Checkpoint and Recovery

定義

Checkpoint and Recovery

PCE 2.0 における Checkpoint and Recovery とは、
進行中の process frame の continuity を Recovery Point として保存し、
後続の session、actor、runtime において、
responsibility、pending gates、delta state、durable refs、authority conditions を保ったまま
合法的かつ統治可能に process を再開するための継続機構 である。

このとき、

Checkpoint は、ある時点の process continuity を Recovery Point として切り出して保存する transition

Recovery は、その Recovery Point を現在の durable project state と照合し、必要な revalidation・recompilation を経て runtime を再構成する transition family

Resume は、recover 済み状態から、再び legal transition を取り始める transition

を指す。

より短く言えば、Checkpoint and Recovery とは
「中断された仕事を、責任・統治・前提条件を失わずに、後で安全に続けられるようにする仕組み」
である。

PCE 2.0 において継続性は、副次的な利便機能ではありません。
それは long-running / multi-actor / multi-session process を成立させる条件です。
Checkpoint and Recovery は、その条件を process semantics として明示する概念です。

なぜ Checkpoint and Recovery が必要なのか

AI 時代の process は、単一の連続セッションで最後まで進むとは限りません。
少なくとも、次のような中断が常態になります。

context window や session 境界をまたぐ
approval 待ちで止まる
evaluation 結果待ちで止まる
actor が交代する
policy や scope が変わる
failure により replan / rollback が必要になる
runtime が pause / suspend / timeout する
同じ frame を別の日・別の actor が引き継ぐ

このとき、単なる transcript 保存では process は再開できません。
本当に必要なのは、次の continuity です。

1. Frame continuity

どの仕事単位の continuation なのか。

2. Responsibility continuity

誰が何を引き受けたまま止まっているのか。

3. Gate continuity

どの approval / eval / policy gate が未解決なのか。

4. Delta continuity

どの Process Delta が emitted / pending / under review なのか。

5. Governance continuity

何が legal で、何が blocked で、誰が resume / approve / merge できるのか。

6. Context continuity

どの local context がまだ有効で、どれを再コンパイルしなければならないのか。

Checkpoint and Recovery は、これらを保存し、再構成するために必要です。

Checkpoint / Recovery / Resume / Rollback / Handoff の違い

この区別は重要です。

Checkpoint

ある時点の process continuity を、再開可能な形で保存する transition です。
その結果は通常 Recovery Point として残ります。

Recovery

Recovery Point を使って runtime continuity を再構成する transition family です。
ただし recover しただけで直ちに active progression になるとは限りません。

Resume

recover 後に、必要な integrity check、authority check、context recompile を経て、
再び active な legal transition を開始する transition です。

Rollback

不適切な進行や不整合を、以前の許容状態へ戻す transition です。
rollback anchor として Recovery Point を使うことがあります。

Handoff

continuity を別 actor / frame へ受け渡す transition です。
handoff はしばしば checkpoint と結びつきますが、保存ではなく移送が中心です。

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

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

rollback(current_state, rollback_anchor) -> prior_acceptable_state
handoff(current_state, target_actor/frame) -> continuity_transfer

ここで重要なのは、
recover = 元に戻すこと ではなく、
recover = いまの durable reality と整合するように継続可能性を再構成すること
だという点です。

Checkpoint and Recovery は何ではないか

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

1. 単なる transcript 保存ではない

チャット履歴やログを残すだけでは、責任状態や pending gate を再開できません。

2. 単なる state serialization ではない

内部メモリを dump するだけでは、legal next transition や authority continuity は保証されません。

3. 単なる retry 機構ではない

retry は同じ action を再実行することですが、
Checkpoint and Recovery は process continuity 全体を扱います。

4. 単なる compaction ではない

context を短くすることは有用ですが、それだけでは recovery semantics にはなりません。

5. 単なる backup ではない

backup は保全のためですが、Recovery Point は future process が意味的に再開するための再開単位です。

6. 単なる session persistence ではない

session を跨いで状態が残ること自体は便利ですが、
PCE 2.0 ではそれを frame / gate / bundle / delta continuity として扱う必要があります。

Checkpoint の本質

PCE 2.0 において Checkpoint は、
現在の進行状態を、そのまま後で再開可能な意味構造へ切り出す transition です。

Checkpoint がやるべきことは三つあります。

1. 保存する

現在の continuity を Recovery Point として durable に保存する。

2. 境界づける

どの boundary で切ったのかを明示する。

例:

implementation completed
pending approval
evaluation completed
handoff prepared
rollback anchor

3. 未来の再開条件を固定する

recover / resume のとき必要な条件を明示する。

つまり Checkpoint は、単なる保存ではなく、
「ここからどう戻り、どう続けるか」を定義した切断 です。

Checkpoint が保存すべきもの

Checkpoint の結果として生成される Recovery Point は、少なくとも次を保存すべきです。

1. Frame identity

frame id
parent frame relation
captured boundary

2. Runtime snapshot

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

3. Responsibility snapshot

active bundles
suspended bundles
pending approver / evaluator / memory writer
escalation owner

4. Gate snapshot

pending approvals
pending evals
policy blocks
required evidence still missing

5. Delta snapshot

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

6. Context continuity metadata

reusable context refs
stale on recover
must recompile for which actors

7. Durable refs

canonical artifacts needed for restart
approved decisions
governance refs
evaluation baselines

8. Recovery constraints

integrity checks
legal next transitions
required authority for resume
escalation path

Checkpoint がこれらを持たないなら、それは単なる save point であって、
PCE 2.0 の意味での recovery point にはなりません。

どこで Checkpoint を切るべきか

何でも checkpoint すればよいわけではありません。
PCE 2.0 では、意味のある境界で切るべきです。

1. Phase boundary

analysis completed
implementation completed
evaluation completed

2. Pending gate entry

approval 待ち
evaluation 待ち
external dependency 待ち

3. Expensive evidence completed

長い test run 完了
高コストな調査完了
difficult synthesis 完了

4. Risk boundary

merge 前
policy-sensitive transition 前
reframe 前
rollback anchor として残したい時点

5. Handoff boundary

actor 交代前
child-to-parent return 前
cross-session continuation 前

6. Session boundary

作業終了前
later resume を見込むとき

短く言えば、
phase / gate / risk / handoff / session の境界をまたぐなら checkpoint を切る意味がある
と考えるのが基本です。

Checkpoint の基本型

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

1. Execution Checkpoint

進行中の work を later resume するための checkpoint です。

2. Approval-Wait Checkpoint

approval pending 状態で止めるための checkpoint です。

3. Evaluation-Wait Checkpoint

required eval の結果待ち、または evaluator handoff 待ちの checkpoint です。

4. Handoff Checkpoint

別 actor / frame / session への継続を安全化するための checkpoint です。

5. Rollback Anchor

問題発生時に戻る基準点として作る checkpoint です。

6. Escalation Hold Checkpoint

authority overflow や incident により停止した状態を保存する checkpoint です。

7. Merge-Ready Checkpoint

evaluation と approval が通り、promotion / merge 直前に置く checkpoint です。

この分類により、recover の目的も明確になります。

Recovery の本質

PCE 2.0 における Recovery は、
過去の snapshot をそのまま再生することではなく、現在の durable reality と整合する形で process continuity を再構成すること です。

Recovery は、少なくとも次のことをします。

1. Integrity check

Recovery Point が破損していないか、必要 refs が存在するかを確認する。

2. Drift detection

Recovery Point 作成後に、project state・governance・bundle・scope が変わっていないかを見る。

3. Reconciliation

変化があるなら、現在の durable reality と reconcile する。

4. Runtime reconstruction

frame の runtime state を再構成する。

5. Responsibility restoration

どの bundle を active / suspended / pending に戻すか定める。

6. Context invalidation / recompilation

古い local context をそのまま使うか、破棄して再コンパイルするか決める。

7. Gate reopening

pending approval / eval / policy block を再び process 上に立てる。

8. Legal next transition selection

resume、replan、rollback、escalate のどれが適切かを決める。

つまり Recovery は、単なる restore ではなく、
re-legalization of continuation です。

Recovery の標準フロー

PCE 2.0 では、Recovery は通常、次の順で進みます。

1. Select Recovery Point

どの recovery point から戻るかを決める。

2. Validate Integrity

必要 refs、delta refs、required evidence が存在するか確認する。

3. Reconcile With Current Durable State

新しい canonical artifact、decision、policy、approval rule が入っていないか照合する。

4. Reconstruct Runtime Skeleton

frame state、phase、pending work を復元する。

5. Rebind or Confirm Responsibility

resume 時点で有効な bundle / authority を確認する。

6. Reopen Pending Gates

approval / eval / policy blocks を復元する。

7. Recompile Actor-local Contexts

必要 actor に対して新しい local context を compile する。

8. Decide Next Transition

resume
replan
rollback
escalate
close

のいずれかへ進む。

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

recover(rp, current_durable_state, current_governance) =
  validate(rp)
  -> reconcile(rp, current_durable_state, current_governance)
  -> reconstruct_runtime(rp)
  -> restore_bundles(rp)
  -> invalidate_or_recompile_contexts(rp)
  -> reopen_pending_gates(rp)
  -> choose_legal_next_transition

Recover と Resume は分けるべきである

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

Recover

状態を再構成する
pending gate を戻す
context の再利用条件を決める
authority を確認する

Resume

recover 済み状態から active progression を再開する
execute / approve / replan / merge などの次の遷移に入る

Recover に成功しても、Resume が legal とは限りません。
たとえば次のような場合です。

required approver が変わっている
old delta が stale
scope が reframe されている
required evidence が失われている
policy rule が更新されている

したがって PCE 2.0 では、
recover = 再構成、resume = 進行再開
として厳密に分けます。

Warm Recovery と Cold Recovery

PCE 2.0 では、二つの recovery mode を区別すると便利です。

1. Warm Recovery

比較的短い中断、同一 actor、近い runtime continuity を前提とした recovery です。

特徴:

reusable context が多い
drift が少ない
recompile コストが低い
ただし stale context を使いすぎる危険がある

2. Cold Recovery

長時間中断、別 actor、別 session、governance drift の可能性を前提とした recovery です。

特徴:

refs と summaries を重視する
recompile 前提
integrity / authority / scope revalidation が強い
安全だがコストは高い

この区別により、checkpoint の作り方も変わります。

warm checkpoint は local continuity を厚く持つ
cold checkpoint は decontextualized summary と refs を重視する

Recovery と Drift

Recovery の成否は、drift に大きく左右されます。
PCE 2.0 では、少なくとも次の drift を想定すべきです。

1. Durable State Drift

canonical artifact、accepted decision、evaluation baseline が変わった。

2. Governance Drift

approval rule、policy、memory promotion rule、scope constraint が変わった。

3. Responsibility Drift

approver や incident owner、memory writer が変わった。

4. Scope Drift

goal、success criteria、in-scope / out-of-scope が変わった。

5. Context Drift

以前の local context が stale になった。

Recovery は、この drift を検出し、必要なら次のいずれかに進むべきです。

recompile and resume
replan
escalate
rollback
reject recovery

つまり Recovery は、
過去への復帰 ではなく
現在における継続可能性の再判定
です。

Checkpoint and Recovery と Governance Surface の関係

Checkpoint と Recovery は、Governance Surface によって拘束されます。

少なくとも次が surface 上で定義されるべきです。

1. Checkpoint creation policy

どの境界で checkpoint を切るか。

2. Integrity checks

recover 時に何を確認しなければならないか。

3. Resume authority

誰が resume を許可できるか。

4. Revalidation requirements

どの drift が再承認・再評価を必要とするか。

5. Recovery limits

何を復元してよく、何を無条件に復元してはならないか。

6. Auditability

checkpoint / recover / resume / rollback の履歴をどう残すか。

これがないと recovery は便利機能にはなっても、governed continuation にはなりません。

Checkpoint and Recovery と Approval Points の関係

pending approval は recovery-aware でなければなりません。
そのため Approval Points は recovery と強く結びつきます。

approval-wait checkpoint が持つべきもの

pending approval point ref
subject ref
required authority
required evidence
stale conditions

recover 後に必要なこと

approval point がまだ有効か
subject が変更されていないか
preconditions がまだ満たされているか
approver authority が drift していないか

つまり pending approval は、「止まっているだけ」ではありません。
それは recover 後に legal に reopening されるべき gate です。

Checkpoint and Recovery と Eval Contract の関係

pending eval も recovery-aware でなければなりません。
そのため Eval Contract は checkpoint / recovery に関わります。

evaluation-wait checkpoint が持つべきもの

subject ref
required eval contract refs
evaluator state
missing evidence
blocking / advisory status

recover 後に必要なこと

eval contract version が変わっていないか
required evidence が still valid か
evaluator result が stale でないか
再評価が必要か

ここで重要なのは、
recover が old eval pass を自動的に current pass に変えるわけではない
ということです。

Checkpoint and Recovery と Handoff の関係

Handoff は continuity transfer であり、
checkpoint は continuity preservation です。
両者はよく一緒に現れます。

pre-handoff checkpoint

source 側の continuation を安全に残す。

handoff-aware checkpoint

handoff package と recovery semantics を一緒に保存する。

post-handoff recovery

later session で target が同じ handoff continuation を再開する。

このため PCE 2.0 では、handoff を多用する process ほど、
checkpoint and recovery を明示的に設計する必要があります。

Checkpoint and Recovery と Process Delta の関係

Process Delta は recovery にとって重要です。

1. checkpoint は recovery delta を emit できる

checkpoint transition により、recovery kind の delta item が出ることがあります。

2. Recovery Point は delta lifecycle refs を持つ

emitted
under_review
pending_promotion
evaluated
merge_ready

などの状態を失ってはなりません。

3. recover 後に coordination delta が出ることがある

recovery completed
recovery invalidated old context
resume authorized
replan required

などです。

つまり Checkpoint and Recovery は、
delta の外側ではなく、delta continuity の一部です。

Checkpoint Policy と Recovery Strategy

PCE 2.0 では、これを Process Frame の内部に持たせるのが自然です。

Checkpoint Policy

どこで checkpoint を切るか
どの kind の checkpoint を使うか
by-value / by-reference の方針
retention mode

Recovery Strategy

どの recovery point を選ぶか
recover の integrity rules
resume に必要な authority
stale context の扱い
drift 時の fallback
replan / rollback / escalate 条件

frame が長くなるほど、この二つは重要になります。

Checkpoint and Recovery の最小スキーマ

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

checkpoint_policy:
  frame_id:
  checkpoint_boundaries:
  checkpoint_types:
  capture_requirements:
    runtime_snapshot:
    responsibility_snapshot:
    gate_snapshot:
    delta_snapshot:
    context_continuity:
  storage_policy:
    zone:
    retention:
  integrity_requirements:
  provenance_requirements:

recovery_strategy:
  frame_id:
  recovery_point_selection_rule:
  integrity_checks:
  reconciliation_checks:
    durable_state_drift:
    governance_drift:
    responsibility_drift:
    scope_drift:
  context_recompile_policy:
  resume_authority_rule:
  legal_next_transition_rule:
  fallback_paths:
    on_invalid_recovery:
    on_stale_context:
    on_missing_evidence:
    on_authority_change:

より transition-oriented に書くなら、次のようになります。

checkpoint_transition:
  transition_id:
  frame_id:
  captured_boundary:
  initiator:
  source_state_ref:
  produced_recovery_point:
  emitted_delta_refs:
  audit_refs:

recovery_transition:
  transition_id:
  frame_id:
  recovery_point_ref:
  initiator:
  integrity_result:
  reconciliation_result:
  restored_runtime_state_ref:
  invalidated_context_refs:
  recompiled_context_refs:
  unlocked_next_transitions:
  emitted_delta_refs:
  audit_refs:

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

checkpoint と recovery を分けている
capture / reconcile / recompile / resume authority がある
recovery は current state との照合を前提にしている
delta と audit に接続している

小さな例

「checkout にクーポン併用制約を追加する」frame が、implementation 完了後に reviewer approval 待ちで停止したとします。

Checkpoint

checkpoint_transition:
  transition_id: checkpoint.after-implementation
  frame_id: feature.checkout.coupon-combination
  captured_boundary: implementation_completed
  initiator: checkpoint_manager
  source_state_ref: runtime.feature.checkout.coupon-combination.v5
  produced_recovery_point: rp.feature.checkout.coupon-combination.after-impl.v1
  emitted_delta_refs:
    - delta_item.review_checkpoint
  audit_refs:
    - audit.checkpoint.after-implementation

Recovery

後日、reviewer が同じ frame を再開するとします。

recovery_transition:
  transition_id: recover.for-review
  frame_id: feature.checkout.coupon-combination
  recovery_point_ref: rp.feature.checkout.coupon-combination.after-impl.v1
  initiator: checkpoint_manager
  integrity_result:
    recovery_point_valid: true
    required_refs_present: true
  reconciliation_result:
    durable_state_drift: false
    governance_drift: false
    responsibility_drift: false
    scope_drift: false
  restored_runtime_state_ref: runtime.feature.checkout.coupon-combination.v6
  invalidated_context_refs:
    - coding_agent_impl_context_v2
  recompiled_context_refs:
    - reviewer_review_context_v2
  unlocked_next_transitions:
    - approve
    - reject
    - escalate
  emitted_delta_refs:
    - delta.recovery.for-review.v1
  audit_refs:
    - audit.recovery.for-review

この例で重要なのは、

recover 前に integrity / drift check が走っている
source context はそのまま再利用されていない
reviewer 用 context が再コンパイルされている
legal next transitions が明示されている

ことです。

Checkpoint and Recovery の不変条件

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

1. No checkpoint without frame identity

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

2. No recovery without integrity check

required refs が壊れている recovery point を盲目的に使ってはなりません。

3. No blind replay of old local context

recover 後の local context は、必要なら再コンパイルされるべきです。

4. No authority creation through recovery

recover によって approval / merge / memory write authority が新しく生まれてはなりません。

5. No gate loss across checkpoint and recovery

pending approval / eval / policy block を失ってはなりません。

6. No canonical overwrite by stale recovery state

古い recovery point が、新しい canonical truth を上書きしてはなりません。

7. Every recovery must yield legal next transitions or explicit failure

recover の結果として、resume / replan / rollback / escalate / close のいずれかが明示されなければなりません。

8. Recovery points are provisional unless separately promoted

recovery point 自体は通常 canonical memory ではありません。

いつ Recovery より Replan を選ぶべきか

recover できるからといって、必ず resume すべきではありません。
次の条件では replan の方が自然です。

1. Scope drift が大きい

元の goal slice がもはや妥当でない場合です。

2. Governance drift が大きい

approval rule や policy が大きく変わった場合です。

3. Responsibility topology が変わった

approver / owner / memory writer 構造が変わった場合です。

4. Old delta が stale

pending delta の admissibility が失われている場合です。

5. Unresolved issue が本質的だった

一時停止時に残っていた ambiguity が frame の再設計を要する場合です。

短く言えば、
continuity をそのまま再開できるなら recover + resume、
continuity の意味自体が変わったなら replan
です。

最低限の自己点検

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

どこで checkpoint を切るか意味的に定義されているか
recovery point に runtime / bundle / gate / delta continuity が保存されているか
transcript 保存と recovery semantics を区別しているか
recover と resume を分けて考えているか
recover 前に integrity check をしているか
durable state / governance drift を検出しているか
stale context を再コンパイルする前提があるか
pending approval / eval を失っていないか
recovery から legal next transition が決まるか
recovery point が provisional durable item として管理されているか

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

暫定的なまとめ

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

長い process は、止まっても続けられなければならない。
そのためには、単に履歴を残すのではなく、frame・責任・gate・delta・authority・context 再利用条件を含む continuity を保存し、現在の durable reality と照合したうえで再開しなければならない。

PCE 2.0 において checkpoint は保存であり、recovery は再構成であり、resume は再進行です。
この三つを分けることで、継続性は convenience ではなく、governed continuation になります。

だから Checkpoint and Recovery は、単なる runtime 機能ではありません。
それは、PCE 2.0 において 中断を含む process を継続可能なものとして成立させる継続意味論 です。