Recovery Point

定義

Recovery Point

Recovery Point とは、ある process frame のある時点における
再開可能な状態を、意味的に保存した再開点 である。

それは単なる transcript や session dump ではなく、
frame identity、runtime snapshot、responsibility snapshot、pending gates、delta state、durable refs、recovery constraints、context recompile requirements を、
将来の recover / resume に耐える形で保持する。

より短く言えば、Recovery Point とは
「この process を、何を引き継ぎ、何を再検証し、何を再コンパイルし、どの条件で再開できるのか」を保存した再開用状態
である。

PCE 2.0 において recovery は実装上の convenience ではありません。
それは、長時間・多段・多主体の process を継続可能にするための存在論的条件です。
Recovery Point は、その継続可能性を process の内部に持ち込むための概念です。

この意味で Recovery Point は、
Process-first と No merge without eval を、長時間継続の側から支える ontology です。

なぜ Recovery Point が必要なのか

AI 時代の process は、しばしば一つの連続した session では完了しません。
途中で少なくとも次のことが起きます。

context window を越える
approval 待ちで止まる
evaluator の結果待ちになる
外部依存の解消を待つ
失敗して rollback / replan が必要になる
actor をまたいで handoff する
同じ frame を別の session で再開する

このとき、単なる会話履歴や raw transcript では process を安全に再開できません。
足りないのは情報量ではなく、再開意味論 です。

再開に本当に必要なのは、たとえば次です。

いまどの frame にいるのか
どの phase で止まっているのか
誰がどの責任を持っているのか
何が未承認か
何が評価待ちか
どの delta が pending か
旧 context をそのまま使ってよいのか
何を再コンパイルすべきか
どの authority で resume できるのか

Recovery Point は、これを保存します。

言い換えると、Recovery Point は
「中断された仕事を、責任と統治を失わずに再開するための durable な再開構造」
です。

Recovery Point は何ではないか

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

1. 単なるチャット履歴ではない

会話履歴は素材にはなりますが、それだけでは再開できません。
責任状態、pending approval、delta lifecycle、stale context の扱いが抜けています。

2. 単なる runtime state dump ではない

システム内部状態をそのまま保存しても、future process が意味的に再開できるとは限りません。
Recovery Point は、再開に必要な意味的構造を持たなければなりません。

3. 単なる checkpoint transition ではない

checkpoint は Transitions 上の出来事です。
Recovery Point は、その結果として生成される保存対象です。

4. 単なる recover transition ではない

recover は保存済み再開点を再活性化する transition です。
Recovery Point は、その transition の入力であり対象です。

5. 単なる durable memory ではない

Recovery Point は durable に保存されますが、通常は canonical memory ではありません。
多くの場合、Durable Project State の provisional zone に属します。

6. 単なる last known good artifact ではない

「戻せる commit」があることは重要ですが、それだけでは process は再開できません。
責任状態、pending gates、次の legal transition が必要です。

7. 単なる handoff note ではない

handoff note は recovery に役立つことがありますが、Recovery Point は handoff より広く、
同一 actor による later resume も含みます。

Recovery Point は「再開可能性」を保存する

Recovery Point が保存するのは、全知的な snapshot ではありません。
保存するのは、再開可能性 です。

ここでいう再開可能性には、少なくとも次が含まれます。

1. Identity Continuity

どの frame の continuation なのかが分かること。

2. Responsibility Continuity

どの actor / bundle が active / suspended / pending なのかが分かること。

3. Gate Continuity

どの approval、evaluation、policy condition が未完了なのかが分かること。

4. Delta Continuity

どの Process Delta が emitted / under review / pending promotion なのかが分かること。

5. Context Continuity

どの local context をそのまま再利用してよいか、どれを再コンパイルすべきかが分かること。

6. Authority Continuity

誰が resume、approve、merge、rollback、escalate できるのかが変わっていないか確認できること。

7. Evidence Continuity

どの evidence や durable refs が再開に必要かが失われていないこと。

つまり Recovery Point は、
「再開できるように十分なもの」を保存し、
「再開時に改めて検証すべきもの」を明示する
存在です。

Checkpoint / Recovery Point / Recover / Resume の違い

この区別はとても重要です。

Checkpoint

ある時点の process を、再開可能な形で保存する transition です。

Recovery Point

checkpoint の結果として得られる、再開可能状態の durable item です。

Recover

Recovery Point から runtime を再構成する transition です。
ただし recover しただけで直ちに safe continuation になるとは限りません。

Resume

recover 後に、必要な revalidation / recompile / reauthorization を経て、実行を再開する transition です。

概念的には、次のようになります。

checkpoint(frame_state_t) -> recovery_point_r
recover(recovery_point_r) -> restored_runtime_state
resume(restored_runtime_state) -> active_progression

ここで重要なのは、
recover は戻すこと、resume は進め直すこと
だという点です。

Recovery Point が保持すべき構成要素

PCE 2.0 では、Recovery Point は少なくとも次を持つべきです。

1. Frame Identity

どの Process Frame の再開点か。
frame_id、parent_frame_id、captured_boundary などを含みます。

2. Runtime Snapshot

その時点の frame の runtime 状態です。

current phase
active / blocked / pending approval / suspended などの state
unresolved issues
pending dependencies
next expected boundary

3. Responsibility Snapshot

その時点での責任状態です。

active bundles
suspended bundles
pending authority
required approver / evaluator / memory writer
escalation ownership

4. Gate Snapshot

まだ通過していない gate です。

pending approval
pending evaluation
policy block
missing required evidence
merge blocked state

5. Delta Snapshot

すでに生成された delta とその lifecycle 状態です。

emitted delta refs
under review delta refs
evaluated-but-unmerged refs
pending promotion refs

6. Context Continuity Metadata

どの local context が有効か、どれが stale か、何を再コンパイルすべきかです。

reusable context refs
stale_on_recover list
recompile_required_for
allowed reuse window

7. Durable References

再開に必要な durable items への参照です。

canonical artifacts
approved summaries
accepted decisions
governance records
evaluation baselines

8. Recovery Constraints

recover / resume に必要な条件です。

integrity checks
required authority for resume
legal next transitions
restore limitations
escalation path

9. Provenance

いつ、どの transition によって、どの根拠で作られた recovery point かを示します。

10. Freshness / Invalidation

どの条件でこの recovery point が stale / invalid になるかを示します。

Recovery Point は「全部を保存する」ものではない

Recovery Point は process continuity のためのものですが、
だからといってすべてを by-value で保存すべきではありません。

保存しすぎると起きる問題

古い local context を盲目的に再利用しやすい
state drift を見落とす
storage と reasoning の両方が重くなる
raw transcript が recovery item を汚す

保存しなさすぎると起きる問題

何を pending として再開すべきか分からない
authority / approval の状態が失われる
recover 後に同じ work をやり直す
expensive evidence を再取得する必要が出る

したがって Recovery Point の本質は、
完全保存ではなく、再開に必要な最小十分構造の保存 にあります。

By-value と By-reference

Recovery Point では、by-value と by-reference を使い分けるのが自然です。

By-value で持つべきもの

current phase summary
unresolved issues
pending gate summary
allowed next transitions
recovery constraints
short recovery note

By-reference で持つべきもの

code diff refs
full evaluation report refs
artifact refs
decision refs
delta refs
prior recovery point refs
large trace refs

この使い分けにより、Recovery Point は

軽量に保持され
それでも再開に必要な深さへ辿れ
stale context の再利用を防ぎやすい

という性質を持てます。

Recovery Point と Context の関係

これは特に重要です。
PCE 2.0 では、Actor-local Compiled Context は state や責任条件に従属します。
したがって recovery の後、旧 context をそのまま使えるとは限りません。

Recovery Point がしなければならないこと

どの context snapshot が再利用可能かを示す
どの context が stale になったかを示す
どの actor に対して recompile が必要かを示す

してはならないこと

旧 prompt / 旧 local view を canonical truth のように扱うこと
approval や replan の後も旧 context を無条件に流用すること

このため Recovery Point は、
context そのもの よりも
context の再利用条件 を保存するべきです。

Warm Recovery と Cold Recovery

PCE 2.0 では、Recovery Point を二つの型に分けて考えると有用です。

1. Warm Recovery Point

比較的短い中断や同一 session に近い再開を前提にした再開点です。

特徴:

local context snapshot を含みやすい
recompile コストが低い
ただし stale になりやすい

2. Cold Recovery Point

時間をまたいだ再開や actor 交代を前提にした再開点です。

特徴:

raw context より refs と summaries を重視する
recompile 前提で設計される
stale 耐性が高い

この区別により、Recovery Point は「ただ保存する」のではなく、
どの kind の再開を想定しているか まで持てるようになります。

Recovery Point の基本型

PCE 2.0 では、少なくとも次の recovery point type を区別できます。

1. Execution Checkpoint

進行中の work を将来再開するための再開点です。
典型的には phase の途中、または expensive work の後に作られます。

2. Approval-Wait Point

approval 待ちで停止している再開点です。
誰の承認を待っているかが重要です。

3. Evaluation-Wait Point

評価待ち、または評価結果待ちで停止している再開点です。
required evaluator と expected verdict を持ちます。

4. Handoff Recovery Point

別 actor、別 session、別 system へ引き継ぐための再開点です。
handoff package と closely related ですが、再開可能性を主目的に持ちます。

5. Rollback Anchor

誤った進行の前へ安全に戻るための基準点です。
「last known good state」に近い役割を持ちます。

6. Escalation Hold Point

曖昧性、incident、authority overflow により escalation した後、
状況が整理されるまで保留される再開点です。

7. Merge-Ready Point

評価と approval が通過し、merge 直前で停止している再開点です。
ここでは durable write の authority と admissibility が重要になります。

Recovery Point と Recovery Surface の関係

Governance Surface の中には、recovery に関わる面があります。
Recovery Point は、その surface が参照する対象です。

Recovery Surface にはたとえば次が含まれます。

checkpoint を切ってよい条件
recover に必要な integrity check
resume に必要な authority
stale contexts の扱い
recover 後に legal な next transitions
rollback anchor の利用条件

つまり Recovery Point は単なる保存物ではなく、
recovery surface によって govern される durable object です。

Recovery Point と Durable Project State の関係

Recovery Point は、通常 Durable Project State の provisional zone に属します。

理由は明確です。

recovery point は durable ではある
しかし canonical project truth ではない
future process の再開には必要
しかしそのまま reusable knowledge として一般化すべきではない

したがって、Recovery Point は多くの場合、

provisional / recovery_points

に置かれます。

ただし、長期保全価値のある resumable summary や rollback anchor が、
将来の incident analysis や governance record に昇格することはありえます。
その場合も、recovery point 自体と derived memory は区別すべきです。

Recovery Point と Process Delta の関係

Recovery Point はしばしば Process Delta と結びつきます。

1. Checkpoint が Recovery Delta を生む

checkpoint transition は、recovery kind の delta item を emit できます。
その item が provisional zone の recovery point collection を更新します。

2. Recovery Point は Delta State を保持する

再開時には、どの delta が emitted / under review / pending promotion なのかが必要です。
Recovery Point は delta lifecycle refs を含むべきです。

3. Recover 後に新しい Delta が生まれうる

recovery の結果として、

resumed coordination delta
replan delta
invalidation note
rollback note

などが生成されることがあります。

つまり Recovery Point は、delta の外側にあるのではなく、
delta lifecycle の継続性を保持する装置 です。

Recovery Point と Transition の関係

Recovery Point は、Transitions と強く結びつきます。

生成する遷移

checkpoint
suspend
handoff の一部
rollback-anchor creation

消費する遷移

recover
resume
rollback
replan の起点

無効化しうる遷移

approve
reject
reframe
delegate / revoke
merge
governance update

特に重要なのは、
ある transition が Recovery Point を stale / invalid にしうる
という点です。

Invalidation と Reconciliation

Recovery Point は永遠にそのまま使えるとは限りません。
次のようなことが起きると、回復前に revalidation や reconcile が必要になります。

1. Durable State Drift

recovery point 作成後に canonical artifacts や decisions が変わった場合です。

2. Governance Drift

approval rule、policy、authority boundary が変わった場合です。

3. Bundle Drift

resume すべき actor の責任状態が変わった場合です。

4. Scope Drift

frame の goal / scope / success criteria が reframe された場合です。

5. Context Drift

旧 local context が stale になった場合です。

このため Recovery Point は、少なくとも次を持つべきです。

invalidation conditions
recompile requirements
reconcile against current durable state
resume authority check

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

recoverable(rp, current_state) iff
  integrity_ok(rp)
  and frame_match(rp)
  and required_refs_available(rp)
  and no_hard_invalidation(rp, current_state)
  and stale_contexts_are_recompiled(rp, current_state)
  and required_authority_for_resume(rp, current_state)

ここで重要なのは、
recover は snapshot を盲目的に戻すことではない
ということです。
recover は、現在の durable reality と整合する形で再開可能性を再構成することです。

Recovery Point の最小スキーマ

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

recovery_point:
  recovery_id:
  frame_id:
  parent_recovery_id:
  kind:
  status:
  captured_at_boundary:
  source_transition:
  runtime_snapshot:
    frame_state:
    phase:
    unresolved_issues:
    pending_dependencies:
  responsibility_snapshot:
    active_bundles:
    suspended_bundles:
    required_authorities_for_resume:
  gate_snapshot:
    pending_approvals:
    pending_evals:
    policy_blocks:
  delta_snapshot:
    emitted_delta_refs:
    under_review_refs:
    pending_promotion_refs:
  context_continuity:
    reusable_context_refs:
    stale_on_recover:
    recompile_required_for:
  durable_refs:
    canonical_refs:
    provisional_refs:
  recovery_constraints:
    integrity_checks:
    allowed_next_transitions:
    restore_strategy:
    escalation_path:
  invalidation_conditions:
  freshness:
  provenance:

もう少し item 指向に書くなら、次のようにも置けます。

recovery_point:
  recovery_id:
  frame_ref:
  type:
    # execution | approval_wait | evaluation_wait | handoff | rollback_anchor | escalation_hold | merge_ready
  durability:
    zone: provisional
    collection: recovery_points
  baseline_refs:
    process_frame:
    durable_state_epoch:
    governance_surface_ref:
  resumable_scope:
  runtime_snapshot:
  responsibility_snapshot:
  pending_gates:
  delta_state_refs:
  context_state:
    reusable_refs:
    must_recompile:
    invalidated_by:
  restore_contract:
    integrity_checks:
    required_authority:
    legal_next_transitions:
  evidence_refs:
  provenance:
  retention:
  freshness:

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

frame と boundary がある
runtime と responsibility の両方を持つ
pending gates と delta state を持つ
context 再利用条件を持つ
restore contract を持つ
provisional durable item として位置づけられる

小さな例

「checkout にクーポン併用制約を追加する」frame が、implementation 完了後に reviewer 承認待ちで停止したとします。
そのときの Recovery Point の例です。

recovery_point:
  recovery_id: rp.feature.checkout.coupon-combination.after-impl.v1
  frame_id: feature.checkout.coupon-combination
  parent_recovery_id: null
  kind: approval_wait
  status: provisional
  captured_at_boundary: implementation_completed
  source_transition: checkpoint.after_implementation
  runtime_snapshot:
    frame_state: pending_approval
    phase: implementation_completed
    unresolved_issues:
      - edge_case_for_stacked_discount_rounding
    pending_dependencies:
      - reviewer_approval
  responsibility_snapshot:
    active_bundles:
      - reviewer_bundle_v1
      - product_owner_goal_bundle_v1
    suspended_bundles:
      - coding_agent_impl_bundle_v2
    required_authorities_for_resume:
      - reviewer
  gate_snapshot:
    pending_approvals:
      - code_review_approval
    pending_evals:
      - required_regression_suite_confirmation
    policy_blocks: []
  delta_snapshot:
    emitted_delta_refs:
      - delta.feature.checkout.coupon-combination.v3
    under_review_refs:
      - delta_item.code_patch
      - delta_item.accepted_rationale
    pending_promotion_refs:
      - delta_item.edge_case_playbook_candidate
  context_continuity:
    reusable_context_refs:
      - reviewer_review_package_v1
    stale_on_recover:
      - coding_agent_impl_context_v2
    recompile_required_for:
      - coding_agent
      - memory_writer
  durable_refs:
    canonical_refs:
      - artifact.spec.coupon-combination.v1
      - decision.no-payment-gateway-change
    provisional_refs:
      - checkpoint.feature.checkout.coupon-combination.after-implementation
  recovery_constraints:
    integrity_checks:
      - confirm_delta_ref_exists
      - confirm_required_ci_report_exists
    allowed_next_transitions:
      - recover
      - approve
      - reject
      - escalate
    restore_strategy: rehydrate_review_state_then_resume_from_approval_gate
    escalation_path: product_owner
  invalidation_conditions:
    - approved_spec_version_changes
    - governance_rule_changed
    - code_diff_ref_missing
  freshness:
    valid_until: next_scope_or_policy_change
  provenance:
    created_by: checkpoint_manager
    created_from_transition: checkpoint.after_implementation

この例で重要なのは、保存されているのが単なる transcript ではなく、

pending approval
active / suspended bundle
delta lifecycle
stale context
next legal transitions

であることです。

Recovery Point の不変条件

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

1. Every recovery point belongs to a frame

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

2. Recovery point is provisional by default

recovery point は durable ではあっても、通常 canonical memory ではありません。

3. Every recovery point must preserve gate continuity

pending approval / eval / policy block などの gate 状態を失ってはなりません。

4. Every recovery point must state context reuse conditions

どの context が再利用可能で、どれが再コンパイル必要か明示されていなければなりません。

5. Recovery must not create authority out of thin air

recover によって approval authority や memory write authority が新しく生まれてはなりません。
authority は restore されるか、再確認されるべきです。

6. Recovery point must be integrity-checkable

required refs が消えていたり、delta lifecycle が壊れていたりするなら、その recovery point は usable ではありません。

7. Recovery point must not override newer canonical truth

recovery point 作成後に canonical state が変わっているなら、reconcile なしに古い前提へ戻してはなりません。

8. Recovery point must support legal next transitions

recover 後に何をしてよいか分からない recovery point は不完全です。

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

実務上は、何でも checkpoint すればよいわけではありません。
新しい Recovery Point を切るべき典型条件は次のとおりです。

1. 意味のある phase boundary に到達したとき

analysis 完了、implementation 完了、evaluation 完了などです。

2. Approval / Evaluation 待ちに入る直前

人待ち・外部待ち・システム待ちに入るなら、再開点を明示した方がよいです。

3. 高コストな evidence を生成した直後

長いテストや調査結果を再利用したい場合です。

4. Risky Transition の直前

merge 前、policy-sensitive action 前、replan 前などです。
rollback anchor としても役立ちます。

5. Actor Handoff の前

別 actor / 別 session / 別 system へ渡すなら recovery semantics を持つ方が強いです。

6. Session 終了前

後で再開する可能性が高いなら、単なる transcript より recovery point が望ましいです。

7. Governance が変わる直前 / 直後

scope change、authority change、policy update の前後では古い context が stale になりやすいからです。

短く言えば、
phase、gate、risk、handoff、session boundary のいずれかをまたぐなら、Recovery Point を切る意味がある
と考えるのが基本です。

最低限の自己点検

ある継続設計が recovery-aware かどうかは、次で点検できます。

transcript ではなく、再開意味論を保存しているか
frame identity と runtime state を区別して保存しているか
responsibility snapshot を持っているか
pending approvals / evals / policy blocks を失っていないか
delta lifecycle refs を持っているか
context の再利用条件と再コンパイル条件があるか
recover / resume に必要な authority が明示されているか
invalidation conditions があるか
durable state drift に対する reconcile を考えているか
recovery point が provisional durable item として位置づけられているか

このどれかが欠けるなら、その継続設計はまだ Recovery Point を十分に持っていません。

暫定的なまとめ

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

長い process は、会話を保存しただけでは再開できない。
何の frame で、どの責任状態で、どの gate を残し、どの delta を保留し、どの context を再コンパイルし、どの authority で resume できるのかが保存されてはじめて再開できる。

PCE 2.0 において recovery は付属機能ではありません。
それは継続可能性の意味論です。
そして Recovery Point は、その意味論を durable に保持するための再開単位です。

だから Recovery Point は、単なる checkpoint file ではありません。
それは、PCE 2.0 において 中断された仕事を、責任と統治を失わずに再開するための存在論的再開点 です。