Approval Points

定義

Approval Point

Approval Point とは、ある process frame の内部に配置される
明示的な ratification 要求地点 である。

それは、ある subject に対して、
approval authority を持つ actor または正当に委任された governance mechanism が、
所定の evidence、preconditions、decision rule に基づいて
進行・採用・昇格・再開を許可するかどうか を確定しなければ、
次の legal transition へ進めない構造上の地点である。

より短く言えば、Approval Point とは
「この先へ進む／これを採用する／これを昇格するには、誰のどの authority による明示的承認が必要か」を process 上に固定する点
である。

PCE 2.0 において approval は、曖昧な「なんとなく確認すること」ではありません。
それは authority の行使です。
そして Approval Point は、その authority が どこで process を止め、どの subject に対して ratification を要求するのか を定義する構造です。

この意味で Approval Point は、
Responsibility Bundle の approval_authority が、
Governance Surface 上で具体的に効く位置を表します。

---

なぜ Approval Points が必要なのか

PCE 2.0 が Approval Point を独立概念として置くのは、
authority を bundle や policy に書いただけでは process を実際には止められないからです。

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

1. 実行と ratification は別だから

AI agent や human actor が work を完了しても、それだけで process を先へ進めてよいとは限りません。
artifact ができたことと、それを project の次の前提として採用してよいことは別です。

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

「レビューしたはず」「誰かが見たはず」「CI が通ったから大丈夫だろう」といった暗黙の合意は、
長時間・多段・多主体の process では非常に壊れやすいです。

3. evaluation と approval を分けたいから

Eval Contract が pass しても、
required authority を持つ actor が ratify していなければ、まだ進めないことがあります。
逆に authority があっても、eval が未完了なら進めないことがあります。

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

No merge without eval がある以上、
merge や memory promotion は「できたから入れる」ではありません。
Approval Point は、その昇格・採用を authority の側から拘束します。

5. pending approval は process state そのものだから

承認待ちは単なる待機ではありません。
それは process の意味的な状態です。
Approval Point がないと、pending approval を追跡可能な状態として扱えません。

だから PCE 2.0 では、
approval は transition の副作用ではなく、構造上の gate
として定義されます。

---

Approval Point は何ではないか

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

1. 単なる approve / reject transition ではない

approve や reject は Transitions 上の出来事です。
Approval Point は、それらが適用される 構造上の地点 です。

2. 単なる evaluator ではない

evaluator は criteria に基づいて判断を出します。
Approval Point は、その判断結果を受けて authority が ratify する場所です。

3. 単なる UI 上のボタンではない

承認ボタンは surface の一実装にすぎません。
Approval Point の本質は、
「この subject はこの authority が承認するまで次へ進めない」という process semantics にあります。

4. 単なる policy 文書ではない

policy が approval requirement を規定することはあります。
しかしその requirement が process 上に gate として materialize されていなければ、Approval Point ではありません。

5. 単なる merge point ではない

merge を守る approval point はありますが、Approval Point は merge に限りません。
spec 承認、reframe 承認、memory promotion 承認、resume 承認もありえます。

6. 単なる「誰かが見る工程」ではない

誰かが見ること自体は review activity ですが、
Approval Point は authority と subject と verdict semantics を持つ構造です。

---

Approval Point は「構造」であり、Approve / Reject は「遷移」である

この区別は PCE 2.0 で非常に重要です。

Approval Point

• frame 内の構造
• どの subject が
• 誰の authority を
• どの条件で必要とするか を定める

Approve / Reject / Request Changes / Escalate

• その Approval Point を実際に横断する transition
• verdict を確定する出来事

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

approval_point = structural gate
approve/reject = transitions that resolve the gate

あるいは、より process 的には、

legal_next_transitions(frame, t) =
  base_next_transitions(frame, t)
  - blocked_by_unsatisfied_approval_points(frame, t)
  + unlocked_by_satisfied_approval_points(frame, t)

ここで重要なのは、Approval Point が
未来の legal transition の集合を制御する構造
だという点です。

---

Approval Point が扱う subject

Approval Point は artifact だけに対して置かれるわけではありません。
PCE 2.0 では、少なくとも次のものが approval subject になりえます。

1. Phase completion

• spec ready
• implementation completed
• evaluation completed
• merge ready

ある phase を終えたとみなしてよいかの承認です。

2. Artifact delta

• code patch
• spec update
• test additions
• runbook update

最も典型的な approval subject です。

3. Decision delta

• accepted rationale
• chosen trade-off
• interpretation decision
• boundary clarification

artifact が変わらなくても、decision の採用は approval を要しえます。

4. Memory promotion candidate

• playbook candidate
• checklist candidate
• failure lesson
• approved summary

これは artifact merge とは別の approval topology を持つことがあります。

5. Reframe / Scope change

• goal の修正
• in-scope / out-of-scope の変更
• success criteria の変更

frame の意味自体を変えるので、強い authority を要します。

6. Policy override / exception

• required check の一時免除
• standard rule からの逸脱
• emergency handling path の許可

これは特別な approval point として扱うべきです。

7. Recovery / Resume

• risky recovery の再開
• paused run の復帰
• rollback 後の再進行

recovery の legality を ratify する必要がある場合があります。

8. Escalation resolution

• incident handling の進め方
• ambiguity 解消後の進行許可
• blocked frame の再始動許可

つまり Approval Point は、
「何かを前へ進めること」全般に対する authority gate です。

---

Approval Point の構成要素

PCE 2.0 では、Approval Point は少なくとも次の成分を持ちます。

1. Point Identity

どの frame のどの地点にある approval point かを識別します。

2. Subject

何に対する approval なのかを定めます。

• phase
• delta item
• candidate
• reframe proposal
• recovery action

などです。

3. Purpose

なぜこの承認が必要なのかを定めます。

• merge readiness の ratification
• decision adoption の確定
• memory promotion の許可
• risky resume の許可

などです。

4. Required Authority

誰または何が承認権限を持つのかを定めます。

• single approver
• ordered approver chain
• any-of
• all-of
• quorum
• explicit override authority

などの topology を持ちえます。

5. Preconditions

approval 対象が point に到達するための条件です。

• required eval pass
• required evidence present
• prior approval completed
• subject scope consistency
• no blocking policy violation

などが入ります。

6. Required Evidence

approver が判断するために必要な evidence です。

• code diff
• test report
• rationale note
• rollback note
• policy check result
• evaluation summary

7. Allowed Verdicts

どの verdict が有効かを定めます。

• approve
• reject
• request_changes
• insufficient_evidence
• escalate
• conditional_approve

などです。

8. Effect on Process

各 verdict によって何が解禁・停止・差戻し・昇格されるのかを定めます。

9. Audit / Record Requirement

何を記録し、何を後から追跡できるべきかを定めます。

10. Freshness / Expiry

いつ stale になり、どの条件で再提出・再承認が必要になるかを定めます。

---

Approval Authority は approver identity と同一ではない

Approval Point で重要なのは、approval authority を actor identity から自動推定しないことです。

actor identity

誰か／何かであること

approval authority

その subject に対して ratify できる bundle 上の権限であること

同じ reviewer でも、

• code review approval はできる
• spec approval はできない
• memory promotion approval はできない

ことがあります。

したがって Approval Point は、少なくとも次を要求すべきです。

• actor ref
• authority basis
• subject scope
• decision rule

この区別があることで、
「actor が関与した」こと と
「その actor が ratify した」こと
を分けて扱えます。

---

Approval Point と Eval Contract の違い

この区別は特に重要です。

Eval Contract

• 何を
• どの criteria で
• どの evidence に基づいて
• 誰 / 何が評価するか を定める契約

Approval Point

• どの subject が
• どの authority によって
• いつ ratify される必要があるか を定める構造

つまり、

• eval は 適合性の判断
• approval は 制度的採用の確定

です。

多くの approval point には、precondition として required eval がぶら下がります。

たとえば、

• regression tests pass
• policy check pass
• required review evidence present

が満たされて初めて approval が開くことがあります。

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

approval_open(point, subject) iff
  subject_is_bound(point, subject)
  and preconditions(point, subject) are satisfied
  and required_evals(point, subject) are completed

ここで重要なのは、
approval point は eval を置き換えない
ということです。

---

Approval Point と Governance Surface の関係

Approval Point は Governance Surface の局所的な構造要素です。

Governance Surface

visibility、capability、approval、evaluation、promotion、audit、recovery などを含む広い統治面

Approval Point

そのうち approval surface を構成する、局所的で subject-specific な点

つまり、

• governance surface は面
• approval point はその面上の局所 gate

です。

Approval Point があることで、

• どこで止まるか
• 誰の authority が必要か
• approval pending がどこにあるか
• approval record をどこで残すか

が明示されます。

---

Approval Point と Process Delta の関係

Approval Point は、しばしば Process Delta を subject とします。
そのとき approval は delta に対して次のことを行います。

1. admissibility を ratify する

この delta item を先へ進めてよいかを確定します。

2. next transition を unlock する

たとえば、

• promote
• merge
• close
• return_to_parent
• next phase start

などが legal になります。

3. coordination delta を生みうる

approval 自体が

• approval decision record
• rejection note
• request changes note
• escalation note

といった coordination / governance delta を生みえます。

重要なのは、
approval point が subject を canonical truth に変えるのではなく、
次の legal transition を開く ということです。
canonical 化は、必要なら promote / merge の遷移で別途起こります。

---

Approval Point と Recovery Point の関係

pending approval は、非常に重要な recovery boundary です。
そのため Approval Point は Recovery Point と強く結びつきます。

approval-wait recovery point が必要な理由

• 誰の承認待ちかを失わないため
• どの subject が pending かを失わないため
• required evidence を再構築せずに済むようにするため
• stale な subject なら再提出条件を明示するため

recover / resume のとき必要なこと

• pending approval point がまだ有効か
• subject が stale になっていないか
• required authority が変わっていないか
• required eval result がまだ current か

つまり Approval Point は、
process を止める構造 であると同時に、
正しく再開するための anchor でもあります。

---

Approval Point と Handoff の関係

多くの approval は、実際には Handoff を伴います。

approval handoff の例

• coding agent → reviewer
• child frame → parent approver
• memory candidate proposer → memory writer
• escalation source → incident owner

このとき Approval Point は、handoff の target condition を定めます。

• 何が subject か
• 何の evidence が必要か
• どの authority に差し出すべきか
• 何を返してほしいか
• reject / request_changes 時にどこへ戻るか

したがって Approval Point は、
単なる「承認が必要な場所」ではなく、
approval-oriented handoff topology の基準点 とも言えます。

---

Approval Point のトポロジ

approval は単一の approver だけとは限りません。
PCE 2.0 では、少なくとも次の topology を区別できます。

1. Single Approver

一人の authority actor が ratify します。

例:

• reviewer による code review approval

2. Ordered Chain

順序付きの承認です。

例:

• evaluator pass → reviewer approval → product owner approval

3. Conjunctive Approval

複数の actor の全員承認が必要です。

例:

• security + domain owner + release manager

4. Any-of / Delegated Approval

許可された actor の誰か一人で足りる場合です。
ただし delegation path は明示されるべきです。

5. Quorum Approval

一定数または一定条件の approver による承認です。
組織的な意思決定に近い場合があります。

6. Conditional Approval

特定の修正や follow-up を条件に前へ進める承認です。
その条件が次の gate や pending item として残る必要があります。

7. Override / Exception Approval

通常の blocking rule を例外的に越える approval です。
これは通常 approval より強い traceability を要します。

この topology は、Approval Point の required_authority と decision_rule に現れます。

---

Approval Point の状態

Approval Point は構造ですが、個々の subject に対しては状態を持ちます。
最低限、次のような状態を想定できます。

• defined
  frame に存在するが、まだ subject がバインドされていない

• open
  subject が存在し、required preconditions を満たし、承認可能状態にある

• pending
  approver に提出され、verdict 待ちである

• satisfied
  required approval が成立した

• rejected
  authority により拒否された

• needs_changes
  再作業を要求された

• insufficient_evidence
  evidence 不足で判定不能

• escalated
  approver の bundle を越える問題として引き上げられた

• expired
  subject stale / timeout / governance drift により再提出が必要

• superseded
  subject 自体が差し替えられたため、この pending approval は無効になった

この状態を持つことで、pending approval が recovery 可能な process state になります。

---

Silence や timeout を approval とみなしてよいか

PCE 2.0 では、明示されていない silence は approval ではありません。

ただし、組織によっては

• timeout auto-approve
• no-objection-after-N-hours
• delegated fallback approval

を採用することがあります。
その場合でも、それは Approval Point の decision_rule に明示されるべきです。

暗黙の「たぶん問題ないだろう」は、Approval Point としては不十分です。

---

Approval Point の最小スキーマ

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

approval_point:
  point_id:
  frame_id:
  kind:
  subject:
    kind:
    ref:
    scope:
  purpose:
  required_authority:
    actors:
    bundle_condition:
    topology:
  preconditions:
    required_evals:
    required_evidence:
    prior_points:
    policy_conditions:
  allowed_verdicts:
    - approve
    - reject
    - request_changes
    - insufficient_evidence
    - escalate
  decision_rule:
  on_verdict:
    approve:
      unlocks:
      next_transitions:
    reject:
      next_transitions:
    request_changes:
      next_transitions:
    insufficient_evidence:
      next_transitions:
    escalate:
      next_transitions:
  expiry_policy:
  audit_requirements:
  provenance:

より point-state 指向に書くなら、次のようにも置けます。

approval_point_instance:
  point_ref:
  subject_ref:
  state:
    # open | pending | satisfied | rejected | needs_changes | insufficient_evidence | escalated | expired | superseded
  submitted_by:
  submitted_at:
  required_authority_refs:
  evidence_refs:
  blocking: true | false
  decision_record:
    verdict:
    decided_by:
    decided_at:
    rationale:
  next_transition_unlocks:
  recovery_binding:
  freshness:

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

1. point 定義と subject ごとの instance を分けられる
2. required authority と preconditions がある
3. verdict とその効果が定義されている
4. audit / recovery / freshness を持てる

つまり Approval Point は、
subject-specific に解かれる authority gate
です。

---

小さな例

「checkout にクーポン併用制約を追加する」frame における approval point の例です。

1. Spec approval point

approval_point:
  point_id: ap.feature.checkout.coupon-combination.spec
  frame_id: feature.checkout.coupon-combination
  kind: phase_approval
  subject:
    kind: spec_candidate
    ref: approved_spec_summary_candidate
    scope: feature.checkout.coupon-combination
  purpose: >
    implementation に進む前に、仕様案を採用してよいかを ratify する。
  required_authority:
    actors:
      - product_owner
    bundle_condition: approval_authority_for_spec
    topology: single_approver
  preconditions:
    required_evals:
      - spec_review_eval
    required_evidence:
      - spec_summary
      - unresolved_issues_list
      - scope_note
    prior_points: []
    policy_conditions:
      - no_open_scope_conflict
  allowed_verdicts:
    - approve
    - reject
    - request_changes
    - escalate
  decision_rule: single_actor_explicit_verdict
  on_verdict:
    approve:
      unlocks:
        - implementation_phase_start
      next_transitions:
        - assign
        - compile-context
    reject:
      next_transitions:
        - replan
    request_changes:
      next_transitions:
        - rework_spec
    escalate:
      next_transitions:
        - escalate
  expiry_policy:
    expires_when:
      - spec_candidate_changes
      - scope_reframed
  audit_requirements:
    - decision_record
    - rationale
  provenance:
    defined_by: product_owner

2. Code review approval point

approval_point:
  point_id: ap.feature.checkout.coupon-combination.code-review
  frame_id: feature.checkout.coupon-combination
  kind: artifact_approval
  subject:
    kind: artifact_delta
    ref: delta_item.code_patch
    scope: feature.checkout.coupon-combination
  purpose: >
    code patch を merge-ready とみなしてよいかを ratify する。
  required_authority:
    actors:
      - reviewer
    bundle_condition: approval_authority_for_code_change
    topology: single_approver
  preconditions:
    required_evals:
      - eval.feature.checkout.coupon-combination.artifact.v1
    required_evidence:
      - code_diff
      - ci_report
      - approved_spec_summary
      - rollback_note
    prior_points:
      - ap.feature.checkout.coupon-combination.spec
    policy_conditions:
      - no_scope_violation
  allowed_verdicts:
    - approve
    - reject
    - request_changes
    - insufficient_evidence
    - escalate
  decision_rule: all_preconditions_met_then_single_actor_explicit_verdict
  on_verdict:
    approve:
      unlocks:
        - promote_artifact_delta
        - merge_candidate_state
      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
  expiry_policy:
    expires_when:
      - code_diff_changes
      - required_eval_results_change
      - governance_rule_changed
  audit_requirements:
    - approval_record
    - reviewer_rationale
  provenance:
    defined_by: reviewer

この例で重要なのは、approval point が単なる「レビューする工程」ではなく、

• 何を subject とし
• 誰の authority を必要とし
• どの eval を prerequisite とし
• どの verdict がどの遷移を解禁するのか

を持っていることです。

---

Approval Point の不変条件

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

1. Every approval point belongs to a frame

どの approval point も、特定の frame に属していなければなりません。

2. Every approval point has an explicit subject

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

3. No approval without authority basis

approver identity だけでは不十分です。
bundle 上の approval authority の基礎が必要です。

4. No approval point without verdict semantics

approve / reject / request_changes / escalate などの結果とその効果が必要です。

5. No silent bypass of required eval

blocking eval が prerequisite なら、approval point はそれを暗黙に飛ばしてはなりません。
飛ばすなら explicit override point が必要です。

6. Pending approval must be recoverable

pending 状態は recovery point として再開可能でなければなりません。

7. No hidden authority transfer through submission

subject を提出した actor が、そのまま approver になるわけではありません。
提出と承認を混同してはなりません。

8. Approval records must be traceable

誰が、何に対して、どの evidence を見て、どの verdict を出したか追える必要があります。

9. Approval point is not durable truth by itself

approval point が満たされたことは重要ですが、
canonical durable state の更新は promote / merge など別遷移で起こるべきです。

---

いつ新しい Approval Point を切るべきか

実務上は、どこに approval point を置くべきかが重要です。
典型条件は次のとおりです。

1. Authority boundary が変わるとき

別の approver、別の approval scope、別の risk tier が必要になる場合です。

2. Subject type が変わるとき

artifact、decision、memory candidate、reframe proposal は別 approval point にするのが自然です。

3. Phase boundary をまたぐとき

spec → implementation、implementation → merge、merge → release などです。

4. High-impact durable write が起きるとき

canonical merge や high-value memory promotion は独立した approval point を持つべきです。

5. Exception / override path が必要なとき

通常フローと例外フローは別 point にした方が traceability が高いです。

6. Recovery / resume が risk-sensitive なとき

高リスクな再開や rollback 後の再進行には独立 approval point がある方がよいです。

短く言えば、
subject、authority、risk、phase、durable impact のいずれかが大きく変わるなら、新しい approval point を切る
のが基本です。

---

最低限の自己点検

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

1. どこで authority による ratification が必要か明示できるか
2. approval point と approve / reject transition を区別できるか
3. subject と required authority を言えるか
4. required eval と approval を混同していないか
5. verdict ごとの next transition が定義されているか
6. pending approval を recovery 可能な状態として扱えるか
7. approval topology（single / chain / quorum / override）を表現できるか
8. approval record の traceability があるか
9. approval による durable state 変更と promote / merge を分けて考えられるか
10. silent approval や implicit approval を rule として明示しているか

このどれかが欠けるなら、その process はまだ approval-aware ではありません。

---

関連する概念

Approval Points は、PCE 2.0 の authority semantics の中核として、次の概念と強く結びつきます。

• Transitions
• Handoff
• Process Frame
• Responsibility Bundle
• Governance Surface
• Process Delta
• Actor
• Actor-local Compiled Context
• Recovery Point
• Eval Contract
• Memory Promotion Rules
• Checkpoint and Recovery

---

暫定的なまとめ

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

approval は、誰かが後から見て問題ないと言うことではない。
process のどの地点で、どの subject に対して、誰のどの authority による ratification が必要かを、構造として先に置くことである。

PCE 2.0 において approval は補助的な確認ではありません。
それは legal transition を開く authority gate です。
そして Approval Point は、その gate を process 上に固定する構造です。

だから Approval Points は、単なるレビュー工程ではありません。
それは、PCE 2.0 において 実行と採用、評価と ratification、pending と progression を切り分ける authority structure です。