Back to Details

policy-evaluation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Policy Evaluation

Policy 评估

Organization policyは文章が存在するだけでは完成しない。Constitutional property、current Operating Model、replaceable Practice、Skill judgmentを区別して評価する。
policyが実行可能なcommand/configへ落ちる部分はdeterministicに検証し、判断を含む部分はfresh agentへcold contextで読ませ、意図したbehaviorを再現できることまで検証する。
policy changeのquality signalを、作者自身の読み直しや「もっともらしい回答」だけへ依存させない。
组织 Policy 仅有一份文档并不代表完成。评估时必须区分 Constitutional property、当前 Operating Model、可替换的 Practice 和 Skill judgment。
对于 Policy 中可落实为 command/config 的部分，应进行确定性验证；对于包含判断的部分，则在 cold context 下交给 fresh Agent 阅读，并验证其能够复现预期 behavior。
Policy 变更的质量信号不能仅依赖作者自行复读或“看起来合理的回答”。

0. Constitutional outcome gate

0. Constitutional outcome 门禁

policy changeを評価するとき、最初に「指定手順を使ったか」ではなくresulting organizationを確認する。
最低限の観点:
  • artifact / attempt / evidence identityが保たれたか
  • authorityを持たないactorのdecisionが確定していないか
  • stale/partial evidenceがcurrent proofになっていないか
  • concurrent mutable ownershipが安全か
  • actor/session loss後にdurable stateから継続できるか
  • conflicting canonical authorityを作っていないか
  • safety mechanismがvalid progressを不必要に止めていないか
tool/command-specific assertionは、そのPractice自体のcontractを評価する場合だけhard requirementにする。
formalizableなconcurrency/recovery/identity propertyは 
formal/Organization.tla
のabstract modelも参照する。TLC successをimplementation conformanceの代替にはしない。
评估 Policy 变更时，首先应检查最终形成的组织，而不是检查是否遵循了指定步骤。
最低限度的检查项：
  • artifact / attempt / evidence 的同一性是否得到保持
  • 无权限 actor 的 decision 是否没有被最终确定
  • stale/partial evidence 是否没有被当作 current proof
  • concurrent mutable ownership 是否得到安全处理
  • actor/session 丢失后，是否能够从 durable state 继续执行
  • 是否没有创建相互冲突的 canonical authority
  • safety mechanism 是否未在无必要时阻止 valid progress
只有在评估 Practice 自身的 contract 时，才应将 tool/command-specific assertion 设为 hard requirement。
对于可形式化的 concurrency/recovery/identity property，还应参考 
formal/Organization.tla
的 abstract model。TLC success 不能替代 implementation conformance。

1. Deterministic space / latent space

1. Deterministic space / latent space

変更対象のruleを最初に2つへ分ける。
首先将待变更的 rule 分为两个空间。

Deterministic space

Deterministic space

同じrepository stateとinputなら、原則として同じ結果を要求できる領域。
例:
  • file / config / link / commandの存在
  • naming / schema / metadata constraint
  • Git / GitHub stateの整合性
  • exact SHA / dependency / branch relationship
  • machine-readable policy profile
  • document structure
  • command snippetの実行可能性
  • regression fixtureに対するpass/fail
ここは自然言語推論を毎回やり直さず、script / command / parser / machine-readable checkへ寄せる。
原则上，只要 repository state 和 input 相同，就应要求得到相同结果的领域。
示例：
  • file / config / link / command 是否存在
  • naming / schema / metadata constraint
  • Git / GitHub state 的一致性
  • exact SHA / dependency / branch relationship
  • machine-readable policy profile
  • document structure
  • command snippet 的可执行性
  • regression fixture 的 pass/fail
对于这些领域，不应每次都重新进行自然语言推理，而应尽量转化为 script / command / parser / machine-readable check。

Latent space

Latent space

単一の文字列比較では正しさを表現できず、policyを読んだagentの判断・優先順位・状況理解が必要な領域。
例:
  • user escalationが必要か
  • taskをどう分解するか
  • どのquality levelを要求するか
  • project evidenceから何をcanonicalと読むか
  • ambiguity / risk / trade-offの扱い
  • reviewerがartifactをどう評価するか
ここはfresh agentへ必要最小限のpolicyとscenarioだけを渡すcold evalで確認する。
deterministicにできるものをlatent evalへ残さない。逆に、keyword matchingだけでjudgment correctnessを証明したと扱わない。
无法通过单次字符串比较表达正确性，需要 Policy 所驱动 Agent 进行判断、确定优先级并理解情境的领域。
示例：
  • 是否需要 user escalation
  • 应如何拆解 task
  • 应要求哪个 quality level
  • 应将 project evidence 中的什么视为 canonical
  • 如何处理 ambiguity / risk / trade-off
  • reviewer 应如何评估 artifact
对于这些领域，应仅向 fresh Agent 提供理解目标 rule 所需的最小 Policy 和 scenario，并通过 cold eval 进行确认。
不要将本可确定性处理的内容留在 latent eval 中。反之，也不要把 keyword matching 当作 judgment correctness 的证明。

2. Policy change gate

2. Policy change 门禁

significantなAgent policy / Skill / prompt / routing変更では、変更前に次を判定する。
  1. 何のbehaviorを変えるか
  2. そのbehaviorのdeterministic部分は何か
  3. latent judgmentが残るか
  4. 過去に実際に起きたfailure / regressionがあるか
  5. fresh agentがcold contextから理解できる必要があるか
次のいずれかに該当する場合、repo-local evalを追加・更新する。
  • wordingだけではbehavior preservationを証明できない
  • model generation差で解釈が揺れ得る
  • safety / delivery / recovery / qualityのcritical invariantを扱う
  • 過去に同じruleが誤解・退行した
  • 複数Skillの優先順位やroutingに依存する
  • deterministic testだけでは「読んで正しく使えるか」を証明できない
小さな誤字修正や意味を変えないrefactorへ無意味なevalを増やさない。
对于显著的 Agent policy / Skill / prompt / routing 变更，应在变更前判断：
  1. 要改变什么 behavior
  2. 该 behavior 中哪些部分属于 deterministic space
  3. 是否仍存在 latent judgment
  4. 过去是否实际发生过 failure / regression
  5. fresh Agent 是否必须能够在 cold context 中理解它
出现以下任一情况时，应添加或更新 repo-local eval：
  • 仅凭 wording 无法证明 behavior 得到保留
  • model generation 差异可能导致解释波动
  • 涉及 safety / delivery / recovery / quality 的 critical invariant
  • 同一 rule 过去曾被误解或发生 regression
  • 依赖多个 Skill 的优先级或 routing
  • 仅靠 deterministic test 无法证明 Agent 能够正确理解并使用 rule
不要为小型 typo 修正或语义不变的 refactor 无意义地增加 eval。

3. Cold eval contract

3. Cold eval contract

latent evalは作者の会話・実装経緯・期待回答をagentへ漏らさない。
原則:
  • fresh agent / fresh contextを使用
  • 対象ruleの理解に必要な最小policyだけを渡す
  • builderのchain-of-thought、試行錯誤、grader実装を渡さない
  • scenarioはactual taskに近い具体例にする
  • answer formatを可能な範囲でstructuredにする
  • artifact / decision / commands等、外部化可能な結果だけを採点する
評価対象policyを全文promptの他sectionで補ってしまわない。
latent eval 不得向 Agent 泄露作者自己的对话、实现过程和期望答案。
原则：
  • 使用 fresh agent / fresh context
  • 仅提供理解目标 rule 所必需的最小 Policy
  • 不提供 builder 的 chain-of-thought、试错过程或 grader 实现
  • scenario 应采用接近实际 task 的具体示例
  • 尽可能将 answer format 结构化
  • 仅对 artifact / decision / commands 等可外部化的结果进行评分
不得通过 Prompt 的其他 section 间接补充目标 Policy 的全部内容。

4. Graderは自分自身をcontrolする

4. Grader 对自身进行控制

graderがanswer keyの表面形だけを数える状態を許容しない。
最低限、次の3 controlを持つ。
不能允许 grader 仅统计 answer key 的表面形式。
至少应具备以下 3 项 control。

Negative control

Negative control

典型的だがpolicy上誤っているnaive answer。
必ずFAILしなければならない。
典型但根据 Policy 属于错误答案的 naive answer。
必须判定为 FAIL。

Regression control

Regression control

過去に実際に通ってしまった、または実害があったbroken answer / behavior。
表面shapeが正しくてもFAILさせる。
过去曾意外通过，或实际造成过损害的 broken answer / behavior。
即使表面形式正确，也必须判定为 FAIL。

Positive control

Positive control

current policyが意図するvalid answer。
必ずPASSしなければならない。
controlが期待通りに分離できないgraderのscoreはquality evidenceとして使用しない。
重要なmust-not / safety invariantは、総合点で相殺させずhard failureにする。
当前 Policy 所预期的 valid answer。
必须判定为 PASS。
如果 control 无法按照预期区分不同答案，则 grader 的 score 不得作为 quality evidence 使用。
对于重要的 must-not / safety invariant，应设为 hard failure，不能让综合得分将其抵消。

5. Eval fixture structure

5. Eval fixture 结构

project conventionがなければ次を候補とする。
text
evals/
  <policy-area>/
    scenario.md
    grade.sh
    controls.sh
    fixtures/
      positive.*
      negative.*
      regression.*
provider-specific eval runnerをcanonical policyへ固定しない。
model invocationはmanual / external runner / CI serviceのいずれでもよいが、scenarioとdeterministic grader / controlsはrepository-controlled stateとして再現可能にする。
如果项目没有既定 convention，可以将以下结构作为候选：
text
evals/
  <policy-area>/
    scenario.md
    grade.sh
    controls.sh
    fixtures/
      positive.*
      negative.*
      regression.*
不要将 provider-specific eval runner 固定为 canonical policy 的一部分。
model invocation 可以采用 manual / external runner / CI service 中的任意方式，但 scenario 与 deterministic grader / controls 必须作为 repository-controlled state 保持可复现。

6. Execution profile

6. Execution profile

task complexityだけでなく、必要なexecution behaviorを先に分類する。
標準profile:
首先应根据所需的 execution behavior 分类，而不应仅依据 task complexity 判断。
标准 profile：

mechanical

mechanical

  • deterministic transformation中心
  • 局所変更
  • product / architecture judgmentなし
  • failure impactが限定的
default:
  • solo execution
  • deterministic/focused validation
  • 不要なfan-outやcriticを起動しない
  • 以 deterministic transformation 为主
  • 局部修改
  • 不涉及 product / architecture judgment
  • failure impact 有限
默认方式：
  • solo execution
  • deterministic/focused validation
  • 不启动不必要的 fan-out 或 critic

localized

localized

  • 1つのcomponent / module / document領域
  • existing conventionからほぼ決定可能
  • limited judgment
default:
  • solo implementation
  • applicable focused/integration validation
  • user-visibleまたはpolicy-sensitiveならcold final read/reviewを追加
  • 局限于一个 component / module / document 领域
  • 基本可以根据 existing convention 确定
  • judgment 有限
默认方式：
  • solo implementation
  • 执行适用的 focused/integration validation
  • 如果涉及 user-visible 或 policy-sensitive 内容，额外增加 cold final read/review

cross-boundary

cross-boundary

  • API / DB / UI / runtime / multiple docs/Skills等のboundaryを横断
  • dependencyやintegration riskあり
default:
  • dependency decomposition
  • safeなnodeだけparallelize
  • integration gate
  • completed artifactに対するbuilderと分離したindependent cold reviewを必須とする
  • 跨越 API / DB / UI / runtime / 多个 docs/Skills 等边界
  • 存在 dependency 或 integration risk
默认方式：
  • dependency decomposition
  • 仅并行执行安全节点
  • integration gate
  • 必须对 completed artifact 执行与 builder 分离的 independent cold review

judgment-heavy

judgment-heavy

  • architecture / product semantics / policy interpretation / visual quality / trade-offが中心
  • deterministic correctnessだけで完了判定できない
default:
  • evidence / reference / acceptance rubricを先に固定
  • builderと分離したindependent cold reviewerを必須とする
  • completed artifact / diff / immutable snapshotをcold review
  • significant decisionをappropriate durable surfaceへ保存
複数profileに該当する場合は、より弱いlabelへ丸めずsafeguardを合成する。特に 
cross-boundary
かつ 
judgment-heavy
のtaskはdependency decomposition / safe parallelismとevidence/rubric-first executionの両方を適用し、combined routingをorchestration前に記録する。
execution profileはquality taxonomyの代替ではない。
quality-gate
が「何を検証するか」を決め、execution profileは「どの程度のorchestration / reviewを使うか」を決める。
  • 重点涉及 architecture / product semantics / policy interpretation / visual quality / trade-off
  • 无法仅凭 deterministic correctness 完成任务判定
默认方式：
  • 先固定 evidence / reference / acceptance rubric
  • 必须设置与 builder 分离的 independent cold reviewer
  • 对 completed artifact / diff / immutable snapshot 进行 cold review
  • 将重要 decision 保存到适当的 durable surface
如果 task 同时符合多个 profile，不要将其归入其中较弱的一个，而应组合相应的 safeguard。尤其是同时属于 
cross-boundary
和 
judgment-heavy
的 task，应同时采用 dependency decomposition / safe parallelism 与 evidence/rubric-first execution，并在 orchestration 之前记录 combined routing。
execution profile 不能替代 quality taxonomy。
quality-gate
决定“需要验证什么”，execution profile 则决定“使用何种程度的 orchestration / review”。

7. Cold artifact review

7. Cold artifact review

cross-boundary / judgment-heavy taskでは、completed candidate artifactに対するbuilderと分離したindependent cold reviewをrequired completion gateとし、builder自身の作業記憶だけをfinal quality signalにしない。
reviewerへ原則渡すもの:
  • objective / acceptance criteria
  • canonical reference / frozen rubric
  • completed artifact / diff / immutable snapshot
  • applicable validation evidence
  • known limitations
原則渡さないもの:
  • builderのprivate reasoning
  • 採用されなかった案の長い実況
  • 「ここは良いはず」等のself-justification
reviewerはartifactをfreshに読み、実際に存在する結果から評価する。
数値self-ratingをquality gateとして要求しない。
对于 cross-boundary / judgment-heavy task，应将针对 completed candidate artifact 且与 builder 分离的 independent cold review 作为必需的 completion gate，不能仅将 builder 自身的工作记忆作为最终 quality signal。
原则上应提供给 reviewer 的内容：
  • objective / acceptance criteria
  • canonical reference / frozen rubric
  • completed artifact / diff / immutable snapshot
  • 适用的 validation evidence
  • known limitations
原则上不应提供给 reviewer 的内容：
  • builder 的 private reasoning
  • 对未采用方案的详细过程说明
  • “这里应该没问题”等 self-justification
reviewer 应以全新视角阅读 artifact，并依据实际存在的结果进行评估。
不要要求提供数值 self-rating 作为 quality gate。

8. Context budget

8. Context budget

progressive disclosureは構造だけでなく、always-loaded context量でも監視する。
このrepositoryでは 
bash evals/policy-evaluation/context-budget.sh
をdeterministic regression checkとして実行する。checked-in 
evals/policy-evaluation/context-budget-baseline.tsv
とroot instruction files / total always-on instructions / 各conditional 
skills/*/SKILL.md
を比較し、各surfaceのbyte growthがbaselineの10%または512 bytesの大きい方を超えた場合はFAILする。outputはmachine-readable TSVとし、intentionalなbaseline更新はreview対象にする。
初期化・policy再構成・root agent fileの大幅変更時に最低限確認する:
  • root 
    AGENTS.md
    / 
    CLAUDE.md
    等のword/byte/token estimate
  • always-on instruction全体の概算cost
  • conditional Skillごとのsize
  • rootでしか成立しないinvariantと、Skillへ遅延できるworkflowの区別
  • 同じruleの重複
  • large embedded examples / copied docs
固定token上限を全projectへ強制しない。
ただしalways-on contextが増えた場合は、追加分が本当に全taskで必要かをreviewし、conditional workflow / reference / Skillへ移せないか検討する。
context削減のためにcritical invariantを消さない。
监测 progressive disclosure 时，不仅要关注结构，还必须关注 always-loaded context 的规模。
在本 repository 中，将 
bash evals/policy-evaluation/context-budget.sh
作为 deterministic regression check 执行。该检查会将 checked-in 
evals/policy-evaluation/context-budget-baseline.tsv
与 root instruction files、always-on instructions 总量以及各个 conditional 
skills/*/SKILL.md
进行比较；如果任一 surface 的 byte 增长超过 baseline 的 10% 与 512 bytes 中的较大值，则判定为 FAIL。输出应采用 machine-readable TSV，对 baseline 的有意更新必须纳入 review。
在初始化、Policy 重组或 root agent file 发生重大变更时，至少应检查：
  • root 
    AGENTS.md
    / 
    CLAUDE.md
    等的 word/byte/token estimate
  • always-on instructions 整体的成本概算
  • 每个 conditional Skill 的大小
  • 仅在 root 才能成立的 invariant 与可延迟到 Skill 的 workflow 之间的区别
  • 同一 rule 的重复
  • 大型 embedded examples / copied docs
不要对所有项目强制采用固定的 token 上限。
但是，如果 always-on context 有所增长，应 review 新增内容是否确实是所有 task 都必需的，并考虑能否将其移至 conditional workflow / reference / Skill。
不要为了减少 context 而删除 critical invariant。

9. Repeated reasoningのcodification

9. 重复推理的 Codification

同じ非自明な判断・手順を繰り返した場合、成功例でもcodification candidateとして扱う。
目安:
  • deterministicで安定した処理 -> script / command / config
  • judgmentを含む再利用workflow -> Agent Skill
  • project-wide invariant / long-lived choice -> policy / ADR
  • verification behavior -> quality profile / test / eval
  • one-off local choice -> codeだけに留める
failureだけでなく、繰り返し成功しているmanual flowも自動化候補にする。
如果同一项非平凡判断或流程被重复使用，即使此前取得成功，也应将其视为 codification candidate。
判断标准：
  • deterministic 且稳定的处理 -> script / command / config
  • 包含 judgment 的可复用 workflow -> Agent Skill
  • project-wide invariant / long-lived choice -> policy / ADR
  • verification behavior -> quality profile / test / eval
  • one-off local choice -> 仅保留在代码中
不仅失败流程可以自动化，反复成功的 manual flow 也应成为自动化候选。

10. Comparative latent evaluation

10. Comparative latent evaluation

output style、interaction policy、judgment routing等のlatent behaviorを評価する場合、candidate単独のabsolute scoreだけで改善を主張しない。
baselineとcandidateを比較できる場合は、同じtask distributionに対するpaired comparative evalを優先する。
评估 output style、interaction policy、judgment routing 等 latent behavior 时，不能仅凭 candidate 的 absolute score 就宣称有所改进。
如果 baseline 与 candidate 可以比较，应优先采用针对同一 task distribution 的 paired comparative eval。

Condition parity

Condition parity

比較するcondition間で最低限そろえる。
  • cases / prompts
  • model family / exact model identity when configurable
  • effort / sampling等、behaviorへmaterialなgeneration settings
  • trial count
  • rubric / blocker definition
  • tool availability / sandbox / network policy
  • provider/runtimeの主要version
conditionごとに異なるtask setやrubricを使ったscoreを直接比較しない。
modelやruntimeを意図的に変えるexperimentでは、その差をindependent variableとして明示し、policy差と混同しない。
比较不同 condition 时，至少应确保以下内容一致：
  • cases / prompts
  • model family / exact model identity（可配置时）
  • effort / sampling 等会对 behavior 产生实质影响的 generation settings
  • trial count
  • rubric / blocker definition
  • tool availability / sandbox / network policy
  • provider/runtime 的主要 version
不要直接比较使用不同 task set 或 rubric 的 condition score。
如果有意改变 model 或 runtime，应将该差异明确标记为 independent variable，避免与 Policy 差异混淆。

Runner isolation

Runner isolation

eval runnerはoperatorのpersonal configurationから可能な限り隔離する。
contamination candidate:
  • user-level Agent Skills / plugins
  • hooks
  • memory / saved instructions
  • output style / personality
  • local global config
  • unrelated MCP / connector
  • environment variableによるhidden behavior switch
baselineへcandidate policyがuser-global設定経由で注入される状態を許容しない。
runnerが完全隔離できない場合、そのcontamination riskをresultへ明示する。
应尽可能将 eval runner 与 operator 的个人配置隔离。
潜在污染来源：
  • user-level Agent Skills / plugins
  • hooks
  • memory / saved instructions
  • output style / personality
  • local global config
  • 无关的 MCP / connector
  • 通过 environment variable 实现的 hidden behavior switch
不允许通过 user-global 设置将 candidate policy 注入 baseline。
如果 runner 无法完全隔离，应在 result 中明确说明该 contamination risk。

Identity pinning

Identity pinning

reproducible comparisonではmodel / CLI / runner identityを固定または記録する。
default modelへ暗黙依存しない。CLI updateやprovider default変更で同じcommandのbehaviorが変わり得るため、published resultには少なくとも次を残す。
  • model identity
  • runner / CLI version
  • cases revision
  • rubric revision
  • trial count
  • policy revision / SHA
在 reproducible comparison 中，应固定或记录 model / CLI / runner identity。
不要隐式依赖 default model。由于 CLI 更新或 provider default 变更可能改变同一 command 的 behavior，published result 至少应保留：
  • model identity
  • runner / CLI version
  • cases revision
  • rubric revision
  • trial count
  • policy revision / SHA

Blind judging

Blind judging

graderがcandidate identityを知る必要がないtaskでは、condition名をblindする。
推奨:
  • baseline
    / 
    candidate
    等をgrader promptへ直接渡さない
  • A
    / 
    B
    等のopaque labelへ置換する
  • position biasを避けるためlabel orderをper groupで入れ替える
  • resumeしても同じgroupは同じlabel mappingになるdeterministic permutationを使う
release gateやcondition-specific thresholdはblind judgeへ渡さず、scoring後のseparate deterministic stageで適用する。
如果 grader 无需知道 candidate identity 即可评分，应对 condition name 进行盲化。
推荐做法：
  • 不在 grader prompt 中直接传入 
    baseline
    / 
    candidate
  • 替换为 
    A
    / 
    B
    等 opaque label
  • 在每个 group 内交换 label order，以避免 position bias
  • 使用 deterministic permutation，确保 resume 后同一 group 仍采用相同的 label mapping
不要将 release gate 或 condition-specific threshold 传给 blind judge，而应在 scoring 后的 separate deterministic stage 中应用。

Paired judging

Paired judging

同一case / trialのconditionsは可能なら同じjudge callまたは同じevaluation batchで比較し、task difficulty差をcondition差として誤認しない。
candidateだけを別時点・別judge contextで採点してbaseline scoreと比較する場合は、そのcomparability limitationを明示する。
对于同一 case / trial 的 conditions，应尽可能在同一次 judge call 或同一个 evaluation batch 中比较，避免将 task difficulty 差异误认为 condition 差异。
如果只对 candidate 在另一时点或另一 judge context 中评分，然后再与 baseline score 比较，应明确说明其 comparability limitation。

Release gate

Release gate

weighted totalだけでrelease判断しない。
最低限:
  • blocker finding = hard failure
  • correctness / safety等のcritical dimensionはnon-regression constraintを持つ
  • overall quality improvementはcritical dimensionを悪化させて相殺しない
  • public competitor / baseline comparison claimはcases / model / trials / rubric等が同条件の場合だけ行う
numeric self-ratingはquality evidenceにしない。
不要仅依据 weighted total 决定是否 release。
最低要求：
  • blocker finding = hard failure
  • correctness / safety 等 critical dimension 必须具有 non-regression constraint
  • overall quality 的提升不能用于抵消 critical dimension 的恶化
  • 只有在 cases / model / trials / rubric 等条件一致时，才能提出针对 public competitor / baseline 的比较声明
numeric self-rating 不能作为 quality evidence。

Budget and resumability

Budget and resumability

paid model evalでは、意図しないrunaway costを避けるためcondition / run単位のbudgetまたはprovider側hard capを持たせる。
long-running evalは、completed 
(case, trial, condition, runner)
をdurable resultとして識別し、provider failureやoperator interruption後にcompleted rowsを再実行せずresumeできる形を優先する。
retryはboundedにし、最終provider errorをsilent dropしない。
特定provider API / runnerをcanonical dependencyにはしない。これらはeval harnessのcontractであり、実装はproject/runtimeに合わせる。
在 paid model eval 中，为避免意外产生 runaway cost，应按 condition / run 设置 budget 或 provider 侧 hard cap。
对于 long-running eval，应优先将 completed 
(case, trial, condition, runner)
标识为 durable result，从而在 provider failure 或 operator interruption 后恢复执行时，无需重新运行 completed rows。
retry 应设置上限，且不能静默丢弃最终的 provider error。
不要将特定 provider API / runner 设为 canonical dependency。它们属于 eval harness 的 contract，具体实现应适应 project/runtime。

11. Eval maintenance

11. Eval maintenance

次の場合は関連evalを再実行・更新する。
  • 対象policy / Skill / prompt / routing変更
  • prompt routing / progressive disclosure変更
  • model generation変更でbehavior差が疑われる
  • grader変更
  • 新しいreal regression発見
  • control fixtureの前提変更
新しいregressionを修正した場合、可能ならそのbroken behaviorをregression fixtureへ保存する。
fixtureをcurrent answerへ都合よく書き換えてhistoryを消さない。
出现以下情况时，应重新执行或更新相关 eval：
  • 目标 Policy / Skill / prompt / routing 发生变更
  • prompt routing / progressive disclosure 发生变更
  • model generation 变更导致 behavior 差异受到怀疑
  • grader 发生变更
  • 发现新的 real regression
  • control fixture 的前提发生变更
修复新的 regression 后，如果条件允许，应将对应的 broken behavior 保存为 regression fixture。
不要为了让 fixture 适配 current answer 而重写 fixture 并抹除历史。

12. Completion evidence

12. Completion evidence

policy change完了時は、該当する範囲で次を示す。
  • deterministic checks
  • control結果
  • latent eval結果と使用したmodel/runtime identity when known
  • current policy revision / SHA
  • evalで確認できないknown limitation
  • bash evals/policy-evaluation/context-budget.sh
    の結果とcontext budgetへの影響
  • execution profileの変更有無
latent evalを実行できない環境では、未実施を明示し、deterministic controlsだけでlatent behaviorまで証明したと報告しない。
Policy 变更完成时，应在适用范围内给出以下证据：
  • deterministic checks
  • control 结果
  • latent eval 结果，以及已知时使用的 model/runtime identity
  • current policy revision / SHA
  • eval 无法验证的 known limitation
  • bash evals/policy-evaluation/context-budget.sh
    的结果及其对 context budget 的影响
  • execution profile 是否发生变化
如果当前环境无法运行 latent eval，应明确标记为未执行，不能仅凭 deterministic controls 就宣称已经证明 latent behavior。

13. Policy decay evaluation

13. Policy decay evaluation

policyは追加だけでなく削除も評価する。
non-constitutional ruleについて、model/tool capabilityやorganization designが変化した場合は次を比較する。
  • ruleあり
  • ruleなし
  • simpler replacement / alternative practice
条件を揃えたcomparative evalでmeaningful outcome差がなく、上位invariantも維持される場合、そのruleをpreserveすること自体をquality goalにしない。
削除candidate:
  • original regression/failure modeをcurrent capabilityがinstructionなしで安定回避する
  • replacement mechanismが同等以上のguaranteeを提供する
  • instructionが上位propertyを重複説明するだけ
  • context/coordination costがbenefitを上回る
critical constitutional propertyを「新modelなら賢いはず」という期待だけで削除しない。削除対象はまずOperating Model / Practice / Skillの具体ruleとする。
评估 Policy 时，不仅要评估新增规则，也要评估规则删除。
对于 non-constitutional rule，如果 model/tool capability 或 organization design 发生变化，应比较以下条件：
  • 保留 rule
  • 移除 rule
  • 使用 simpler replacement / alternative practice
如果条件一致的 comparative eval 未显示 meaningful outcome 差异，并且上位 invariant 仍然得到维持，则不应将“保留该 rule”本身作为 quality goal。
删除候选：
  • 当前 capability 即使没有 instruction，也能稳定避免 original regression/failure mode
  • replacement mechanism 提供同等或更强的 guarantee
  • instruction 只是重复说明上位 property
  • context/coordination cost 超过其带来的 benefit
不要仅凭“新 model 应该足够聪明”的预期，就删除 critical constitutional property。删除对象应首先落实到 Operating Model / Practice / Skill 的具体 rule。