上一篇写的是把季度复盘结论写进下季度准入规则：哪些需求能进，owner 容量怎么约束，carryover risk 如何带状态进入新季度。
规则写进准入表以后，问题还没有结束。
很多治理规则是在规划会上成立的。一进入执行，临时例外、顺手补 scope、owner 借调、依赖延迟就会开始出现。它们单独看都像合理调整，累积起来会把 admission rule 慢慢掏空。
所以季度启动后的前几周，要专门做一次启动校验。它不重新评审所有需求，只确认三件事：准入规则有没有被绕过，owner 容量有没有被透支，上一季度带进来的风险有没有被降级成普通待办。
这一篇写一个最小校验机制：用前几周的执行信号守住下季度 admission rule。
1. 启动校验看规则是否真的进入执行
准入规则不要只停在规划表里。
新季度启动后，每个被接受的交付包都应该能回指到它满足了哪些规则：
1
2
3
4
5
6
7
8
9
10
11
12
13
| delivery_package_rule_trace:
package: evidence_replay_gate_completion
admitted_by:
- recurring_risk_cannot_reenter_without_new_evidence
- release_gate_gap_must_close_before_preview
evidence:
- replay_api_owner_named
- audit_contract_updated
- first_two_services_selected
first_week_check:
status: on_track
missing:
- none
|
如果一个交付包在规划会上通过了准入，但启动后拿不出这些证据，就说明准入只是口头通过。
这类问题要在第一周暴露。等到第四周才发现，它已经变成排期风险，团队会更倾向于用例外继续推进。
2. 例外要登记成 rule pressure
执行初期一定会出现例外。
关键点不在于完全禁止例外，而在于把例外登记成对规则的压力，别让它混进普通变更。
1
2
3
4
5
6
7
8
9
10
11
12
| admission_exception_pressure:
exception: allow_exception_preview_before_replay_gate_done
requested_by: product_ops
related_rule: release_gate_gap_must_close_before_preview
pressure_type: sequence_bypass
requested_reason:
- pilot_team_needs_visibility_in_current_month
decision:
status: rejected
reason:
- would_bypass_original_q3_retrospective_finding
- no_new_evidence_reduces_replay_gate_risk
|
这里的重点是 pressure_type。
它说明这个例外是在压哪条规则：是想绕过顺序，扩大 scope，借用 owner 容量，还是延后关闭证据。
例外如果不这样记录，很容易变成“本次情况特殊”。等特殊情况出现三次，规则就已经失效。
3. 前两周要检查 owner 容量有没有被借走
规划时写下的 owner capacity，很快会被执行中的临时事项侵蚀。
所以前两周要看真实容量，而不是只看计划容量：
1
2
3
4
5
6
7
8
9
10
11
12
| owner_capacity_startup_check:
owner: release_platform_team
planned_available_for_new_items: 5
week_1_actual_changes:
incident_support: +8
urgent_policy_hotfix: +5
borrowed_by_other_stream: +4
remaining_capacity_for_admitted_package: -12
required_action:
- freeze_new_scope
- split_replay_gate_completion_to_minimum_closure
- defer_preview_related_work
|
如果容量已经变成负数，不能继续假装交付包仍然可行。
这时要触发范围收缩，而不是靠 owner 加班或把关闭证据往后挪。
owner 容量被借走，本质上就是 admission rule 的执行风险。它应该回到准入表里，而不是只留在项目周报里。
4. carryover risk 不能被改名成优化项
上一季度带进来的 carryover risk，在新季度前几周最容易被改名。
比如 audit_replay_manual_step_remaining 可能被拆成“优化审计回放体验”“补充回放页面入口”“完善回放日志展示”。这些名称都没错，但如果原风险还没有关闭，它们不能替代关闭动作。
可以给 carryover risk 加一个启动期检查：
1
2
3
4
5
6
7
8
9
10
11
12
13
| carryover_risk_startup_check:
risk: audit_replay_manual_step_remaining
expected_q4_decision:
- close_with_replay_api
- extend_acceptance_with_reason
- escalate_to_blocking_baseline
week_2_found_items:
- improve_replay_page_entry
- add_manual_replay_log_filter
validation:
closes_original_risk: false
changes_acceptance_status: false
requires_decision: true
|
这个检查会逼团队回答：这些新增动作是否关闭了原风险。
如果没有关闭，就不能把它们当成风险处理完成。它们可以作为辅助工作存在，但 carryover risk 的状态必须继续保留。
5. 用 drift ledger 记录规则被削弱的路径
准入规则失效通常不是一次性失败。
更常见的路径是微小漂移：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| admission_rule_drift_ledger:
rule: recurring_risk_cannot_reenter_without_new_evidence
drift_events:
- week: 1
event: preview_scope_added_before_replay_gate_done
impact: sequence_bypass
decision: rejected
- week: 2
event: replay_gate_evidence_deadline_moved_by_two_weeks
impact: closure_delay
decision: accepted_with_new_deadline
- week: 3
event: pilot_team_added_without_repeated_use_metric
impact: evidence_gap
decision: pending
|
这份 ledger 不需要复杂系统支持。每周只记会削弱规则的事件。
到了第三周，如果同一条规则已经被压了三次，就不能再说规则运行稳定。它要么太硬，和现实冲突太多；要么执行边界没有被尊重。
两种情况都要调整，但调整方式不同。
6. 区分规则需要修订，还是执行在绕规则
启动校验不能把所有偏差都当成违规。
有些偏差说明规则写错了。
例如要求所有收益型能力都必须绑定 workflow entry，但实际发现某些内部治理能力先通过 API contract 被下游系统消费，短期没有页面入口也能形成重复使用。这时规则应该修订：
1
2
3
4
5
6
7
8
9
10
11
12
| rule_revision_case:
original_rule: benefit_capability_requires_workflow_entry
observed_signal:
- internal_api_contract_has_repeated_downstream_calls
- no_human_workflow_entry_needed_for_this_capability
revision:
accept_when:
- has_workflow_entry
- or_has_stable_downstream_api_contract
still_reject_when:
- no_named_consumer
- no_repeated_use_metric
|
但另一些偏差只是绕规则。
比如需求没有重复使用指标，只是因为“这周先上，后面再补”。这种情况不需要修订规则，应该维持阻断或降级范围。
启动校验的价值就在这里：把“规则不适配现实”和“执行想绕开规则”分开处理。
7. 第三周给一次 admission health 结论
不要等到月末才看 admission rule 是否有效。
第三周可以给一次健康结论：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| admission_health_review:
quarter: 2026_q4
week: 3
rules:
recurring_risk_cannot_reenter_without_new_evidence:
health: stressed
pressure_events: 3
action: keep_rule_and_reduce_scope
benefit_capability_requires_workflow_entry:
health: needs_revision
pressure_events: 1
action: add_api_contract_path
owner_capacity_must_be_available_before_acceptance:
health: violated
pressure_events: 2
action: freeze_new_items_for_release_platform_team
carryover_risks:
audit_replay_manual_step_remaining:
status: still_open
action: keep_as_baseline_gap
|
health 不要只写绿黄红。
它要落到动作：保留规则、修订规则、冻结新增、缩小范围、升级为 baseline gap。
这样第三周 review 才不会变成又一次状态同步。
8. 一个最小启动校验模板
把前面的内容合起来，可以得到一份很轻的模板：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| startup_admission_validation:
quarter: 2026_q4
validation_window:
from: 2026-10-01
to: 2026-10-21
checks:
rule_trace:
required_for_each_admitted_package: true
exception_pressure:
record_pressure_type: true
pressure_types:
- sequence_bypass
- scope_expansion
- owner_capacity_borrowing
- evidence_delay
owner_capacity:
compare_planned_and_actual: weekly
carryover_risk:
require_original_risk_closure_mapping: true
drift_ledger:
review_at_week_3: true
outputs:
- rule_kept
- rule_revised
- scope_reduced
- item_deferred
- carryover_risk_escalated
|
这个模板的作用是把季度启动期的真实信号收回来。
它不增加新的治理层级，只是要求已经写下来的准入规则接受一次早期校验。
小结
下季度准入规则要在启动后的前几周接受现实检验。
每个交付包要能回指到准入证据，例外要登记成 rule pressure，owner 容量要看实际变化，carryover risk 要继续带着原始状态。规则被削弱的路径要进入 drift ledger，而不是散落在周报和会议纪要里。
如果规则不适配现实，就修订规则。如果执行在绕规则，就收缩范围或冻结新增。把这两类问题分开，季度计划才不会在启动后几周就回到旧节奏。
下一篇可以继续写 admission rule 经过启动校验后，如何把这些 rule pressure 和 drift ledger 信号回灌到月度执行节奏里，让规则修订不依赖季度末才发现。
本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-admission-rule-first-weeks-validation-exception-drift-control/