No merge without eval

原理

No merge without eval

PCE 2.0 において、merge は単なる保存や反映ではない。
それは process delta を durable project state に昇格させ、
以後の process の前提として採用する行為である。
したがって、明示的な eval を通過していない delta は merge してはならない。

より形式的に言えば、
将来の process が依拠する状態変更は、評価されていなければならない。

この原理が言いたいのは単純です。
生成されたから残すのではない。評価を通ったから残す。

PCE 2.0 において、merge は付随的な後処理ではありません。
それは、将来の仕事の初期条件を書き換える行為です。
だからこそ、merge は常に eval を前提にしなければなりません。

なぜこの原理が必要なのか

AI 時代の開発では、もっとも危険なのは「間違った出力」そのものだけではありません。
むしろ危険なのは、評価されていない差分が project state に紛れ込み、それが次の process の前提になること です。

ここで起こる問題は少なくとも 4 つあります。

1. 見かけ上の成功が、そのまま健全な成功とは限らない

ある結果が一見うまく見えても、次のような可能性があります。

本来通すべき手順を飛ばしている
禁止された capability を使っている
根拠が失われている
必要な検証を経ていない
偶然に正解らしく見えているだけで、再現性がない

このとき問題なのは、誤った結果を一時的に生成したことだけではありません。
それを 正しい履歴として残してしまうこと です。

2. agentic systems では delta が将来の前提になる

PCE 2.0 の world では、生成物・判断・却下・評価結果・運用知が次の process の初期条件になります。
そのため、merge されるものは単なる output ではなく、将来の context compilation の材料 です。

評価されていない delta を混ぜることは、
将来の actor-local context を汚染することと同じです。

3. multi-step / multi-turn / stochastic な実行では、出力だけ見ても足りない

長時間・多段・多主体の process では、最終出力だけでは十分に判断できません。
どのような手順を通ったか、どの capability を使ったか、どこで失敗し、どう回復したかも品質に関わります。

したがって、merge の条件は「出力があったこと」ではなく、
その差分が適切な eval contract に照らして妥当と判断されたこと でなければなりません。

4. durable state は倉庫ではなく制度である

PCE 2.0 の Durable Project State は、
「とりあえず貯める場所」ではありません。

それは、今後の process が依拠してよいとみなされた内容だけを保持する、
選別された永続層 です。

この意味で、merge は保存ではなく昇格です。
そして昇格には eval が要ります。

PCE 2.0 における `merge` とは何か

ここでいう merge は、狭い意味での Git merge だけではありません。
PCE 2.0 における merge とは、ある delta を durable state の一部として採用すること です。

典型的には次が含まれます。

canonical artifact の更新
decision の採用
rejection / failure knowledge の確定
operational memory の昇格
evaluation result の記録
policy / playbook / skill の更新
process status の「完了」「承認済み」などへの遷移
次の process が依拠する要約・チェックポイントの正規化

重要なのは、将来の process がそれを前提にしてよい状態へ変えること が merge だという点です。

`eval` とは何か

PCE 2.0 における eval は、「なんとなく確認すること」ではありません。
それは、ある delta を採用してよいかどうかを判断するための、明示的な評価手続き です。

eval は、最低限次を持つ必要があります。

何を評価対象にするか
何をもって適合とするか
誰または何が評価するか
結果をどう記録するか
どの失敗が merge を阻止するか

この評価手続きを、PCE 2.0 では Eval Contract と結びつけて考えます。

eval の代表例

eval は一種類ではありません。たとえば次があります。

deterministic tests
schema / type / lint validation
policy compliance checks
safety checks
trace / workflow grading
human review
structured rubric evaluation
replay / simulation
regression checks
memory promotion review

重要なのは、「どれが唯一正しい eval か」ではありません。
重要なのは、merge に先立つ明示的な評価経路があること です。

`eval` と `approval` は同じではない

この区別は重要です。

eval

ある delta が、定義された基準に照らして妥当かを判断すること。

approval

ある authority を持つ actor が、その delta を制度上採用してよいと ratify すること。

つまり、

eval は証拠に基づく判断
approval は権限に基づく確定

です。

多くの場合、merge には両方が必要です。
eval が pass していても、approval authority がなければ merge できないことがあります。
逆に、approval があっても eval がなければ PCE 2.0 では merge できません。

したがって原理は、より厳密にはこう読めます。

No merge without eval
かつ
No merge without required authority

`no merge without eval` が規定する最小条件

PCE 2.0 では、ある delta が merge されるためには、最低でも次が必要です。

1. merge 対象が明示されていること

何を durable state に昇格させるのかが明示されていなければなりません。
artifact なのか、decision なのか、memory candidate なのか、status change なのかを曖昧にしてはなりません。

2. applicable な eval contract が存在すること

その delta に対して、どの評価経路を通すのかが定義されていなければなりません。

3. blocking evaluator が実行されていること

必須の tests、checks、reviews、policy gates などが未実行のままではいけません。

4. merge gate を通過していること

必要な threshold、pass/fail 条件、must-fix 条件を満たしていなければなりません。

5. authority が存在すること

必要な場合には、approval authority や memory write authority を持つ actor が明示されていなければなりません。

6. provenance が残されること

どの process から生まれ、どの eval を通過し、誰が昇格させたかを追跡できる必要があります。

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

merge(delta) is permitted iff
  merge_target(delta) is explicit
  and eval_contract(delta) exists
  and required_evaluators(delta) have run
  and blocking_gates(delta) have passed
  and required_authorities(delta) are present
  and provenance(delta) is recorded

何を評価するのか

no merge without eval は、artifact だけを評価しろと言っているのではありません。
PCE 2.0 では、少なくとも次が評価対象になります。

1. Artifact quality

コード、仕様、文書、設定、テストなどが要求を満たすか。

2. Procedural validity

その差分が適切な process を通って生まれたか。
禁止された経路や未承認の capability を使っていないか。

3. Policy / governance compliance

安全性、権限、規則、スコープ境界を破っていないか。

4. Evidence sufficiency

その差分を将来の前提にしてよいだけの根拠が揃っているか。

5. Memory worthiness

その内容を durable state に残す価値があるか。
単なる一時的ノイズや局所判断ではないか。

このように、eval は「正しい答えか」だけを問うものではありません。
将来の process の前提にしてよいか を問うものです。

Process Delta ごとに評価の形は違う

PCE 2.0 における Process Delta は一様ではありません。
したがって eval も一様ではありません。

artifact delta

主に correctness / regression / policy / review が重要になります。

decision delta

根拠の妥当性、代替案比較、承認条件が重要になります。

failure delta

失敗の再現性、分類、将来の回避価値が重要になります。

evaluation delta

grader の妥当性、再実行可能性、閾値の意味が重要になります。

memory delta

再利用価値、過学習的な局所知でないこと、誤情報でないことが重要になります。

つまり、no merge without eval は
「全部同じスコアで測れ」という原理ではありません。
むしろ逆で、delta の型に応じた eval contract が必要だ という原理です。

provisional state と canonical state を分ける

この原理を過剰に硬く読まないために、重要な区別を置いておきます。

provisional state

途中作業、仮説、実験結果、途中 checkpoint、未確定メモ。
これは保存されてよいですが、merge された canonical state ではありません。

canonical state

将来の process が依拠してよい正規状態。
これは eval を通らなければなりません。

この区別は大きいです。
no merge without eval は、
「何も保存するな」
ではありません。

言っているのは、
「正規状態として昇格するなら eval を通せ」
ということです。

そのため、checkpoint や scratchpad の保存はありえます。
ただし、それは Recovery Point や provisional artifact として明示されるべきであり、
canonical durable state と混同してはなりません。

この原理から導かれる規則

1. No canonical promotion without explicit eval path

正規状態への昇格には、必ず明示的な評価経路が必要です。

2. No merge by mere generation

生成されたこと自体は merge の理由になりません。
モデルが出した、agent が完了と報告した、だけでは不十分です。

3. No merge by apparent success alone

見かけ上うまく動いていても、手順違反や policy violation があれば merge してはなりません。

4. No memory promotion without memory-specific evaluation

memory への昇格は、artifact と同じ評価で代用してはなりません。
その内容を将来再利用してよいかどうかを別途評価する必要があります。

5. No irreversible state change without provenance

どの process から、どの evidence で、どの authority によって merge されたかが追えなければなりません。

6. Failed eval must branch the process

eval に失敗したら、その delta はそのまま merge されません。
取りうる遷移は、reject、rework、rollback、replan、escalate です。

`no merge without eval` が設計に与える帰結

1. evaluation は末尾ではなく process の一部になる

評価は、最後に軽く確認する作業ではありません。
最初から process frame の内部に組み込まれている必要があります。

2. merge は storage operation ではなく governance event になる

merge は「保存」ではなく、「この差分を今後の前提に採用する」という制度的出来事になります。

3. durable state は curated state になる

durable state は履歴の墓場ではありません。
評価済み差分だけが入る選別層になります。

4. trace と process 自体が評価対象になる

出力だけではなく、どのような実行経路を通ったかも merge 条件に関わります。

5. evaluation は memory architecture と結びつく

何を残すかの判断は、単に重要そうかどうかではなく、
将来の process に耐えるかどうかの評価と結びつきます。

この原理は何を意味しないか

すべてのトークンや中間思考を逐一採点せよ、という意味ではない

評価対象は merge 対象の delta です。
すべての内部ステップを同じ強度で評価する必要はありません。

人間レビューだけが eval だ、という意味ではない

eval は deterministic tests でも、policy checks でも、trace grading でも、structured rubric でもよいです。
重要なのは、明示性と再現性です。

すべての provisional work を禁止する、という意味ではない

実験、仮説、scratchpad、checkpoint は存在してよいです。
ただし canonical state と区別されなければなりません。

evaluation が万能である、という意味ではない

eval には限界があります。
だからこそ、どの evaluator を使い、どの authority がどこで ratify するかを process frame に埋め込む必要があります。

小さな例

ある coding agent が patch を作ったとします。

この patch が merge される前に、少なくとも次がありえます。

unit / integration tests
policy check
scope violation check
reviewer による approval
risk / rollback 情報の確認
memory promotion 対象の抽出と評価

ここで重要なのは、
patch が生成されたことと
patch が merge 可能であること
が別だという点です。

さらに、同じ run から生まれた別の delta も区別されます。

patch 自体
採用した判断理由
失敗した試行の要約
新しい playbook 候補

これらはすべて同じようには merge されません。
それぞれに必要な eval contract が違います。

最低限の自己点検

ある設計が no merge without eval を満たしているかを点検するには、次を問います。

何が merge 対象かが明示されているか
各 delta 型に対して eval contract があるか
blocking evaluator と advisory evaluator が区別されているか
approval と eval が混同されていないか
durable state と provisional state が区別されているか
memory promotion に専用の評価経路があるか
merge 後に provenance を追跡できるか
eval 失敗時の遷移が reject / rollback / replan / escalate として定義されているか

このどれかが欠けるなら、
その設計はまだ no merge without eval ではありません。

暫定的なまとめ

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

PCE 2.0 において merge とは、将来の process が依拠する状態を書き換えることである。
だから、merge は生成の結果ではなく、評価の結果でなければならない。

生成は自由でよい。
探索も仮説も失敗もあってよい。
しかし、それを正規状態として残すなら、必ず評価を通す。
この境界を守ることが、PCE 2.0 における durable state の健全性を支えます。