Eval Contract

定義

Eval Contract

Eval Contract とは、ある evaluation subject に対して、
何を、誰または何が、どの基準で、どの証拠に基づいて、どの判定規則で評価するか を定める
明示的な評価契約である。

それは単なる rubric や test list ではなく、
subject、purpose、criteria、required evidence、evaluator set、blocking / advisory classification、decision rule、failure handling、output record、validity scope を含む。

より短く言えば、Eval Contract とは
「この差分またはこの過程を、どの条件で合格とみなし、どの条件で保留・差し戻し・昇格禁止とするか」
を定める評価上の約束である。

PCE 2.0 において評価は、後から感覚的に行う確認ではありません。
評価は process の内部に組み込まれた、merge と promotion の前提条件 です。
Eval Contract は、その評価を曖昧さなく定義するための概念です。

この意味で Eval Contract は、
No merge without eval を運用可能にする中心概念です。

なぜ Eval Contract が必要なのか

PCE 2.0 が Eval Contract を独立概念として置く理由は、
「評価すること」と「どう評価するか」が分離されていないと、評価は運用上すぐに崩れるからです。

少なくとも、次の問題があります。

1. 「評価したつもり」が発生しやすい

テストを少し走らせた、人がざっと見た、CI が通った。
これだけでは、本当に何をもって pass としたのかが曖昧なままです。

2. 出力だけを見て process failure を見落としやすい

artifact が一見正しく見えても、

禁止された capability を使っている
required approval を飛ばしている
scope を逸脱している
handoff 情報が欠落している
memory promotion に値しないノイズを混ぜている

といった問題がありえます。

3. delta の型ごとに評価の仕方が違う

artifact、decision、failure memory、operational memory、recovery point は、同じ評価基準では扱えません。
にもかかわらず、contract がなければ「全部なんとなくレビューする」へ流れやすくなります。

4. multi-actor / multi-session で評価条件が失われやすい

長い process では、誰がどの条件で何を判断するはずだったかが途中で薄れます。
Eval Contract がないと、後続の actor は何を満たせばよいか分からなくなります。

5. merge と approval が混線しやすい

評価で pass したことと、authority を持つ actor がそれを採用してよいと ratify したことは別です。
Eval Contract が明示されていないと、この二つが簡単に混ざります。

だから PCE 2.0 では、
評価は出来事ではなく契約として先に定義されるべき
だと考えます。

Eval Contract の中心的な問い

Eval Contract が答えるべき問いは、少なくとも次のとおりです。

何を評価対象にするのか
その評価の目的は何か
何をもって適合とするのか
どの evidence が必要か
誰または何が評価するのか
どの evaluator が blocking で、どれが advisory か
どの verdict で pass / fail / escalate / retry とするのか
評価結果をどう記録し、どの遷移につなげるのか
この契約はどの scope / phase / delta type に有効か
いつ失効し、いつ新しい contract が必要になるのか

この問いに答えられないなら、その評価設計はまだ contract ではなく、ただの慣習や印象に留まっています。

Eval Contract は何ではないか

輪郭をはっきりさせるために、まず何ではないかを書いておきます。

1. 単なる test suite ではない

テスト群は Eval Contract の一部になりえますが、全部ではありません。
何を subject とし、どの条件で fail とし、どの authority が後続に関わるかまで必要です。

2. 単なる rubric ではない

rubric も一部です。
しかし rubric だけでは evaluator、evidence、decision rule、failure handling が抜けます。

3. 単なる evaluator ではない

CI、reviewer、policy engine は evaluator になれますが、
それらがどう協調して verdict を形成するかは contract が決めます。

4. 単なる approval ではない

approval は authority の行使です。
eval は criteria に基づく判断です。
Eval Contract は approval を置き換えません。

5. 単なる評価結果ではない

pass / fail / score / comments は evaluation result です。
Eval Contract は、その結果をどう生成するかを定める事前の規則です。

6. 単なる後付けの説明ではない

「今回はこう見た」は evaluation note にはなりますが、contract ではありません。
contract は評価前に有効である必要があります。

Eval Contract が評価する対象

PCE 2.0 では、評価対象は artifact だけではありません。
Eval Contract の subject は少なくとも次の型を取りえます。

1. Artifact Subject

code patch
spec update
test suite addition
configuration change
runbook update

2. Decision Subject

accepted rationale
chosen trade-off
approved interpretation
superseding decision

3. Failure / Rejection Subject

reusable failure lesson
rejected alternative summary
anti-pattern note
do-not-repeat memory candidate

4. Operational Memory Subject

playbook candidate
checklist candidate
skill refinement
workflow pattern candidate

5. Evaluation Subject

evaluation result itself
new threshold proposal
baseline update
grader output quality

6. Governance Subject

approval rule proposal
scope restriction clarification
escalation rule update
audit annotation

7. Recovery Subject

checkpoint integrity
resumable summary quality
recovery package completeness

8. Process / Trace Subject

execution trace
handoff package
procedural validity
scope compliance of a whole phase

このように Eval Contract は、
何を評価するかの ontology を広く持つ 必要があります。

Frame-level Contract と Item-level Contract

Eval Contract は、一つの粒度に固定されません。
PCE 2.0 では、少なくとも二層で考えるのが自然です。

1. Frame-level Eval Contract

Process Frame に埋め込まれる評価契約です。
その frame 全体に共通する baseline を定めます。

たとえば、

required regression suite
mandatory reviewer check
scope violation policy
required evidence for completion

などです。

2. Item-level Eval Contract

個別の Process Delta item に紐づく評価契約です。
artifact delta、decision delta、memory candidate など、それぞれに固有の評価経路を持てます。

frame-level contract がデフォルトを与え、
item-level contract がそれを継承・具体化・追加制約化する、という形が基本です。

概念的には、次のように書けます。

effective_eval_contract(delta_item) =
  inherit(frame_eval_contract)
  + specialize(item_type_contract)
  + apply(item_specific_overrides)

ここで重要なのは、item-level contract が frame-level baseline を黙って弱めてはならないことです。
必要なら明示的な reframe や authority が要ります。

Eval Contract の構成要素

PCE 2.0 では、Eval Contract は少なくとも次の成分から成ります。

1. Subject

何を評価するのか。
artifact、decision、memory candidate、trace などの対象型と scope を定めます。

2. Purpose

この評価の目的は何か。
merge readiness の判断なのか、memory promotion の判断なのか、policy compliance の確認なのかを定めます。

3. Criteria

何をもって適合とするか。
correctness、completeness、policy compliance、reusability、procedural validity などです。

4. Required Evidence

判定に必要な evidence を定めます。
tests、logs、review notes、trace refs、rollback note、rationale などが入りえます。

5. Evaluator Set

誰または何が評価に参加するかを定めます。

CI
static analyzer
human reviewer
policy engine
trace grader
memory writer
incident owner

などが evaluator になりえます。

6. Blocking / Advisory Classification

どの evaluator の verdict が promotion をブロックしうるかを定めます。

blocking evaluator
fail すれば pass できない
advisory evaluator
参考信号を与えるが、それ単独では block しない

この区別は重要です。
PCE 2.0 では、全部の評価が同じ重みではありません。

7. Decision Rule

複数の evaluator の結果をどう合成して final verdict を出すかを定めます。

たとえば、

all blocking evaluators must pass
no policy violation may exist
reviewer approval is required after CI pass
if disagreement occurs, escalate
score must exceed threshold X

などです。

8. Output / Verdict Format

評価結果をどの形で記録するかを定めます。

pass / fail
conditional pass
insufficient evidence
escalate
retry required
numeric score
rubric profile
required fixes list

9. Failure Handling

fail や inconclusive のとき、どう遷移するかを定めます。

reject
rework
rollback
replan
escalate
remain provisional

10. Validity / Freshness

この contract がどの scope / phase / version / policy state に対して有効かを定めます。
scope が変わったのに古い contract を流用してはなりません。

Blocking と Advisory の違い

この区別は実務上とても重要です。

Blocking Evaluator

その evaluator の fail は、少なくとも当該 subject の昇格を阻止します。

例:

required regression tests
policy compliance check
mandatory review pass
checkpoint integrity check

Advisory Evaluator

意思決定に有用な signal を与えるが、単独では昇格を止めません。

例:

style preference score
non-critical optimization suggestion
heuristic maintainability note
secondary trace commentary

ただし advisory だから無視してよいとは限りません。
contract は、advisory result を escalation 条件や future review note に結びつけることができます。

重要なのは、重みの違いが明示されていること です。

Outcome Evaluation と Process Evaluation

Eval Contract は、artifact quality だけを扱うものではありません。
PCE 2.0 では評価対象を少なくとも二軸で考えます。

1. Outcome Evaluation

出来上がった結果が要求を満たすかを評価します。

tests pass
spec compliance
output schema validity
performance threshold
regression absence

2. Process Evaluation

どうやってそこに到達したかを評価します。

scope compliance
required handoff completeness
prohibited capability non-use
approval sequence integrity
trace quality
memory promotion discipline

Eval Contract は、このどちらを評価するのかを明示しなければなりません。
一部の contract は outcome だけを見るかもしれませんし、
高リスクな contract は process 軸を必須にするかもしれません。

詳しくは Outcome vs Process を参照します。

Eval Contract と Approval の違い

PCE 2.0 では、eval と approval は区別されます。

Eval

criteria と evidence に基づいて適合性を判断すること。

Approval

必要な authority を持つ actor が、その subject を制度的に採用してよいと ratify すること。

したがって、

eval pass でも approval がなければ merge できないことがある
approval authority があっても eval がなければ merge できない
approval は evaluator の一人であることもあるが、概念上は同一ではない

という関係になります。

概念的には、次のように書けます。

mergeable(item) iff
  eval_verdict(item, contract) satisfies decision_rule(contract)
  and required_approval(item) is granted

この区別があることで、PCE 2.0 は
判断と ratification を混同しない ようにできます。

Eval Contract と Responsibility Bundle の関係

Eval Contract は、誰が何を評価するかを定めますが、
それは Responsibility Bundle における evaluation_authority と対応していなければなりません。

ただし、両者は同じものではありません。

Responsibility Bundle

ある actor が評価責任を持つかどうかを定める。

Eval Contract

その評価が、何を、どう、どの evidence で、どの rule で行われるかを定める。

つまり、

bundle は 評価責任の所在
contract は 評価手続きの内容

です。

このため、ある actor が evaluator になれるのは、bundle 上そうである場合に限られます。
逆に bundle があっても、contract がなければ評価は曖昧なままです。

Eval Contract と Process Delta の関係

Process Delta の各 item は、必要に応じて required_eval を持ちます。
Eval Contract は、その required_eval を具体化するものです。

Artifact Delta の場合

required tests
mandatory review
policy checks

Decision Delta の場合

rationale review
goal-owner confirmation
trade-off adequacy check

Memory Candidate の場合

reusability review
repeatability evidence check
noise rejection check

Recovery Delta の場合

checkpoint integrity
resumability completeness

このため Eval Contract は、
delta を「評価可能な change set」にするための制度でもあります。

Eval Contract と Durable Project State の関係

Eval Contract 自体も、project によっては durable に保持されるべき対象です。

理由は単純です。
どんな criteria で pass とみなしてきたかは、project の品質制度の一部だからです。

Durable 化されうるものには、たとえば次があります。

frame-level evaluation baselines
required review checklists
accepted thresholds
policy-aligned grading rules
regression suites as contract components

これらは Durable Project State の evaluation_memory や governance_records に入りえます。

ただし、その場合でも contract は versioned であるべきです。
古い contract のもとで pass した item と、新しい contract のもとで pass した item を混同してはなりません。

Eval Contract のライフサイクル

Eval Contract 自体にもライフサイクルがあります。

1. Define

frame 設計時または policy 設計時に contract を定義する。

2. Bind

特定 frame、phase、delta type、delta item に contract を結びつける。

3. Execute

actual evaluation を走らせる。

4. Record

verdict、evidence、comments、version を evaluation record として記録する。

5. Consume

approve / reject / rework / promote / merge などの transition で結果を消費する。

6. Supersede

criteria や baselines が変わったら、新しい contract で古い contract を置き換える。

ここで重要なのは、
contract と result を分けること
です。

contract は規則
result は実行結果

です。

Eval Contract の最小スキーマ

PCE 2.0 における最小スキーマは、次のように置けます。

eval_contract:
  contract_id:
  version:
  scope:
  subject:
    kind:
    target:
  purpose:
  criteria:
  required_evidence:
  evaluators:
    - evaluator:
      role:
      mode:
      blocking: true | false
  decision_rule:
  verdict_schema:
  failure_handling:
  escalation_rule:
  validity:
    applies_when:
    expires_when:
  provenance:
  notes:

もう少し item 指向に書くと、次のようになります。

eval_contract:
  contract_id:
  version:
  scope:
    frame:
    phase:
    delta_kind:
  subject:
    kind:
    scope:
  purpose:
  criteria:
    - criterion_id:
      description:
      measurement:
      threshold:
  required_evidence:
    - evidence_type:
      required: true | false
  evaluators:
    - evaluator_ref:
      authority_basis:
      blocking: true | false
      output:
  decision_rule:
    type:
    parameters:
  verdict_schema:
    states:
      - pass
      - fail
      - conditional_pass
      - insufficient_evidence
      - escalate
  failure_handling:
    on_fail:
    on_inconclusive:
  validity:
    applies_to_versions:
    invalidated_by:
  provenance:

このスキーマで重要なのは、次の点です。

subject がある
criteria と required evidence がある
evaluator ごとに blocking / advisory がある
decision rule がある
verdict schema がある
failure handling と validity がある

つまり Eval Contract は、
評価対象・評価者・評価方法・判定規則・失敗時遷移
を一体で持つ構造です。

小さな例

「checkout にクーポン併用制約を追加する」frame における、artifact delta 向け contract の例です。

eval_contract:
  contract_id: eval.feature.checkout.coupon-combination.artifact.v1
  version: 1
  scope:
    frame: feature.checkout.coupon-combination
    phase: implementation_completed
    delta_kind: artifact
  subject:
    kind: artifact_delta
    target: code_patch_and_related_tests
  purpose: >
    code patch を canonical artifacts に昇格してよいかを判断する。
  criteria:
    - criterion_id: regression_integrity
      description: required regression suite がすべて通ること
      measurement: ci_test_result
      threshold: all_required_green
    - criterion_id: scope_compliance
      description: payment gateway changes が含まれていないこと
      measurement: reviewer_and_policy_check
      threshold: no_scope_violation
    - criterion_id: spec_alignment
      description: approved spec と整合していること
      measurement: reviewer_check
      threshold: approved
    - criterion_id: rollback_feasibility
      description: rollback path が存在し記録されていること
      measurement: review_note
      threshold: present
  required_evidence:
    - evidence_type: ci_report
      required: true
    - evidence_type: code_diff
      required: true
    - evidence_type: approved_spec_summary
      required: true
    - evidence_type: rollback_note
      required: true
  evaluators:
    - evaluator:
        ref: ci_evaluator
      role: deterministic_test_runner
      mode: automated
      blocking: true
    - evaluator:
        ref: policy_checker
      role: scope_policy_check
      mode: automated
      blocking: true
    - evaluator:
        ref: reviewer
      role: human_review
      mode: human
      blocking: true
    - evaluator:
        ref: maintainability_scorer
      role: advisory_quality_signal
      mode: automated
      blocking: false
  decision_rule:
    type: all_blocking_must_pass
    parameters:
      advisory_notes_do_not_block: true
  verdict_schema:
    states:
      - pass
      - fail
      - insufficient_evidence
      - escalate
  failure_handling:
    on_fail:
      - reject_artifact_delta
      - create_rework_transition
    on_inconclusive:
      - request_missing_evidence
      - remain_provisional
  escalation_rule:
    when:
      - reviewer_detects_spec_ambiguity
    target: product_owner
  validity:
    applies_when:
      - frame_scope == feature.checkout.coupon-combination
      - approved_spec_version == v1
    expires_when:
      - spec_reframed
      - governance_rule_changed
  provenance:
    defined_by: product_owner

この例で重要なのは、評価が

何に対して
何のために
どの evidence で
誰が
どの rule で

行われるかが明示されていることです。

Memory Promotion 向けには別 contract が必要

artifact の contract を、そのまま memory promotion に使うべきではありません。
PCE 2.0 では、memory 候補は独自の contract を持つべきです。

たとえば operational memory candidate なら、次の criteria が必要かもしれません。

局所事情ではなく再利用可能か
一回限りの偶然ではなく repeatability があるか
ノイズや speculative note ではないか
将来の frame に対して本当に有用か
superseded されやすい一時知識ではないか

したがって memory_write_authority と memory promotion review は、
artifact review とは別の contract で扱う方が自然です。

詳しくは Memory Promotion Rules を参照します。

Eval Contract の不変条件

PCE 2.0 では、少なくとも次の不変条件を置きます。

1. Every mergeable subject has an eval contract

canonical または durable へ昇格しうる subject は、明示的な Eval Contract を持たなければなりません。

2. Contract must identify subject and purpose

何を、何のために評価するのかが曖昧であってはなりません。

3. Criteria and decision rule must be explicit

criteria だけでなく、複数結果をどう合成するかまで必要です。

4. Blocking and advisory signals must be distinguishable

どれが promotion を止めうるのかが明確でなければなりません。

5. Evaluator and approver must not be conflated by default

同一人物や同一仕組みが両方を担うことはありえても、概念上は分けて扱うべきです。

6. Contract validity must be bounded

scope や policy が変わったのに、古い contract を黙って流用してはなりません。

7. Evaluation result must trace back to contract version

どの contract version で pass / fail になったか追跡できなければなりません。

8. Memory promotion requires memory-appropriate criteria

artifact quality だけで memory promotion を判断してはなりません。

いつ新しい Eval Contract を切るべきか

実務上は、どこで新しい contract が必要になるかが重要です。
典型条件は次のとおりです。

1. Subject の kind が変わるとき

artifact と decision と memory candidate は、別 contract にするのが自然です。

2. Success criteria が変わるとき

frame の達成条件が変われば、評価条件も変わります。

3. Governance / policy が変わるとき

新しい approval rule や safety rule が入ったなら、contract も更新が必要です。

4. Authority boundary が変わるとき

新しい reviewer、new risk tier、different approval path が必要になれば contract も変わります。

5. Evidence shape が変わるとき

required evidence が diff から trace に変わる、rollback note が必須になる、などです。

6. Artifact から process 評価へ重心が移るとき

高リスク変更や長時間タスクでは、process validity を含む contract が必要になります。

7. Memory promotion を始めるとき

残す対象が artifact ではなく reusable memory なら、専用 contract が必要です。

短く言えば、
subject、criteria、evidence、authority、policy のいずれかが意味的に変わるなら、新しい Eval Contract を切る
のが基本です。

最低限の自己点検

ある評価設計が Eval Contract と呼べるかは、次で点検できます。

何を評価するのか subject を明示できるか
何のための評価か purpose を言えるか
criteria と decision rule を分けて書けるか
required evidence が明示されているか
evaluator set に blocking / advisory の違いがあるか
evaluation authority と approval authority を混同していないか
fail / inconclusive 時の遷移が決まっているか
contract の scope と validity が書けるか
result が contract version に結びついて記録されるか
memory promotion や process evaluation に対して、別 contract を設計できるか

このどれかが欠けるなら、その評価はまだ契約として十分に定義されていません。

暫定的なまとめ

Eval Contract が言っていることは、最終的には次の一文に集約できます。

評価とは、結果を見て後から感想を言うことではない。
何を、どの evidence で、誰が、どの rule で評価し、その verdict をどの遷移へ結びつけるかを、先に定める契約である。

PCE 2.0 において、eval は任意の補助作業ではありません。
それは merge と promotion を支える制度です。
そして Eval Contract は、その制度を曖昧さなく実装するための核です。

だから Eval Contract は、単なる rubric でも test list でもありません。
それは、PCE 2.0 において 変化を採用してよいかを決める評価上の責任境界 です。