Evaluation

定義

Evaluation

Evaluation とは、ある Actor が、ある Process Frame のある局面において、
特定の subject に対して、
所定の criteria と evidence に基づき、その subject が次の判断や遷移の材料として十分かどうかを判定する責任 である。

それは単なる「見て感想を言うこと」ではなく、
subject binding、criteria application、evidence sufficiency judgment、outcome/process distinction、verdict emission、re-evaluation trigger detection、evaluation record production を含む。

より短く言えば、Evaluation とは
「この差分・この結果・この候補・この過程を、何をもって pass / fail / insufficient / escalate とみなすのかを判定する責任」
である。

PCE 2.0 において評価は、作業の末尾におかれる optional な確認ではない。
それは process の admissibility を決める中心機能であり、
No merge without eval を支える責任である。

この意味で Evaluation は、
Responsibility-first を judgment 側から具体化した責任である。

なぜ Evaluation が必要なのか

PCE 2.0 が Evaluation を独立責任として置くのは、
「何かが生成されたこと」と「それを process 上で十分だと判断できること」が別だからである。

少なくとも、次の問題がある。

1. execution は結果を生むが、十分性までは保証しない

実装、要約、調査、memory candidate 抽出といった execution は、subject を生み出す。
しかし execution actor が subject を生んだことは、それが十分であることを保証しない。

code patch は動くかもしれない
summary は読みやすいかもしれない
failure note はもっともらしいかもしれない

しかし、それが本当に criteria を満たすかは別問題である。

2. approval は authority だが、criteria judgment そのものではない

approver は subject を ratify する。
しかし approval の前提として、何らかの評価が必要であることが多い。

tests は十分か
rollback note はあるか
rationale は納得できるか
candidate memory は再利用に耐えるか

これらは evaluation の役割であり、approval と同一ではない。

3. AI 時代には process 自体も評価対象になる

PCE 2.0 では、評価対象は artifact だけではない。
少なくとも次も subject になりうる。

handoff package
recovery readiness
approval prerequisites
process trace
memory candidate
failure lesson
decision rationale

したがって Evaluation は、単なる artifact QA ではない。

4. outcome と process はずれうる

Outcome vs Process で述べたように、

outcome は良いが process が悪い
outcome は悪いが process learning は高い

ということが起こりうる。
この区別を扱える責任が必要である。

5. durable state を汚さないために評価が必要である

特に memory promotion や canonical merge では、
「出たから入れる」では project state が壊れる。
何を前提にしてよいかを判断する責任が必要になる。

だから Evaluation は、
subject の十分性を criteria と evidence で判定する責任
として、独立に扱われる。

Evaluation は何ではないか

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

1. 単なる Approval ではない

approval は authority による ratification である。
evaluation は criteria に基づく判定である。
両者はしばしば連動するが、同一ではない。

2. 単なる Execution ではない

subject を作ることと、その subject を評価することは別である。
同じ actor が両方を担う場合でも、責任としては分離して扱うべきである。

3. 単なる Goal Ownership ではない

goal owner は、何を達成したいかと何をもって完了とするかを保持する。
evaluator は、その goal に照らして個別 subject が十分かを判定する。

4. 単なる Memory Writing ではない

memory candidate が promote-worthy かを評価することと、
実際に durable state へ書くことは別である。

5. 単なる metrics 観測ではない

Process Metrics は process を観測する。
Evaluation は、個別 subject に対して verdict を出す。

6. 単なる “見ること” ではない

誰かが眺めた、読んだ、気になった、というだけでは evaluation ではない。
subject、criteria、evidence、verdict が必要である。

7. 単なる score 計算ではない

score があることは一つの形だが、
PCE 2.0 において evaluation は pass / fail / insufficient evidence / escalate などの process effect を伴う判断である。

Evaluation が含む責任

PCE 2.0 では、Evaluation は少なくとも次の責務を含む。

1. Subject Identification

何を評価しているのかを定める。

例:

artifact delta
decision delta
failure memory candidate
handoff package
recovery point
frame completion readiness

2. Criteria Application

その subject に適用される criteria を選び、適用する。
ここで criteria は Eval Contract によって定義される。

3. Evidence Sufficiency Judgment

判定に必要な evidence が十分かを確認する。
evaluator は「合格 / 不合格」だけでなく、
まだ判定不能である ことも責任を持って言わなければならない。

4. Outcome Judgment

結果物として十分かを判断する。
たとえば correctness、completeness、requirement fit などである。

5. Process Judgment

その subject がどのような過程で作られたかを判断する。
たとえば procedural validity、governance validity、promotion discipline などである。

6. Verdict Emission

pass / fail / conditional / insufficient evidence / escalate などの verdict を出す。

7. Evaluation Record Production

何を、どの criteria で、どの evidence に基づいて、誰または何が判定したかを記録する。

8. Re-evaluation Trigger Detection

subject が stale になった、governance drift が起きた、evidence が更新された、
といった理由で、以前の評価が無効化される条件を扱う。

Evaluation の対象は何か

PCE 2.0 において Evaluation の subject は広い。
少なくとも次のような subject を評価しうる。

1. Artifact Subject

code patch
spec update
test additions
config changes
generated summary

2. Decision Subject

accepted rationale
interpretation decision
trade-off proposal
boundary clarification

3. Failure / Rejection Subject

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

4. Operational Memory Subject

checklist candidate
playbook candidate
workflow note
reusable instruction candidate

5. Governance Subject

approval rule proposal
scope clarification
escalation route
policy note

6. Recovery Subject

recovery point integrity
resumable summary
rollback anchor validity
resume readiness

7. Process / Trace Subject

handoff completeness
gate continuity
procedural compliance
transition chain validity

この広さが重要である。
PCE 2.0 における evaluation は、artifact testing に還元されない。

Outcome Evaluation と Process Evaluation

Evaluation responsibility の中でも、特に重要なのは
Outcome と Process を区別することである。

Outcome Evaluation

その subject が結果として十分かを問う。

例:

code patch が requirements を満たしているか
summary が必要項目を含んでいるか
memory candidate が future process に有用か

Process Evaluation

その subject が妥当な過程を経て成立しているかを問う。

例:

required gate を通っているか
prohibited capability を使っていないか
evidence が traceable か
stale context を流用していないか
handoff / recovery continuity が保たれているか

評価責任を持つ actor は、subject に応じてこの両軸を使い分ける必要がある。
詳しくは Outcome vs Process を参照。

Evaluation と Eval Contract の違い

この区別は非常に重要である。

Eval Contract

何を、誰が、どの criteria で、どの evidence に基づいて、どの decision rule で評価するかを定める契約である。

Evaluation

その contract を実際に適用し、判定を出す責任である。

つまり、

Eval Contract は 評価手続きの定義
Evaluation は その手続きを担う責任

である。

同じ evaluator actor が存在しても、contract がなければ評価は曖昧になる。
逆に contract があっても、それを担う evaluator がいなければ process は動かない。

Evaluation と Approval の違い

Evaluation

criteria と evidence に基づく adequacy judgment

Approval

authority に基づく ratification

evaluation で pass しても、approval が必要な subject はある。
逆に approval authority があっても、required eval を飛ばして先へ進めてはならない。

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

approval_open(subject) iff
  required_evaluation(subject) is satisfied
  and required_evidence(subject) is present
  and approval_authority(subject) is available

つまり Approval はしばしば Evaluation の上に乗る。

Evaluation と Goal Ownership の違い

goal owner は what counts as success for the frame を保持する。
evaluator は whether this subject satisfies applicable criteria を判断する。

goal owner が

success criteria を定める
reframe を認める
close を accept する

のに対し、evaluator は

contract に基づいて判定を出す
evidence insufficiency を指摘する
fail / pass / escalate を判断する

という役割を持つ。

同じ actor が両方を持つことはありうるが、責任の性質は異なる。

Evaluation と Memory Writing の違い

memory promotion では、この差が重要になる。

evaluator

memory candidate が promote-worthy かどうかを判定する

memory writer

durable collection へ actual write / promotion を実行する

たとえば evaluator が
「この failure lesson は reusable である」
と判断しても、
最終的な canonical / provisional の選択や durable write は memory writer の責任かもしれない。

したがって Evaluation はしばしば、memory promotion path の admissibility を与える責任である。

Evaluation と Process Metrics の違い

Process Metrics は、process を観測する指標群である。
Evaluation は、個別 subject に対する verdict を出す責任である。

Metrics がすること

継続的な signal を与える
問題の傾向を見る
改善対象を特定する

Evaluation がすること

個別 subject の adequacy を判定する
next transition の可否に影響する
merge / promotion / close の前提になる

つまり metrics は観測、evaluation は judgment である。

Evaluation authority は actor symmetry の中でどう分布するか

PCE 2.0 では actor の分析上の対称性を認める。
そのため Evaluation は、Goal Ownership や Approval よりも広い actor に割り当てやすい。

人間が evaluator になる場合

reviewer
domain expert
product owner
memory writer

AI / tool が evaluator になる場合

CI evaluator
static analyzer
policy checker
trace grader
automated rubric evaluator

hybrid evaluator

AI が preliminary evaluation
human が final evaluation
blocking / advisory を分担する

この意味で Evaluation responsibility は、PCE 2.0 の中でも比較的 automatable である。
ただし、actor であることから evaluation authority が自動的に出るわけではない。
subject scope と contract に基づいて明示的に配分される必要がある。

Evaluation のトポロジ

評価責任は常に single evaluator とは限らない。
少なくとも次の topology を区別できる。

1. Single Evaluator

一人 / 一系統が判定する。

2. Blocking + Advisory Split

blocking evaluator と advisory evaluator が分かれる。

例:

CI = blocking
maintainability scorer = advisory

3. Ordered Evaluation Chain

複数の evaluator が順番に評価する。

例:

automated checks
human review
memory promotion review

4. Conjunctive Evaluation

複数 evaluator の条件を全て満たす必要がある。

5. Heterogeneous Evaluation Set

artifact quality、process validity、governance validity を別 evaluator が見る。

6. Escalatory Evaluation

通常 evaluator が判断不能な subject を higher authority や specialized evaluator に引き上げる。

PCE 2.0 では、topology を明示しないと
「誰が fail を出したのか」「何が blocking だったのか」が曖昧になる。

Evaluation の主要操作

Evaluation responsibility は static ではない。
少なくとも次の操作がある。

Assign

ある actor に、ある subject scope の evaluation responsibility を割り当てる。

Bind Subject

その evaluator がどの subject を評価するのかを結びつける。

Inspect Evidence

required evidence が揃っているかを見る。

Apply Contract

applicable eval contract を適用する。

Emit Verdict

pass / fail / conditional pass / insufficient evidence / escalate を出す。

Record Evaluation

判定結果、evidence、criteria、rationale を記録する。

Invalidate Verdict

subject や evidence が変わった結果、以前の評価を stale / invalid にする。

Request Re-evaluation

再提出、再計測、再実行を要求する。

Escalate

自分の contract scope を越える曖昧性や governance 問題を引き上げる。

Evaluation は evidence insufficiency を言える責任である

PCE 2.0 における evaluation では、
「pass か fail か」だけでは不十分である。

特に重要なのは、
insufficient evidence
を正式な verdict として扱うことだ。

なぜか。

evidence が足りないのに pass とすると Corrupt Success が増える
evidence が足りないのに fail とすると productive iteration を壊しやすい
inadequate package / bad handoff / bad instrumentation の問題が見えなくなる

したがって evaluator は、
まだ判断可能状態に達していないことを責任を持って宣言する
必要がある。

Evaluation は stale になりうる

評価結果は永続的真理ではない。
次のようなことが起きると stale になりうる。

1. Subject Drift

artifact や candidate 自体が変わった

2. Evidence Drift

テスト結果や supporting refs が変わった

3. Governance Drift

policy、scope、approval requirements が変わった

4. Contract Drift

eval contract version が変わった

5. Context Drift

以前の evaluation が旧前提に依存していた

このため Evaluation responsibility には、
再評価が必要な条件を検知する責務も含まれる。

Evaluation と Handoff の関係

evaluation そのものも handoff に乗ることがある。

評価のための handoff

execution actor → evaluator
child frame → parent evaluator
reviewer → memory writer
runtime → resume evaluator

評価結果の handoff

evaluator → approver
evaluator → executor for rework
evaluator → memory writer
evaluator → incident owner

このとき handoff package には少なくとも次が必要である。

subject
applicable contract
evidence refs
unresolved issues
verdict or pending state
next expected action

したがって Evaluation は、単独で完結することもあるが、
多くの場合は governed handoff chain の一部である。

Evaluation と Checkpoint / Recovery の関係

long-running process では evaluation も途中で止まる。
そのため Checkpoint and Recovery と結びつく。

evaluation-wait checkpoint に必要なもの

subject ref
required evaluator
applicable contract ref
evidence state
pending verdict

recover 時に必要なこと

contract version が変わっていないか
evidence が still valid か
subject が stale でないか
blocking/advisory topology が変わっていないか

つまり Evaluation は単発の確認ではなく、
pending / recovered / resumed しうる process responsibility である。

Evaluation の最小スキーマ

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

evaluation_responsibility:
  actor_ref:
  frame_id:
  subject_scope:
  applicable_contracts:
  evaluation_axes:
    outcome: true | false
    process: true | false
  blocking_mode:
    # blocking | advisory | mixed
  allowed_verdicts:
    - pass
    - fail
    - conditional_pass
    - insufficient_evidence
    - escalate
  required_evidence:
  escalation_path:
  invalidation_conditions:
  record_requirements:
  validity:
    active_when:
    expires_when:
  provenance:

bundle の一部として書くなら、もう少し簡潔に次のようにも置ける。

evaluation:
  subjects:
  contracts:
  axes:
    - outcome
    - process
  blocking_mode:
  required_evidence:
  allowed_verdicts:
  re_evaluation_triggers:
  escalation_path:
  record_requirements:

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

subject scope がある
applicable contract がある
outcome / process の軸がある
blocking / advisory を持てる
insufficient evidence と re-evaluation が扱える
record と invalidation を持つ

つまり Evaluation は、
単なる「良い悪いを言う係」ではなく、
contract-bound adequacy judgment responsibility として扱われる。

小さな例

feature.checkout.coupon-combination frame における reviewer の evaluation は、たとえば次のように書ける。

evaluation_responsibility:
  actor_ref: reviewer
  frame_id: feature.checkout.coupon-combination
  subject_scope:
    - artifact_delta.code_patch
    - decision_delta.accepted_rationale
  applicable_contracts:
    - eval.feature.checkout.coupon-combination.artifact.v1
  evaluation_axes:
    outcome: true
    process: true
  blocking_mode: blocking
  allowed_verdicts:
    - pass
    - fail
    - insufficient_evidence
    - escalate
  required_evidence:
    - code_diff
    - ci_report
    - approved_spec_summary
    - rollback_note
  escalation_path:
    - product_owner
  invalidation_conditions:
    - code_diff_changes
    - approved_spec_changes
    - governance_rule_changes
  record_requirements:
    - evaluation_record
    - rationale_note
  provenance:
    assigned_by: feature.checkout.coupon-combination

一方で ci_evaluator は次のようにもっと限定的でよい。

evaluation_responsibility:
  actor_ref: ci_evaluator
  frame_id: feature.checkout.coupon-combination
  subject_scope:
    - artifact_delta.code_patch
  applicable_contracts:
    - eval.feature.checkout.coupon-combination.artifact.v1
  evaluation_axes:
    outcome: true
    process: false
  blocking_mode: blocking
  allowed_verdicts:
    - pass
    - fail
    - insufficient_evidence
  required_evidence:
    - test_suite_definition
    - runnable_patch
  escalation_path: []
  invalidation_conditions:
    - code_diff_changes
    - test_definition_changes
  record_requirements:
    - ci_report
  provenance:
    assigned_by: governance_record.checkout_required_regression

この例で重要なのは、両者とも evaluator だが、

subject scope
axes
evidence
escalation path
blocking mode

が違う点である。

Evaluation の不変条件

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

1. Every mergeable or promotable subject has an evaluator

merge / promotion に進む subject には、何らかの evaluation responsibility が必要である。

2. No evaluation without explicit subject

何を評価しているのか曖昧な evaluation は不完全である。

3. No evaluation without contract or equivalent criteria basis

criteria basis のない evaluation は、印象論に戻りやすい。

4. Evaluation does not imply approval

pass verdict は ratification ではない。

5. Evaluation does not imply durable write

評価済みであっても、memory write authority や approval が別に必要なことがある。

6. Insufficient evidence is a legitimate verdict

根拠不足を明示的 verdict として扱わなければならない。

7. Evaluation results must be attributable

誰または何が、どの contract と evidence に基づいて判定したか追える必要がある。

8. Stale subject must not inherit stale verdict silently

subject や evidence が変わったら old verdict は無条件に流用してはならない。

いつ Evaluation を分けるべきか

次の条件があるなら、一つの evaluation responsibility ではなく分割を考えるべきである。

1. Subject type が変わるとき

artifact、decision、memory candidate、recovery readiness では必要な judgment が違う。

2. Outcome と Process を別 actor が見るとき

CI が outcome を見て、reviewer が process を見る、などである。

3. Blocking / Advisory が分かれるとき

強制力のある evaluator と助言的 evaluator を分ける必要がある。

4. Evidence modality が違うとき

test report を扱う evaluator と trace / rationale を扱う evaluator は分けやすい。

5. Governance sensitivity が違うとき

resume approval 前の risky evaluation や policy-sensitive memory candidate などは、専用 evaluation が必要である。

6. Memory promotion を独立評価したいとき

artifact correctness と memory worthiness は別なので、専用 evaluation を持つべきである。

短く言えば、
subject、criteria、evidence、blocking mode、risk のいずれかが意味的に変わるなら evaluation を分ける
のが基本である。

最低限の自己点検

ある process が evaluation-aware かどうかは、次で点検できる。

何を評価しているのか subject を言えるか
applicable contract を言えるか
outcome と process を分けて見ているか
evaluator と approver を混同していないか
required evidence が明示されているか
insufficient evidence を正式 verdict として扱えるか
stale verdict の invalidation 条件があるか
blocking / advisory の違いがあるか
evaluation record を traceable に残せるか
evaluation が merge / promotion / close のどこに効くか説明できるか

このどれかが欠けるなら、その process はまだ evaluation を十分に責任として扱っていない。

暫定的なまとめ

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

process において「十分である」は、作った actor の手応えでも、approver の権限でも決まらない。
何を評価対象とし、どの criteria と evidence に基づいて、pass / fail / insufficient / escalate と判断するかを引き受ける責任が evaluation である。

PCE 2.0 において evaluator は、単なる検査役ではない。
それは subject を future process の材料として使ってよいかどうかを、criteria と evidence の側から保証する責任を持つ。

だから Evaluation は、単なるテスト工程ではない。
それは、PCE 2.0 において 結果・過程・根拠の十分性を process progression に接続する adequacy-judgment responsibility である。