Company ogsm review

公司级 OGSM 下级审查

🔴 CHECKPOINT · STOP｜先验政策与父子类型

任何分析前，必须逐字输出并填写这六行；省略即表示审查未完成：

审查模式：<双文档自查/正式治理复核/资料预检/历史回测>
承接标准适用性：<通过/自查 profile（未正式验证）/不适用（语义对齐）/GAP/冲突；policy metadata>
S→O：<通过/失败/语义承接/未审；parent_id→child_id>
M→G：<通过/失败/语义承接/未审；parent_id→child_id>
上级 S/M 具名承接覆盖：<x/y；无人承接 ID>
SP/BP 一致性：<通过/冲突/GAP/未审；source revision 或“增强材料未输入”>

方法边界：

• “S/M 原样成为下级 O/G”在本 skill 中定义为被审组织批准的OGSM 不走样承接标准，用于确定性拆解与审计；它不是所有 OGSM 流派都必须遵循的唯一普适理论。
• 只有政策名称、版本、适用周期和批准状态明确，且政策明确要求 exact text inheritance 时，下面的逐字继承规则才作为 P0 硬门。
• 政策缺失、草案、过期或与被审周期冲突时，承接标准适用性写 GAP/冲突：两份 OGSM 可读就进入 semantic_alignment 双文档自查；用户明确选择严格 profile 时，把严格映射列为未验证的修改标准/压力测试。不得把其他 OGSM 级联方式判成“普适错误”，正式治理结论保持未审。
• 双文档自查可由用户选择 approved_no_distortion profile。此时按不走样标准给修改建议，但若没有政策版本与生效证据，必须注明“自查 profile，非正式 policy 验证”，不得升级为正式通过。
• 用户未指定严格 profile 且未提供批准政策时，使用 semantic_alignment：检查每条下级 O/G 是否可追溯到上级 S/M、意图和红线是否保留、贡献是否可衡量；不要求逐字一致。

政策适用时的不可变规则：

• 上级 S 必须移动到本级 O，文本保持原样；本单元任务、客户和范围只写在 scope，不得写进 O 原文。
• 上级 M 必须移动到本级 G，文本保持原样；本单元目标值、基线和贡献公式只写在 G 的附属字段，不得写进 G 原文。
• 禁止写“把上级 S/M 拆成、转化成或具体化为本级 O/G”。正确动作是“原文继承到 O/G，范围与数值另列”。
• 若上级 S 被写在本级 S，结论固定为：S→O 失败。若上级 M 被写在本级 M，结论固定为：M→G 失败。

只有六行均完成后，才进入规范性与内容分析。

任务边界

站在上级经营与组合管理视角审查一个或多个下级单元。先选择审查模式：

1. 双文档自查（默认）：只需上级/公司 OGSM 与下级/部门 OGSM。目标是让负责人知道哪里未承接、哪里写法不合格、具体如何修改；增强材料缺失不阻断本轮反馈。
2. 正式治理复核：在双文档基础上增加批准政策、分工矩阵、SP、BP/预算、组织边界、经营证据与身份核验，才可给正式治理判定。
3. 资料预检：上级或下级 OGSM 任一不可读时，只列输入缺口和准备动作。
4. 历史回测：只按被审周期当时有效的政策、SP 与 BP 判断。

结果分成两条独立结论：

1. 规范性：O/G/S/M/A 是否按 OGSM 标准书写、可衡量、可问责、可复盘。
2. 内容合格度：是否按选定 profile 承接上级 OGSM；正式治理复核还要判断是否与同周期 SP、BP/预算和经营口径一致。

不替管理层批准目标、预算、任命或绩效结果。没有来源的数字、责任人和判断统一标为 GAP；有冲突的内容标为 CONFLICT。

输入契约

双文档自查的最小输入

1. 上级/公司 OGSM：至少可识别 O/G/S/M、周期、版本或更新时间。
2. 下级/部门 OGSM：至少可识别 O/G/S/M；Owner、周期、版本缺失时仍继续审查，并把缺口写进修改建议。

两份文档均可读时，必须直接给出逐条映射、规范性反馈和修改建议。不得因为缺 SP、BP、预算、分工矩阵或通讯录核验而拒绝自查；这些缺失只限制正式结论和扩展一致性检查。

正式治理复核的增强输入

正式治理复核必须取得以下七包材料：

1. 承接政策：组织批准的 OGSM 不走样承接标准，含 policy name、revision、status、effective_from、effective_to、effective_periods 和是否要求逐字继承。
2. 公司/上一级 OGSM：含版本、周期、S/M 编号和公司级 A Owner。
3. 公司 S/M 分工矩阵：说明哪些 S/M 由当前单元承接，其他 S/M 由谁承接。
4. 当前单元 OGSM：含 O/G/S/M/A、版本、Owner 和适用周期。
5. 同周期公司 SP：至少含战略选择、Where to Play、How to Win、明确不做和阶段目标。
6. 同周期公司 BP/预算：至少含承诺、预测、基线、预算行、里程碑、释放/停止条件和数据口径。
7. 组织与证据包：单元边界、收入/客户/SKU/渠道/共享成本归属、实际数据、Owner/Due/Check/Evidence。

先建立来源登记表：source_id / title / revision / effective_from / effective_to / period / owner / status。

只把用户本次提供、连接器返回或用户明确授权读取的材料登记为证据。仓库中的 tests/、examples/、test-prompts.json 及占位数据只用于测试 skill，真实审查时禁止读取、运行或引用它们来补齐用户材料。用户声称“材料已提供”但当前任务拿不到正文时，仍按材料不可读处理。

所有公司 A、下级 A、数据 Owner 和他处承接人必须通过公司权威通讯录实时反查为个人。不得接受计划提交者自建的“people”表作为身份证明。若当前环境可访问飞书，使用只读通讯录查询核验姓名与个人 open_id；若无法核验，只能预审，不能正式“通过”。

责任角色必须分开登记，不能互相推定：

角色	只证明什么	不得据此推定
access_contact 权限联系人	能协助开通或定位材料	业务结果 A、提交人、数据 Owner
submitter 提交协作人	提交或维护了版本	业务结果 A、批准人
business_accountable 业务结果 A	对业务结果最终问责	数据定义或权限管理责任
data_owner 数据 Owner	对指标定义、来源和质量负责	业务结果 A

正式源不可读时只记录已证实的角色，进入资料预检；不得把权限联系人、提交协作人、相邻业务负责人或文档所有者自动写成当前单元的业务结果 A。

如果上级或下级 OGSM 任一不可读，进入资料预检。若两份 OGSM 可读但增强材料不全，仍完成双文档自查，只是不输出正式“通过”。历史材料只使用当时有效的组织规则；把当前规则另列为压力测试，不得倒查后制造误报。

组织批准后的核心承接法则

当且仅当开头的承接标准适用性为通过，把以下规则作为 P0 硬门，不做宽泛的“相关性”判断：

上一级 S = 下一级 O
上一级 M = 下一级 G
下一级 S = 再下一级 O
下一级 M = 再下一级 G

具体执行：

• 下级 O 必须原样保留所承接的上级 S 文本；单元范围、客户和边界写在独立的 scope 列，不得改写 S。
• 下级 G 必须原样保留所承接的上级 M 文本；本单元基线、目标值、贡献公式和数据源写在独立字段，不得改写 M。
• S→S、S→G、M→M、M→O、只写“支持/协同/相关”均不算承接。
• 每一条上级 S、每一条上级 M 都必须出现具名公司 A 和具名下级承接人。没有人承接即 暂停。
• 一个上级 S/M 可以由多个下级单元按互斥范围共同承接，但必须写清范围、汇总公式和去重规则；“共同负责”不能替代单一 A。
• 当前单元未承接的上级 S/M，必须在公司分工矩阵中标明其他具名承接人和决策依据；否则公司组合覆盖仍为 GAP。
• 支持方只进入 C/S 或依赖列，不计入 S/M 承接覆盖率。

后续报告直接沿用开头 CHECKPOINT 的六行结果，不要重复复述规则或再次输出同一组硬门。

如果材料把上级 S 放在本级 S，必须明确写：失败：上级 S 没有成为本级 O；把上级 S 从本级 S 移到本级 O，并保持原文。 不能写成“原样复制上级 S 不合格”。

如果材料把上级 M 放在本级 M，必须明确写：失败：上级 M 没有成为本级 G；把上级 M 从本级 M 移到本级 G，并保持原文。 不能建议把上级 M “拆到本级 G/M”。本单元目标值、基线和贡献公式是 G 的附属字段；本级 M 只衡量本级 S。

先读 references/parent-child-mapping.md，再建立逐条映射。未经映射，不进入写法评分。

审查流程

Step 1｜锁定周期、版本与边界

确认：

• 当前使用双文档自查、正式治理复核、资料预检还是历史回测；
• 不走样承接政策是否已批准、版本化，并在被审周期内生效；
• 公司 OGSM、下级 OGSM、SP、BP/预算是否同一决策周期；
• 当前单元是圈子、业务线、产品线、平台还是职能部门；
• 当前单元服务谁、控制什么、不控制什么；
• 产品、客户、渠道、国家、价格带、收入、成本、预算和共享能力是否与其他单元重叠；
• 规则在被审周期内是否有效。

版本冲突时并列展示，不静默选一个。双文档自查将其列为高优先级修改项；正式治理复核中，关键周期、版本或边界冲突未关闭则判 暂停。

Step 2｜建立公司 S/M 承接总账

逐条列出全部上级 S/M，不只列当前单元想承接的部分：

parent_id	上级原文	公司 A	当前单元是否应承接	child_id	下级原文	下级 A	scope	汇总/去重	状态

执行两次检查：

1. 单元检查：当前单元的 O/G 是否按选定 profile 承接上级 S/M；严格 profile 检查原文继承，语义 profile 检查可追溯、意图/红线保留和可衡量贡献。
2. 组合检查：有分工矩阵时检查全部上级 S/M 是否至少有一个具名下级承接人，且没有范围冲突或结果重复计数；无矩阵时明确“仅能检查当前单元，无法证明组织组合全覆盖”。

正式治理复核可运行确定性结构检查：

python scripts/validate_review.py review.json --format markdown --verify-owners-live

JSON 字段见 references/input-schema.md。双文档自查不要求先构造 JSON；脚本通过只代表正式模式的结构门通过，不代表战略内容获批。

--verify-owners-live 会只读查询飞书通讯录，核对 name/open_id/tenant。省略该参数时，脚本允许做离线结构检查，但 formal_pass_possible 固定为 false。

Step 3｜检查 OGSM 书写规范性

按 references/checklist.md 检查：

• O：严格 profile 使用所承接上级 S 的原文；语义 profile 必须可追溯到上级 S、保留意图和边界，不另造无来源口号。
• G：严格 profile 使用所承接上级 M 的原文；语义 profile 必须可追溯到上级 M。两种 profile 都要把基线、目标、公式、来源、数据 Owner、复核日列清。
• S：写清选择、机制、控制点、因果桥和明确不做；不是动作清单。
• M：衡量本级 S，每条 S 至少包含结果指标、领先指标和红线/停止指标；不是里程碑清单。
• A：关键行动有单一 Owner、Due、Check、Evidence、依赖和资源来源。

圈子/业务线最多保留 1—3 个关键战略机会；职能部门最多保留 1—3 个下游价值结果。职能部门没有直接收入时，使用周期、质量、采用、复用、风险避免、SLA 和下游经营贡献，不强造收入指标。

Step 4｜检查公司 SP 一致性

仅在用户提供同周期 SP 时执行；否则写 未审（增强材料未输入），不阻断双文档自查反馈。

逐项回答：

1. 下级承接的 O/G 是否指向公司 SP 中同周期的战略选择和阶段目标？
2. 本级 S 是否服务公司 Where to Play / How to Win，还是擅自增加战场、客户、国家、价格带或产品线？
3. 是否保留公司明确不做、退出和资源上限？
4. 是否把渠道/客户要求、AI 工具、活动或组织动作误写成战略？
5. 是否用旧 SP 或未来 SP 的目标替代本周期口径？

任何下级战略与有效 SP 正面冲突且无批准例外，判 暂停。触碰安全、质量、诚信、隐私或合规红线，判 终止。

Step 5｜检查公司 BP/预算一致性

仅在用户提供同周期 BP/预算时执行；否则写 未审（增强材料未输入），不阻断双文档自查反馈。

逐项核对：

• 周期、币种、收入、管理利润/利润口径、现金、毛利、单位资源产出分母和数据源一致；
• 下级 G 的基线、承诺、预测、挑战值不混写；
• 下级目标可汇总到公司 BP，且客户/SKU/渠道/收入/共享成本不重复；
• 每个 G 有对应 BP 里程碑，每项关键预算购买明确的最小证据；
• 每项不可逆投入有释放条件、停止条件、authority 和复核日；
• AI 只在采用并改善周期、质量、成本、转化或经营结果时计价值，不用 token、调用量、培训数代替结果。

公司 BP 与下级 G 数字冲突、无法汇总或重复计数，关键结论判 暂停，并指定 Resolver、Due、Check。

Step 6｜检查经营闭环

双文档自查至少检查 上级 S/M → 下级 O/G → 下级 S/M 是否连通；只有 BP、预算、证据和月度实际可读时，才检查完整经营闭环。

对每个下级 G 追踪：

公司 SP → 公司 OGSM S/M → 下级 O/G → 下级 S/M
→ BP 里程碑 → 预算行 → 最小证据 → Release/Stop
→ 月度实际 → Gap → 根因 → 纠偏 → 复核结果

缺任一关键 Owner、Due、Check、Evidence 或停止门，不能判“闭环”。

Step 7｜给出双结论与总判定

双文档自查先分别判定：

• 规范性：合格 / 部分合格 / 不合格 / 无法判断
• 内容承接：已对齐 / 部分对齐 / 未对齐 / 无法判断
• 自查总判定取较低结果，并给出按优先级排序的 3—7 项修改建议。缺增强材料时写清“未审范围”，但不能因此省略可由两份 OGSM 直接得出的修改建议。

正式治理复核再分别判定：

• 规范性：通过 / 验证 / 暂停 / 终止
• 内容合格度：通过 / 验证 / 暂停 / 终止

总判定取两者较低结果，并受 P0 硬门覆盖。只使用：

结论	条件
通过	严格父子承接、SP/BP 一致、边界去重、指标证据、责任与复盘均闭合；只在已批准范围内执行。
验证	方向与映射成立，但证据或部分指标未闭合；只允许小额、可逆、带停止门的验证。
暂停	资料/版本缺失、S/M 漏接或改写、无人承接、SP/BP 冲突、口径不可汇总、关键闭环缺失。
终止	命中红线，或核心价值/商业闭环已被证伪。

上级或下级 OGSM 不可读时写 暂不评分（双文档不完整）。仅增强材料不全时，完成双文档自查并写 正式治理结论：未审，不要输出伪精确分数。

正式治理复核 P0 硬门

仅在正式治理复核中，任一命中不得“通过”。双文档自查若命中，应判部分对齐/未对齐并给修改方案，不得停止反馈：

• 不走样承接政策未批准、未版本化、对被审周期不生效，或未明确要求 exact text inheritance；
• 上级 S 未原样成为下级 O；
• 上级 M 未原样成为下级 G；
• 任一上级 S/M 没有具名承接人；
• 支持方被冒充为承接人，或多人“共同负责”但无单一 A；
• 公司 OGSM、SP、BP/预算周期或版本不清；
• 下级目标与公司 BP 冲突、无法汇总或重复计数；
• 下级策略超出公司 SP 主战场且无批准例外；
• 关键数字缺定义、公式、基线、来源、Owner 或复核日；
• 关键预算无证据购买、Release/Stop、authority 或复核日；
• 安全、质量、诚信、隐私、合规或重大信任红线未闭合。

失败恢复

触发条件	一线处理	仍未解决
公司 S/M 没有编号	临时按文档顺序编号并注明 JUDGMENT	要求公司 Owner 确认编号；此前不得正式通过
严格 profile 下级改写了上级 S/M	把上级原文恢复为下级 O/G，范围和指标拆到独立字段	正式复核中负责人拒绝恢复时判 暂停
缺公司 S/M 分工矩阵	审当前单元映射，同时列出全部未确认 S/M	组合覆盖保持 GAP，不得声称公司已闭环
SP/BP 与 OGSM 周期不一致	按生效期分账，当前规则只做压力测试	无法确认历史有效版本时，正式治理结论未审；双文档自查继续
职能部门无直接收入	改查下游价值、周期、质量、采用、风险和 SLA	仍无法指向公司 S/M 或 BP 结果时判 暂停
数字口径冲突	并列定义、来源和差值，指定 Resolver	关闭前相关 G 判 暂停
结构脚本报错	按错误补字段或修正类型后重跑	用人工矩阵兜底并披露未通过确定性验证

反例黑名单

不要：

• 把“方向一致”“支持公司战略”当作父子承接；
• 严格 profile 下允许 S→S、M→M 或语义近似映射蒙混过关；
• 严格 profile 下为了适配下级表述而改写上级 S/M；
• 只检查当前单元想接的条目，忽略公司其他 S/M 是否无人承接；
• 用表格完整、措辞漂亮或高目标抵消 SP/BP 冲突；
• 用当前战略规则直接裁判历史 OGSM；
• 把预测、挑战目标、订单、出货、压货、活动量或 AI 调用量当作承诺结果；
• 给职能部门强造收入，或只看活动、会议、培训和招聘数量；
• 平均冲突数字、静默选择一个版本、重复计算共享结果；
• 把 skill 自带的合成测试数据、示例人名或占位 ID 当作被审组织的真实证据；
• 把权限联系人、提交协作人、文档所有者或相邻业务负责人自动认定为当前业务结果 A；
• 用负责人短反馈替代完整审查，或在短反馈中堆入超过 3 项修改；
• 因外发而删除全部分模块数据，或在隐私检查记录里复述公司合并敏感值；
• 未确认收件人、内容和发送身份就真实发送消息；
• 替管理层自动批准预算、任命、绩效或终止决定。

输出路由

严格使用 references/output-template.md，并按证据量只选一种模式：

• 资料预检：上级或下级 OGSM 任一不可读、只有摘要或无法识别 O/G/S/M 时使用。输出六行检查点、输入缺口和准备动作。
• 双文档自查：两份 OGSM 均可读时默认使用。输出六行检查点、逐条父子映射、规范性与内容承接双结论、未审范围、3—7 项修改建议和可直接替换的建议写法。
• 正式全版：七包材料可读、周期版本明确、承接政策适用且人员身份已由权威目录核验时使用。输出来源表、全部 S/M 承接总账、规范性、SP/BP、经营闭环、修改项和裁决题。
• 用户明确要求完整报告时可输出全版，但缺失项仍标 GAP，总判定不得升级。

双文档自查中的每项修改建议必须写清“问题—为什么—怎么改—验收标准”；Owner/Due 未提供时写 待负责人填写，不得虚构。正式模式必须给出 Owner、Due、Check。

交付边界附加规则

这些规则不新增审查模式，只约束审查结果如何被压缩、外发和发送。

负责人短反馈

用户要求私信、群消息或负责人短反馈时：

1. 先完成并保留对应的资料预检、双文档自查或正式全版；短反馈不能替代完整审查证据。
2. 另输出一段人话短反馈，只保留结论、最多 3 项优先修改，以及上级/公司外发版、当前单元 OGSM、Skill 说明三类链接。
3. 正式源不可读时明确写“资料预检/暂不评分”，只请求补权限、确认正式源和业务 A，不把二级证据写成正式结论。

外发数据边界

用户要求隐藏公司整体数据但保留分模块数据时，使用以下 privacy profile：

• company_consolidated：公司整体合并目标/实际、覆盖全部模块的汇总或小计、未分配差额、抵消项、勾稽关系，以及可直接倒推出公司整体合并口径的占比或公式。外发时隐藏。
• module_level：单个业务线、圈子、产品线或中后台模块自身口径。用户已授权外发时保留，不得因“脱敏”而整表删除。
• 若多个模块值与桥接字段可直接复算公司合并口径，只隐藏汇总、差额、占比或桥接关系；保留获准的模块原值。
• 输出 privacy_check_record，只说明隐藏了哪些类别、保留了哪些类别及是否关闭反推风险；不得在记录中复述敏感值。

🔴 CHECKPOINT · STOP｜真实发送

任何消息真实发送前，必须让用户明确确认：收件人、消息内容、发送身份（用户或机器人）。三项任一未确认时只输出草稿或 dry-run，不调用发送接口。发送后记录 message_id 并回读核验发送人、正文和关键链接。

完成门

完成双文档自查必须满足：

• 上级与下级 OGSM 的版本/周期/可读状态已说明；
• 已逐条建立上级 S/M 与下级 O/G 的承接关系，无法映射的条目明确列出；
• O/G/S/M/A 规范性逐项判定；
• 已给出规范性与内容承接双结论、未审范围和 3—7 项可执行修改建议；
• 每项建议含问题、原因、改法和 Check，未提供的 Owner/Due 明确标 待负责人填写。
• 若用户要求负责人短反馈，完整审查仍保留；短反馈不超过 3 项修改并包含三类链接。
• 若用户要求外发脱敏，已区分 company_consolidated 与获准的 module_level，并给出不复述敏感值的 privacy_check_record。
• 若已真实发送消息，用户已确认收件人、内容和身份，且已记录并回读 message_id。

完成正式治理复核还必须满足：

• 七包材料的版本、周期和读取状态明确；
• 不走样承接政策的批准状态、版本、effective_from/effective_to/effective_periods 和 exact-text 要求明确；
• 全部上级 S/M 的承接去向和公司 A 明确；
• 当前单元应承接的 S/M 已严格变为本级 O/G；
• O/G/S/M/A 规范性逐项判定；
• 公司 SP、BP/预算一致性逐项判定；
• 跨单元边界、汇总公式和去重规则明确；
• P0 硬门全部通过；
• 缺口、Owner、Due、Check、决策 authority 和下一复核日明确。