Approval

定義

Approval

Approval とは、ある Actor が、ある Process Frame のある局面において、
特定の subject に対して、
次の legal transition を解禁してよいかどうかを ratify する責任 である。

それは単なる「確認すること」ではなく、
subject scope、required preconditions、required evidence readiness、allowed verdicts、authority basis、effect on next transitions、escalation path、recordability を含む。

より短く言えば、Approval とは
「この差分・この phase・この再開・この昇格候補を、いま先へ進めてよいかを、正当な authority のもとで確定する責任」
である。

PCE 2.0 において approval は、単なる礼儀的な確認や、後からの軽いレビューではない。
それは authority の行使 であり、process の中で実際に gate を解く責任である。

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

なぜ Approval が必要なのか

PCE 2.0 が Approval を独立責任として置くのは、
「何かができたこと」と「それを先へ進めてよいこと」が別だからである。

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

1. execution と ratification は別だから

実装、調査、要約、評価が終わっても、
それだけでその subject を process の次の段階へ進めてよいとは限らない。

code patch ができた
spec draft がまとまった
memory candidate が抽出された
recovery point から戻せそうだ

こうしたことは、まだ「先へ進めてよい」の根拠にはならない。
Approval は、その gap を埋める責任である。

2. multi-actor process では暗黙の承認が壊れやすいから

長時間・多段・多主体の仕事では、

誰かが見たはず
たぶん問題ないはず
CI が通ったから大丈夫だろう
実装者が納得しているからよいだろう

が非常に危険になる。
Approval は、こうした曖昧な通過を防ぐ。

3. eval と approval が別だから

Eval Contract は criteria に基づく判断を与える。
しかし、評価で pass したことと、制度上その subject を先へ進めてよいことは別である。

eval = 適合性の判断
approval = authority による ratification

である。

4. durable state の更新は特権的だから

とくに promote や merge のような durable-state mutation は、
future process の前提を変える。
したがって、それに近づく subject には approval が必要になることが多い。

5. pending approval は意味的な process state だから

承認待ちは単なる待ち時間ではない。
それは process の構造上の状態であり、recovery や handoff でも保持されるべきものである。
Approval を独立責任として扱うことで、pending state を追跡可能にできる。

Approval は何ではないか

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

1. 単なる Evaluation ではない

評価は criteria と evidence に基づく判断である。
Approval は、その結果を踏まえて authority が ratify することである。
評価と承認は同じ actor が行うこともあるが、概念上は分けるべきである。

2. 単なる Goal Ownership ではない

goal owner は frame 全体の目標と完了条件を保持する。
approver は通常、特定 subject に対して先へ進めてよいかを判断する。
approver がそのまま frame 全体を close してよいとは限らない。

3. 単なる Execution ではない

作業をした actor が、その成果物を自分で ratify してよいとは限らない。
execution と approval の分離は、PCE 2.0 で非常に重要である。

4. 単なる Memory Writing ではない

memory candidate を approve することと、最終的に durable state に書き込むことは別である。
Approval は promotion path を解禁するが、write authority と一致するとは限らない。

5. 単なる UI ボタンではない

approve / reject ボタンは表面上の実装にすぎない。
Approval の本質は、その verdict が どの legal next transitions を解禁し、どれを止めるか にある。

6. 単なる「誰かが見たこと」ではない

PCE 2.0 における approval は、subject、authority、preconditions、allowed verdicts、effect を持つ。
誰かが眺めたこと自体は approval ではない。

7. 単なる silence ではない

何も言わないことは、原則として approval ではない。
timeout approve や no-objection rule を使うなら、それは explicit rule として定義されるべきである。

Approval が含む責任

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

1. Subject Ratification

何に対して ratify するのかを引き受ける。

例:

spec candidate
artifact delta
decision delta
memory candidate
recovery resume request
reframe proposal

2. Authority-bearing Verdict

自分が正当な authority basis を持つ範囲で verdict を出す。
これは単なる意見表明ではなく、next transition を変える責任である。

3. Gate Resolution

pending gate を解く。
approve、reject、request changes、escalate などにより、process の停止状態を解消する。

4. Preconditions Awareness

required eval、required evidence、prior approval などの preconditions が満たされているかを確認する。
approval は eval を代行しないが、approval 可能状態に入っているか を見なければならない。

5. Boundary Enforcement

scope、policy、risk tier、authority boundary を守る。
approver は subject の見た目だけでなく、「この subject をこのまま先へ進めてよいか」を境界条件つきで判断する。

6. Exception Routing

自分の approval scope を越える曖昧性や conflict がある場合、適切に escalate する。

7. Decision Record Production

誰が、どの evidence を見て、どの verdict を出したかを traceable に残す。
approval は記録なしには durable governance に組み込めない。

Approval の対象は何か

PCE 2.0 では、approval の subject は artifact だけではない。
少なくとも次のようなものが approval subject になりうる。

1. Phase completion

spec ready
implementation completed
evaluation completed
merge ready

2. Artifact delta

code patch
spec update
test additions
runbook edits

3. Decision delta

accepted rationale
chosen interpretation
trade-off acceptance
scope clarification

4. Memory candidate

checklist candidate
failure memory candidate
approved summary candidate
operational memory candidate

5. Reframe proposal

goal change
scope change
success criteria change

6. Recovery / Resume request

checkpoint からの risky resume
rollback 後の再進行
incident 後の再始動

つまり Approval は、
「これを先へ進める」「これを採用する」「これを昇格へ進める」
という意味を持つ対象全般に関わる。

Approval と Approval Point の違い

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

Approval

責任・authority の側にある概念。
ある actor が subject を ratify する responsibility である。

Approval Point

Approval Points は process 構造の側にある概念。
「ここでは approval が必要だ」という gate である。

つまり、

Approval = 責任
Approval Point = 構造
Approve / Reject = 遷移

である。

Approval responsibility があるだけでは process は止まらない。
Approval Point があるだけでも、誰が ratify するか分からなければ gate は解けない。
両者は相補的である。

Approval と Evaluation の違い

この区別も PCE 2.0 では中心的である。

Evaluation

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

Approval

その subject を process 上で先へ進めてよいかを authority に基づいて ratify する。

したがって、

eval pass でも approval が必要なことがある
approval authority があっても eval 未了なら approve できないことがある
evaluator と approver が同一 actor でも、責任としては別に持つべきである

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

approval_open(subject) iff
  required_eval(subject) completed
  and required_evidence(subject) present
  and approval_authority(subject) available

ここで重要なのは、approval は
「良さそうだからよい」
ではなく、
「criteria と evidence を満たした subject に対して authority を行使する」
ことだという点である。

Approval と Goal Ownership の違い

goal owner は frame 全体の目的と完了条件を保持する。
approver は通常、特定 subject に対して legal progression を解禁する。

Goal owner がやること

goal を定義する
success criteria を保持する
reframe する
frame close を accept する

Approver がやること

spec candidate を ratify する
code change を review-ready / merge-ready と認める
memory candidate を先へ進める
risky resume を許可する

同じ actor が両方を持つことはありうる。
しかし概念上は分離した方が、process integrity が高くなる。

Approval と Memory Writing の違い

memory candidate の場合、この差はとくに重要である。

Approval

candidate を promote path に載せてよいかを ratify する。

Memory Writing

最終的にどの durable collection へ書き込むかを決める。

たとえば reviewer が「failure lesson として残す価値がある」と approve しても、
実際に canonical failure memory へ merge するのは memory writer かもしれない。

つまり Approval はしばしば

promote candidate として admissible にする
required gate を解く

役割を持つが、
書き込み権限そのものとは別である。

Approval と actor symmetry / responsibility asymmetry

PCE 2.0 は actor の分析上の対称性を認めるが、
Approval は典型的に 非対称責任 の中核である。

理論上

approval を non-human actor が担うことを完全に排除する必要はない。
policy-backed governance actor、automated approver、runtime gate などはありうる。

実務上

しかし approval には通常次が伴う。

authority basis
ratification trace
boundary enforcement
exception handling
potential liability adjacency

このため、approval はしばしば

human approver
explicitly delegated governance actor
strongly bounded automated gate

として設計される。

重要なのは、
approval は actorhood から自動的には出てこない
という点である。
actor であることと、ratify できることは別である。

Approval のトポロジ

Approval responsibility は常に single approver とは限らない。
PCE 2.0 では、少なくとも次の topology を区別できる。

1. Single Approver

一人の actor が ratify する最も単純な形。

2. Ordered Chain

複数段の承認が順番に必要な形。

例:

spec review → product owner approval
CI pass → reviewer approval → release owner approval

3. Conjunctive Approval

複数 actor 全員の承認が必要な形。

4. Delegated Approval

一定範囲では delegated approver が代行できる形。
delegation path は traceable であるべき。

5. Conditional Approval

条件つきで先へ進める承認。
follow-up item や pending condition を残す必要がある。

6. Override / Exception Approval

通常の blocking rule を越える強い承認。
この場合、通常より強い rationale と audit が必要になる。

Approver の topology が変わるなら、
Approval responsibility も単純な yes/no 権限ではなくなる。

Approval の主要操作

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

Assign

ある actor に特定 subject scope の approval responsibility を割り当てる。

Bind Subject

ある approval point に特定 subject を結びつける。

Review for Approval

evidence と prerequisites を確認し、verdict を出す準備をする。

Approve

subject を next legal transition に進めてよいと ratify する。

Reject

subject を current path で先へ進めることを拒否する。

Request Changes

subject を差し戻し、再提出を要求する。

Escalate

自分の authority scope を越える問題として引き上げる。

Conditional Approve

限定条件つきで次の遷移を一部解禁する。
条件自体は別の pending item として traceable であるべき。

Revoke / Invalidate

drift や subject change により、以前の approval を stale / invalid にする。

このうち approve は最も目立つが、
PCE 2.0 では reject や request changes も process continuity にとって同等に重要である。

Approval と Handoff の関係

Approval はしばしば Handoff を伴う。

例:

coding agent → reviewer
analyst agent → product owner
reviewer → memory writer
runtime / incident actor → resume approver

ここで important なのは、approval 用 handoff package に少なくとも次が必要だという点である。

subject
required evidence
relevant rationale
pending gates
expected verdict
escalation path

つまり Approval は「見て判断する」だけではなく、
approval-ready な continuity package を受け取って初めて成立する。

Approval と Checkpoint / Recovery の関係

pending approval は、recovery-aware でなければならない。
そのため Approval responsibility は Checkpoint and Recovery と結びつく。

少なくとも次が重要である。

approval-wait checkpoint が持つべきもの

pending subject
required approver
required evidence
stale conditions
next legal verdicts

recover 後に確認すべきこと

approver authority が変わっていないか
subject が変更されていないか
required eval result が still valid か
old approval が stale ではないか

つまり Approval は、単発のボタン操作ではなく、
pending から resume までを含む継続責任 でもある。

Approval の最小スキーマ

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

approval_responsibility:
  actor_ref:
  frame_id:
  subject_scope:
  authority_basis:
  topology_role:
    # single_approver | chain_step | conjunctive_member | delegated_approver | override_approver
  allowed_verdicts:
    - approve
    - reject
    - request_changes
    - insufficient_evidence
    - escalate
    - conditional_approve
  preconditions:
    required_evals:
    required_evidence:
    prior_approvals:
    policy_conditions:
  effect_on_verdict:
    approve:
      unlocks:
      next_transitions:
    reject:
      next_transitions:
    request_changes:
      next_transitions:
    insufficient_evidence:
      next_transitions:
    escalate:
      next_transitions:
    conditional_approve:
      obligations:
      next_transitions:
  validity:
    active_when:
    expires_when:
  audit_requirements:
  provenance:

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

approval:
  subjects:
  authority_basis:
  topology_position:
  allowed_verdicts:
  required_preconditions:
  required_evidence:
  escalation_path:
  effect_on_approval:
  expiry_policy:
  audit_requirements:

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

subject scope がある
authority basis がある
allowed verdicts がある
preconditions と evidence がある
verdict が next transitions を変える
expiry と audit を持つ

つまり Approval は、
単なる「approve できる人」ではなく、
subject-specific ratification contract を持つ責任 として扱われる。

小さな例

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

approval_responsibility:
  actor_ref: reviewer
  frame_id: feature.checkout.coupon-combination
  subject_scope:
    - artifact_delta.code_patch
  authority_basis:
    - reviewer_bundle_v1
    - governance_record.checkout_coupon_review_required
  topology_role: single_approver
  allowed_verdicts:
    - approve
    - reject
    - request_changes
    - insufficient_evidence
    - escalate
  preconditions:
    required_evals:
      - eval.feature.checkout.coupon-combination.artifact.v1
    required_evidence:
      - code_diff
      - ci_report
      - approved_spec_summary
      - rollback_note
    prior_approvals:
      - spec_approval
    policy_conditions:
      - no_scope_violation
  effect_on_verdict:
    approve:
      unlocks:
        - promotion_path_for_artifact_delta
      next_transitions:
        - promote
    reject:
      next_transitions:
        - rework
    request_changes:
      next_transitions:
        - handoff_back_to_coding_agent
    insufficient_evidence:
      next_transitions:
        - request_missing_evidence
    escalate:
      next_transitions:
        - escalate_to_product_owner
  validity:
    active_when: implementation_completed
    expires_when:
      - code_diff_changes
      - required_eval_result_changes
      - governance_rule_changes
  audit_requirements:
    - approval_record
    - rationale_note
  provenance:
    assigned_by: feature.checkout.coupon-combination

この例で重要なのは、reviewer が「レビュー担当」という role を持つだけでなく、

何に対して
どの条件で
どの verdict を出せて
それが process をどう変えるか

まで明示されていることだ。

Approval の不変条件

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

1. No approval without explicit subject

何に対する承認か曖昧な approval は不完全である。

2. No approval without authority basis

actor identity だけでは不十分であり、bundle または governance に基づく authority が必要である。

3. No approval without verdict semantics

approve / reject / request changes などの結果と、その effect が必要である。

4. Approval does not replace evaluation

required eval を黙って飛ばす approval は、explicit override でない限り不正である。

5. Approval does not imply durable write

approve されたからといって、自動的に canonical state が更新されるわけではない。

6. Pending approval must be recoverable

approval 待ちは recovery-aware な process state でなければならない。

7. No hidden authority transfer

subject を提出した actor が、そのまま approver であるとは限らない。
提出と承認は分けて扱うべきである。

8. Approval records must be attributable

誰が、どの evidence を見て、どの verdict を出したか追える必要がある。

いつ Approval を分けるべきか

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

1. Subject type が変わるとき

spec approval
code review approval
memory promotion approval
resume approval

は通常、分けた方がよい。

2. Authority boundary が変わるとき

別の approver や別 risk tier を必要とするなら、approval surface も分けるべきである。

3. Evidence shape が変わるとき

artifact diff を見る approval と、failure memory candidate を見る approval では必要 evidence が違う。

4. Verdict semantics が変わるとき

conditional approve がありうる subject と、all-or-nothing でしか扱えない subject は分けた方がよい。

5. Governance sensitivity が変わるとき

override、exception handling、高リスク resume などは独立した approval responsibility にする方が安全である。

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

最低限の自己点検

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

どの subject に approval が必要か言えるか
誰がどの authority basis で approve できるか言えるか
approval と eval を混同していないか
approval と goal ownership を混同していないか
allowed verdicts とその効果があるか
pending approval を recovery 可能な state として扱えているか
stale subject や changed subject で old approval を流用していないか
request changes / escalate を正式な verdict として扱えているか
approval が next transitions をどう解禁するか説明できるか
approval record の traceability があるか

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

暫定的なまとめ

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

process において「次へ進めてよい」は、結果が出たことでも、誰かが見たことでも、評価が通ったことだけでも決まらない。
特定の subject に対して、必要な前提と根拠が揃った上で、正当な authority が ratify してはじめて決まる。

PCE 2.0 において approver は、単なる確認者ではない。
それは、process の次の合法状態を開く責任を持つ actor である。

だから Approval は、単なるレビュー工程ではない。
それは、PCE 2.0 において 評価と統治を process progression へ接続する ratification responsibility である。