Process Delta

定義

Process Delta

Process Delta とは、ある process frame が、ある意味のある境界において生成する
型付きの差分束 である。

それは単なる output ではなく、
artifact、decision、failure / rejection、evaluation、governance、operational memory、recovery などに関する
提案・変更・却下・更新・昇格候補 を、
kind、op、scope、provenance、evidence、required_eval、required_authority、target_zone とともに保持する。

より短く言えば、Process Delta とは
「この process は何を変えたか、何を変えようとしているか、何を残すべきか、何をまだ残すべきでないか」
を型付きで表現した差分である。

PCE 2.0 において process は、ただ出力を生成して終わるのではありません。
process は差分を生み、その差分が評価され、必要に応じて Durable Project State に昇格されます。

この意味で Process Delta は、
PCE 2.0 の循環における process の返り値 です。

なぜ Process Delta が必要なのか

AI 時代の開発では、成果物だけを result とみなすと、プロセスの本質が失われます。
本当に次へ引き継がれるべきなのは、コード差分だけではありません。

少なくとも次も process の結果です。

どの仕様解釈を採用したか
どの代替案を却下したか
どこで失敗し、何を学んだか
どの評価を通ったか
どの governance 条件が確認されたか
どの playbook や checklist が再利用価値を持つか
どの checkpoint から再開できるか

これらを artifact の影に隠してしまうと、

future process が同じ判断をやり直す
同じ failure を繰り返す
evaluation の根拠が失われる
memory promotion が雑になる
governance の痕跡が残らない

という問題が起こります。

Process Delta は、この「artifact 以外の成果」まで含めて、
process の結果を state-change candidate として表現するための概念 です。

`Delta` とは何か

ここでいう delta は、単なる diff ではありません。
より厳密には、ある境界をまたいで意味を持つ変化 です。

1. 差分は常に何かに対する差分である

Process Delta は、真空中の情報ではありません。
それは現在の project state、現在の process state、現在の policy / authority 状態に対する差分です。

2. 差分は semantic である

テキスト差分やコード差分だけが delta ではありません。
decision delta や evaluation delta には、行レベルの diff がないことがあります。
それでも「project の将来条件を変える」なら delta です。

3. 差分は型を持つ

artifact と decision と failure は、同じようには扱えません。
PCE 2.0 では、delta は必ず kind を持ちます。

4. 差分は昇格候補である

Process Delta は、まだそれ自体が canonical state ではありません。
それは評価され、必要な authority を通ったあとで初めて durable state に影響します。

5. 差分は部分的でよい

ひとつの process が project 全体を返す必要はありません。
delta は局所的・部分的な変化の束でよいです。

したがって Process Delta は、
process 結果の意味的で型付きの state-change candidate
として理解されるべきです。

Process Delta は何ではないか

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

1. 単なる output ではない

生成された文やコードや要約がそのまま delta なのではありません。
それらが「何を変えようとしているか」が表現されてはじめて delta になります。

2. 単なる Git diff ではない

コード差分は artifact delta の一種にはなりますが、Process Delta 全体ではありません。
decision や failure knowledge や evaluation result は Git diff だけでは表せません。

3. 単なる event log ではない

「何が起きたか」を記録した event と、
「何が project state の変化候補なのか」を表す delta は違います。
event は履歴、delta は差分候補です。

4. 単なる chat transcript ではない

会話履歴の中には差分の素材が含まれていても、履歴そのものが delta ではありません。

5. 単なる checkpoint ではない

checkpoint は recovery delta の一種にはなりえますが、
それだけで Process Delta 全体ではありません。

6. まだ durable state ではない

これはとても重要です。
Process Delta は、まだ project の正規状態ではありません。
それは評価と promotion の前段階にある変化束です。

Process Delta はいつ生成されるか

Process Delta は、必ずしも frame の完全終了時だけに生まれるわけではありません。
PCE 2.0 では、意味のある境界 ごとに delta が生成されえます。

代表的な境界

子 frame の完了
phase の完了
implementation の完了
evaluation の完了
approval の完了または拒否
rollback / replan の発生
checkpoint の確定
memory promotion 候補の抽出

このため、ひとつの Process Frame は複数の Process Delta を生成しえます。

つまり Process Delta は、
frame 全体の一回きりの返り値 というより、
意味のある境界で emission される型付き変化束 と理解した方がよいです。

Process Delta の中心的な性質

PCE 2.0 における Process Delta には、少なくとも次の性質があります。

1. Typed

どんな種類の差分かが明示されている。

2. Directional

何をどう変えたいのかが明示されている。
add / update / supersede / retract / archive / checkpoint などの方向を持ちます。

3. Scoped

どの feature、module、service、release、policy scope に属するかが明示されている。

4. Attributable

どの frame、どの actor / bundle、どの evidence から生まれたかが追跡できる。

5. Evaluable

どの eval contract を通るべきかが分かる。

6. Selectively mergeable

delta 全体を丸ごと merge する必要はありません。
item ごと、型ごとに評価・分割・昇格できます。

7. Potentially durable, not automatically durable

durable になりうるが、自動的には durable にならない。

この七つがあるからこそ、Process Delta は
raw output でも raw log でもなく、PCE 2.0 の中核概念として成立します。

Process Delta の基本型

PCE 2.0 では、最低でも次の型を Process Delta に含めます。

1. Artifact Delta

成果物の差分です。

code patch
spec update
test additions
schema changes
runbook edits

これは最も分かりやすい delta ですが、これだけでは不十分です。

2. Decision Delta

意思決定の差分です。

accepted interpretation
adopted strategy
chosen trade-off
superseded decision
approved rationale

成果物が変わらなくても、decision が変われば project は変わります。

3. Failure / Rejection Delta

失敗や却下の差分です。

rejected alternative
failed attempt with reusable lesson
scope violation finding
do-not-repeat note
policy rejection rationale

PCE 2.0 では、失敗も durable な学習対象になりえます。

4. Evaluation Delta

評価に関する差分です。

test results
grading outcomes
quality verdicts
regression baseline updates
rubric judgments

これは No merge without eval を支える型です。

5. Governance Delta

統治条件に関する差分です。

updated approval rule
scope constraint clarification
policy annotation
escalation condition
audit note

AI 時代の process では governance 自体も変化します。

6. Operational Delta

再利用可能な手順知・運用知に関する差分です。

new checklist candidate
updated playbook
skill refinement
reusable workflow note
incident handling pattern

これは Durable Project State の operational memory を更新しうる型です。

7. Recovery Delta

再開可能性に関する差分です。

checkpoint package
paused run snapshot
resumable summary
pending approval recovery state

これは canonical ではなく provisional zone を更新することが多いです。

8. Status / Coordination Delta

process の進行や handoff に関わる差分です。

phase completed
ready for review
blocked by approval
escalated to owner
handoff package created

これは必ずしも durable canonical item にはなりませんが、
親 frame や downstream actor にとって重要な差分です。

`kind` と `op` を分ける

Process Delta を粗くしないために、kind と op は分けて考えます。

Kind

差分が何の型か。

artifact
decision
failure_memory
evaluation
governance
operational_memory
recovery
status

Op

その型に対して何をしようとしているか。

add
update
supersede
retract
archive
checkpoint
annotate

この区別があることで、たとえば次が表現できます。

decision を add する
artifact を update する
playbook を supersede する
rejected alternative を archive ではなく failure memory として add する
recovery point を checkpoint として追加する

PCE 2.0 では、delta は「何か」だけでなく、
それをどう変えたいのか まで表現する必要があります。

Process Delta と Handoff の関係

PCE 2.0 では、子 frame が親 frame に返すものは、単なる message ではありません。
それは Process Delta です。

このとき delta は、state change candidate であると同時に、handoff material でもあります。
したがって Process Delta は、しばしば次のような情報も持ちます。

summary
evidence refs
unresolved issues
recommended next action
required approval
escalation recommendation

ただし注意すべきは、これらの handoff 情報がそのまま canonical state になるわけではないことです。
それらは delta の消費を助ける付帯情報であって、
durable 化されるには別途 eval / authority / promotion が必要です。

Process Delta と Durable Project State の関係

Process Delta は、Durable Project State を更新しうる唯一の正当な差分表現です。
言い換えると、durable state の変更は、追跡可能な delta を通して起こるべきです。

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

execute(process_frame, runtime_state) -> process_delta
evaluate(process_delta, eval_contract) -> verdict
promote(approved_items(process_delta), durable_project_state) -> durable_project_state'

ここで重要なのは、Process Delta 自体はまだ state ではない という点です。
それは durable state に対する更新候補です。

target zone の違い

各 delta item は、どこへ向かうのかを持ちます。

canonical zone へ向かうもの
provisional zone へ向かうもの
parent frame への handoff 専用のもの
status coordination のためだけのもの

したがって Process Delta は、
一つの大きな diff ではなく、
異なる zone / consumer / authority に向かう型付き change set です。

Process Delta と Evaluation の関係

Process Delta は、評価の前に存在しますが、評価と切り離されてはいません。
むしろ delta は、どの評価を必要とするか を内包しているべきです。

各 delta item には、少なくとも次が結びつきます。

required_eval
evidence_refs
blocking_conditions
required_authority

たとえば、

artifact delta には tests と review が必要かもしれない
decision delta には rationale review と goal-owner approval が必要かもしれない
operational delta には再利用価値の確認が必要かもしれない
recovery delta は full eval ではなく integrity check だけでよいかもしれない

このため、Process Delta は「評価の後に見るもの」ではなく、
評価の対象であり、評価経路を要求するもの です。

Process Delta は分割・合成・部分昇格できる

PCE 2.0 では、一つの process から出た delta を丸ごと扱う必要はありません。
delta は操作可能であるべきです。

Split

一つの delta を複数の型や scope に分ける。

例:

code patch は merge する
playbook 候補は pending のまま残す
working note は捨てる

Compose

複数の delta を一つの higher-level delta として扱う。

例:

child frame A / B / C の delta を親 frame の統合 delta にまとめる

Partial Promotion

delta の一部だけを canonical に昇格させる。

例:

decision delta は採用
related operational delta は追加検証待ち

Supersede

古い delta の効果を新しい delta で置き換える。

例:

earlier rationale を後続の approved rationale で supersede する

この柔軟性があるからこそ、Process Delta は実務に耐えます。

Process Delta のライフサイクル

Process Delta 自体にも状態があります。
最低限、次のような状態を想定できます。

emitted
under_review
evaluated
approved
partially_merged
merged
rejected
superseded
archived

ここで重要なのは、
delta が emitted された瞬間に merge 済みになるわけではない
という点です。

No merge without eval は、このライフサイクルの中心原理です。

by-value と by-reference

Process Delta の payload は、必ずしも中身そのものを持つ必要はありません。
大きい artifacts や logs は reference で持つ方が自然なことがあります。

by-value

short rationale
summary
checklist candidate
review verdict
status annotation

by-reference

code diff ref
document ref
issue / PR ref
checkpoint ref
evaluation report ref

この使い分けにより、delta は軽量に保ちつつ、必要な深さの情報へ到達できます。

Process Delta の最小スキーマ

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

process_delta:
  delta_id:
  source_frame:
  emitted_at_boundary:
  status:
  summary:
  unresolved_issues:
  recommended_next_action:
  items:
    - item_id:
      kind:
      op:
      scope:
      target_zone:
      target_collection:
      payload_or_ref:
      evidence_refs:
      required_eval:
      required_authority:
      blocking_conditions:
      provenance:
      freshness:

より item 指向に書くなら、各 item は次のように表せます。

delta_item:
  item_id:
  kind:
  op:
  scope:
  target_zone:
  target_collection:
  payload_or_ref:
  evidence_refs:
  required_eval:
  required_authority:
  blocking_conditions:
  provenance:
    source_frame:
    source_actor:
    source_bundle:
  freshness:

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

item ごとに kind と op がある
target zone / collection がある
eval と authority の前提がある
provenance がある
delta 全体に summary と unresolved issues がある

つまり Process Delta は、
意味的変化 + 評価前提 + handoff 可能性
を一つに束ねた構造です。

小さな例

「checkout にクーポン併用制約を追加する」frame から、次の delta が出たとします。

process_delta:
  delta_id: delta.feature.checkout.coupon-combination.v3
  source_frame: feature.checkout.coupon-combination
  emitted_at_boundary: implementation_completed
  status: emitted
  summary: >
    実装・テスト更新・判断根拠・失敗知・checkpoint を含む差分。
    code change は review と regression pass 後に canonical 候補。
  unresolved_issues:
    - edge_case_for_stacked_discount_rounding_requires_followup
  recommended_next_action:
    - review_code_change
    - run_required_regression_suite
    - evaluate_memory_candidates
  items:
    - item_id: delta_item.code_patch
      kind: artifact
      op: update
      scope: feature.checkout.coupon-combination
      target_zone: canonical
      target_collection: artifacts
      payload_or_ref:
        commit_ref: abc1234
        files:
          - src/checkout/coupon_validation.ts
          - tests/checkout/coupon_validation.test.ts
      evidence_refs:
        - local_test_run_552
      required_eval:
        - regression_tests
        - code_review
      required_authority:
        - reviewer
      blocking_conditions:
        - no_scope_violation
      provenance:
        source_frame: feature.checkout.coupon-combination
        source_actor: coding_agent
        source_bundle: coding_agent_impl_bundle_v2
      freshness: current

    - item_id: delta_item.accepted_rationale
      kind: decision
      op: add
      scope: feature.checkout.coupon-combination
      target_zone: canonical
      target_collection: decisions
      payload_or_ref:
        summary: payment gateway changes remain out of scope for this feature
      evidence_refs:
        - approved_spec_summary
        - implementation_note
      required_eval:
        - rationale_review
      required_authority:
        - product_owner
      blocking_conditions: []
      provenance:
        source_frame: feature.checkout.coupon-combination
        source_actor: analyst_agent
        source_bundle: analyst_agent_bundle_v1
      freshness: current

    - item_id: delta_item.failed_naive_threshold_approach
      kind: failure_memory
      op: add
      scope: feature.checkout.coupon-combination
      target_zone: canonical
      target_collection: failure_memory
      payload_or_ref:
        summary: naive threshold check caused regression in existing coupon precedence
      evidence_refs:
        - failed_test_run_548
      required_eval:
        - reviewer_confirmation
      required_authority:
        - reviewer
      blocking_conditions: []
      provenance:
        source_frame: feature.checkout.coupon-combination
        source_actor: coding_agent
        source_bundle: coding_agent_impl_bundle_v2
      freshness: current

    - item_id: delta_item.regression_results
      kind: evaluation
      op: add
      scope: feature.checkout.coupon-combination
      target_zone: canonical
      target_collection: evaluation_memory
      payload_or_ref:
        report_ref: ci_run_554
      evidence_refs:
        - ci_run_554
      required_eval:
        - ci_integrity_check
      required_authority:
        - ci_evaluator
      blocking_conditions:
        - all_required_tests_green
      provenance:
        source_frame: feature.checkout.coupon-combination
        source_actor: ci_evaluator
        source_bundle: ci_eval_bundle_v1
      freshness: current

    - item_id: delta_item.review_checkpoint
      kind: recovery
      op: checkpoint
      scope: feature.checkout.coupon-combination
      target_zone: provisional
      target_collection: recovery_points
      payload_or_ref:
        checkpoint_ref: cp-20260308-02
      evidence_refs: []
      required_eval:
        - checkpoint_integrity_check
      required_authority:
        - runtime
      blocking_conditions: []
      provenance:
        source_frame: feature.checkout.coupon-combination
        source_actor: runtime
        source_bundle: runtime_checkpoint_bundle
      freshness: short_term

    - item_id: delta_item.edge_case_playbook_candidate
      kind: operational_memory
      op: add
      scope: checkout
      target_zone: provisional
      target_collection: pending_candidates
      payload_or_ref:
        summary: candidate checklist for coupon edge-case verification
      evidence_refs:
        - implementation_note
        - failed_test_run_548
      required_eval:
        - memory_promotion_review
      required_authority:
        - memory_writer
      blocking_conditions:
        - insufficient_repeatability_evidence
      provenance:
        source_frame: feature.checkout.coupon-combination
        source_actor: reviewer
        source_bundle: reviewer_bundle_v1
      freshness: current

この例で重要なのは、ひとつの delta の中に

canonical 候補
provisional 候補
artifact
decision
failure
evaluation
recovery

が混在していてもよいことです。
PCE 2.0 では、これらを型ごとに扱います。

Process Delta の不変条件

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

1. Every delta has a source frame

どの delta も、どの process frame から生まれたか追跡できなければなりません。

2. Every delta item is typed

kind のない delta item は許されません。
artifact なのか decision なのか evaluation なのかを曖昧にしてはなりません。

3. Every mergeable item has an eval path

canonical または durable な更新候補は、required eval を持たなければなりません。

4. Every item declares intended target

どこへ向かう差分なのかが必要です。
canonical か provisional か、どの collection かを明示しなければなりません。

5. Delta is not state

Process Delta は durable state そのものではありません。
それは state 更新候補です。

6. Delta may be partially promoted

delta 全体を一括採用する必要はありません。
item 単位で評価・昇格・却下できなければなりません。

7. Every canonical promotion must trace back to a delta

durable project state の canonical item は、どの delta から来たか追跡できなければなりません。

8. Handoff material must not be mistaken for canonical truth

summary や unresolved issues は有用ですが、そのまま canonical state だとみなしてはなりません。

いつ新しい Process Delta を切るべきか

実務上は、何を一つの delta としてまとめるかが重要です。
新しい delta を切るべき典型条件は次です。

1. 意味のある boundary をまたいだとき

子 frame 完了、phase 完了、approval 完了、evaluation 完了などです。

2. required eval / authority が大きく変わるとき

artifact review と memory promotion review を同じ delta item に混ぜるべきではないことがあります。

3. target zone が異なるとき

canonical 候補と provisional 候補は、区別可能であるべきです。

4. scope が大きく変わるとき

別 module、別 feature、別 policy scope にまたがるなら、分けた方が追跡しやすいです。

5. 親 frame への handoff と durable promotion を分けたいとき

親が読むための summary と、project state に残すべき item は分離した方がよいことがあります。

短く言えば、
評価条件、authority、scope、target zone のいずれかが大きく変わるなら、新しい delta を切る
のが基本です。

最低限の自己点検

ある設計が Process Delta を十分に持っているかは、次で点検できます。

その process の結果を artifact 以外も含めて差分化できるか
kind と op を分けて書けるか
delta item ごとに target zone と target collection を持てるか
required eval と required authority が書けるか
provenance が frame / actor / bundle まで追えるか
canonical 候補と provisional 候補を分けられるか
delta 全体の summary と unresolved issues を持てるか
child から parent への handoff payload として使えるか
durable state がどの delta から更新されたか説明できるか
delta が state そのものだと誤認されていないか

このどれかが欠けるなら、その差分モデルはまだ粗いままです。

暫定的なまとめ

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

process の結果は、単なる output ではない。
それは、artifact、decision、failure、evaluation、governance、memory、recovery を含む、型付きの差分として表現され、評価と authority を経てはじめて project state を変える。

PCE 2.0 において process は、状態を直接書き換えません。
process はまず delta を生み、その delta が評価され、選別され、昇格されて初めて durable state を更新します。

だから Process Delta は、単なる補助概念ではありません。
それは、PCE 2.0 において 変化を記述し、評価し、継続へ接続するための中心的な差分単位 です。