Recoverability as a System Primitive for Long-Horizon AI Agents

• A saved state is not necessarily suitable for reuse: the newest checkpoint may contain an edit that failed a required check, while an earlier approved version remains eligible.That earlier approval must still apply, and retry must be permitted.Source: §1 · p. 1
• Checkpointing, validation, diagnosis, and planning must be connected so evidence supports the source and conditions govern the proposed action.A checkpoint manager or workflow engine can provide this control if it explicitly decides where and how execution may continue.Source: §1 · p. 2
• Recoverability selects an evidence-supported recovery point and allowed action, or withholds automatic continuation when governing rules require it.It coordinates checkpointing, validation, and repair through the execution control plane, but does not generate repair content.Source: §1 · p. 2
• The decision binds a particular source and recovery route to event-time evidence and policy, rather than treating approval as a permanent checkpoint label.The contract requires execution to follow the granted transition and to respect limits on repeated recovery.Source: §1 · p. 2
• Accurate restoration and successful completion can conceal an excluded starting point, so recovery choice must be evaluated separately from restored bytes and final task success.The paper also tests source choice, shared restoration, and authorization as distinct responsibilities.Source: §1 · p. 3

2.1 Fault Tolerance and Checkpointing

• A computationally consistent checkpoint can still contain invalid content or outdated assumptions, so restoration needs a separate decision about suitability for reuse.Agent checkpointing such as Crab improves restoration correctness by capturing operating-system effects, but does not establish that a selected version meets current continuation conditions.Source: §2.1 · p. 3
• A semantic checkpoint manager may satisfy the full contract if it checks action permission, supports refusal, enforces decisions, and records rationale and bounds.The contribution is to specify and evaluate this observable decision separately from restoration and task outcomes; restore-latest is one explicit baseline, not a characterization of all checkpoint systems.Source: §2.1 · pp. 3–4

2.2 Memory and Persistent Agent State

• Persistent memory can inform recovery-point choice, but retained claims must be checked against current artifacts and evidence; the runtimes do not evaluate memory-conflict resolution.Reflexion [10], Voyager [12], Generative Agents [8], and MemGPT [7] retain information beyond a single context.Source: §2.2 · p. 4

2.3 Diagnosis, Adaptation, and Workflow Control

• Diagnosis and adaptation do not alone determine which persistent state supports a correction or what effects are permissible from it.A failed tool-call diagnosis cannot establish whether a file changed before failure or whether retry could duplicate the effect; a workflow can answer through its own policy.Source: §2.3 · p. 4

2.4 Evaluating Agent Execution

• The evaluation records source selection, restoration, action counts, permission and execution, and final invariants because endpoint scores alone cannot reveal invalid recovery choices.The studies are controlled demonstrations, not workload-scale comparisons of agent intelligence or deployed reliability; direct empirical comparison with complete systems is outside scope.Source: §2.4 · pp. 4–5

3.1 Execution State and Degradation

• A state is degraded when execution cannot proceed under usual assumptions without rechecking them; detecting an event triggers recovery but does not determine the source or allowed next action.Triggers may include explicit errors, repeated action without validated progress, stale evidence, corruption, incomplete context, or uncertain tool side effects.Source: §3.1 · p. 5

3.2 Recovery Points and Conditions for Reuse

• A candidate continuation boundary combines a possible recovery-state reference with information needed to continue, while eligibility means evidence and policy support its use after the event.Support may depend on validation, provenance, freshness, uncertainty, or human approval; the formulation does not supply a universal trust method.Source: §3.2 · p. 5
• The newest available state and newest supported state can differ: in the document example, the newest is B while A is supported, subject to its approval still applying.Eligibility depends on the event, evidence, and rules; a stored label does not make it permanently valid.Source: §3.2 · p. 6

3.3 Recovery Actions and Permission to Continue

• Recovery routes specify retry, rollback, resume, replan, or withholding, and must be permitted for the event, source, evidence, and policy.An eligible source may have no valid continuing route, such as when an uncertain external write makes retry unacceptable; route examples are conditional, not rules inferred from failure labels alone.Source: §3.3 · p. 6
• A trusted continuation boundary is the source of a granted policy-valid transition, but trust here means support under stated evidence and policy, not objective world truth.A trustworthy continuation also requires execution to follow the granted transition.Source: §3.3 · p. 7

3.4 Recovery Correctness and Task Completion

• Restoration fidelity and final task-invariant success do not establish whether the recovery decision was policy-valid; a rejected version may be restored faithfully and later repaired successfully.Termination labeled completed is also distinct from passing the final invariant, and correct refusal can count as correct recoverability.Source: §3.4 · p. 7

3.5 Requirements for a Recoverable System

• The contract requires systems to distinguish saved from eligible state, decide whether and how to continue, execute the decision, retain checking evidence, and limit repeated recovery.Full-conformance evaluation must test both grant-required and withhold-required cases; always stopping is not sufficient.Source: §3.5 · p. 7
• A checkpoint manager or workflow engine can implement the requirements, with or without snapshot restoration, while partial implementations remain useful when their tested responsibilities are explicit.The design and evaluation identify which parts are actually exercised rather than implying a complete implementation.Source: §3.5 · p. 7

4.1 Design Goals and Responsibility Boundaries

• The design keeps candidate storage separate from version- and scope-bound eligibility evidence, while requiring recovery decisions to cover both a source and an action and to stop or escalate when conditions fail.Its goals also include bounded attempts, execution, and retained state.Source: §4.1 · p. 8

4.2 RPR Reference Control Architecture

• RPR organizes candidate registration, event-specific support assessment, source-and-route decisions, authorized enactment or withholding, and verification across three layers.Its five stages express information and decision dependencies, not separate processes; the architecture separates restoration fidelity, authority adherence, and endpoint completion.Source: §4.2 · pp. 8–9
• The architecture distinguishes the latest stored and latest eligible states from continuation authority, restoration fidelity, and endpoint completion, making evidence-to-decision-to-execution relations auditable.Figure 2 depicts the layers and subsequent verification.Source: §4.2 · p. 9, Figure 2 · p. 9

4.3 State, Candidates, and Evidence

• The object model separates operational artifacts, candidate checkpoints, and evidence; its EvidencePackage collects decision inputs, while a HandoffPackage is a design extension not established as implemented.Artifact-anchored continuity ties support to a specific version, while cross-artifact reconciliation and partial rollback remain extensions beyond the evaluated implementations.Source: §4.3 · p. 10

4.4 Candidate Lifecycle and Recovery Decisions

• Candidate lifecycle rules preserve rejected versions for inspection without promoting them, bind failures to relevant evidence, and select a valid source-route pair or a non-continuation disposition.Source and route may be chosen jointly or reconsidered as constraints and failure evidence change.Source: §4.4 · p. 11

4.5 Enactment, Verification, and Bounded Recovery

• Enactment must preserve the granted source-action association or carry out the prescribed halt or escalation; verification checks the decision and actual execution, not only restored bytes or the final artifact.An event ledger retains attempts and effects across task-state restoration, and recovery attempts, execution, artifacts, and repeated routes need explicit limits.Source: §4.5 · p. 11

5 Runtime Instantiations

• The three instances divide the reference design’s responsibilities: RPR-Grant selects and restores checkpoints, RPR-File applies source selection to model-generated documents and file writes, and RPR-Authority tests event-time permission and execution.Their evidence is complementary, not an integrated end-to-end validation; the file executor is not connected to the authority apparatus.Source: §5 · p. 12, Table 3 · p. 12

5.1 RPR-Grant: Selecting a Checkpoint Recorded as Eligible

• RPR-Grant promotes a new artifact only when validation and continuation policy admit it, and distinguishes the latest saved checkpoint from its separately recorded eligible pointer.Its fixed recovery modes use the failure family and recorded eligible checkpoint; the recovering paths evaluated have an eligible source, and source and route rules change together between restoring modes.Source: §5.1 · pp. 12–13
• RPR-Grant keeps its event ledger outside restorable task state and limits recovery to three attempts, while handoff and persistent-session reload are not exercised in the evaluated loop.Memory-conflict resolution is also unimplemented.Source: §5.1 · p. 13

5.2 RPR-File: Model-Generated Documents and File Restoration

• RPR-File snapshots approved and working-only document versions, restores the selected snapshot to disk, and verifies its SHA-256 digest before a separate model call proposes repair.Its scope is recorded eligibility and restoration, not general evidence assessment, cross-session handoff, or full-contract conformance.Source: §5.2 · pp. 13–14

5.3 RPR-Authority: Checking Permission at the Failure Event

• RPR-Authority evaluates whether event-time evidence and supplied rules permit a source and action, using a separate oracle as a reference for decisions.A fresh isolated authority process mediates effects through one-use capabilities and retains a hash-chained transcript, final state, and seal for independent checking.Source: §5.3 · p. 14
• The authority boundary covers effects mediated and recorded by its process, but assumes integrity of the trusted caller and spawn mechanism and does not claim to detect every sink-authorization change.The task-side client cannot establish conformance merely by reporting its own configuration; verification compares authority evidence with an independently retained configuration.Source: §5.3 · p. 14

6.1 Research Questions and Study Roles

• Studies A–C isolate runtime behavior and supplied source rules, while Study D changes failure-event conditions; their distinct requirements are not pooled as a benchmark score.The general contract permits any source-and-route pair in the allowed set, rather than requiring the newest eligible checkpoint.Source: §6.1 · p. 15

6.2 Study A: Choosing an Eligible Recovery Point

• 4/4 divergence challenges: checkpoint-only selected excluded B while recoverability selected A, yet both restored exactly and satisfied final invariants.Both modes selected the required source in all 12 aligned cases. Two checkpoint-only invariant misses in aligned scenarios reflected a generic-route payload mismatch, not a source error; Study A did not reassess evidence validity at failure.Source: §6.2 · pp. 16–17

6.3 Study B: Preserving Validated Progress

• 2, 4, and 8 attempts were blind-retry overheads; restoring modes retained 1, 3, and 7 validated actions and incurred one extra attempt.The pattern held across every task-by-failure-by-position cell; the action counts use unit spacing and do not measure latency or production efficiency.Source: §6.3 · pp. 17–18

6.4 Study C: Shared Candidates and Actual File Restoration

• 20/20 shared candidates: checkpoint-only selected B and recoverability selected A, yet every run completed with a repaired file satisfying its invariant.The within-project transfer check used validator-rejected candidates, exact-string checks, and one local file; it was not an independent replication or a test of learned source selection.Source: §6.4 · p. 18

6.5 Study D: Enforcing and Checking Continuation Decisions

• Each grant issued a one-use route capability and each withhold blocked continuation; caller-held policy evidence exposed altered configuration after an effect.The check rejected conformance but did not prevent or roll back the effect; the result assumes the trusted caller and spawn mechanism were not replaced.Source: §6.5 · pp. 19–20

6.6 What the Studies Establish Together

• Across studies, preservation, source choice, event-time permission, and independent checks are distinct; controlled demonstrations do not establish open-world robustness.A required withhold can leave a task unfinished while satisfying the recovery contract, while a completed task can still violate it.Source: §6.6 · pp. 20–21

7.1 Making Reuse a Decision

• A common decision interface separates source admission, reconstruction, route permission, and execution, and can live inside an existing checkpoint manager or workflow engine.Freshness checks can change whether a checkpoint remains usable, even when the checkpoint itself is more complete.Source: §7.1 · p. 22

7.2 Binding Checks to the Work They Support

• Validation must remain tied to the artifact version and conditions checked; current grant-path implementations use creation-time records and do not solve later evidence assessment.Human authorization and reconciliation of conflicting evidence remain future work.Source: §7.2 · p. 22

7.3 Checking Both Execution and Its Explanation

• Accurate restoration and eventual success do not establish that a source was permissible, and internally consistent records do not establish agreement with the expected policy.Independently held policy evidence can reject an explanation even after an effect occurs; this audit acceptance is distinct from preventing the effect.Source: §7.3 · pp. 22–23

7.4 Evaluating Recovery Mechanisms

• Evaluations should vary recovery-relevant conditions, isolate source from route rules, and report decision, enactment, fidelity, outcomes, and costs separately.The current router’s retained fields beyond failure family and eligible checkpoint have no demonstrated causal benefit to its choice.Source: §7.4 · p. 23

8.1 Given Rules and Narrow Task Coverage

• The studies test runtime adherence to supplied validators and policies, not whether those rules capture every real-world condition; their scripted and narrow task matrices are not representative deployments or evidence of cross-model robustness.Study C uses a local Markdown file, four invariant templates, and one write-then-timeout pattern; Study D uses 18 matched deterministic cases and synthetic probes.Source: §8.1 · p. 23

8.2 Comparisons and Costs Not Yet Measured

• Source and route contributions remain unisolated, and reported progress counts omit inference, validation, checkpoint, storage, audit, and enforcement costs.Study C’s latency and token records do not establish a controlled efficiency comparison because its modes repair different restored inputs.Source: §8.2 · pp. 23–24

8.3 Trust and Reproduction Boundaries

• The trust tests assume integrity of the trusted caller and spawn mechanism and do not cover OS compromise or arbitrary external effects; rejecting a nonconforming run does not prevent or reverse its physical effect.Offline verification also cannot recreate the original model-serving environment or re-observe an exited process’s OS status.Source: §8.3 · p. 24

8.4 Extending the Decision beyond the Current Cases

• The work does not establish autonomous repair quality or production reliability; future evaluations should combine multiple artifacts, changing evidence, and compound failures while measuring each control stage and the whole path.Cross-session handoff, memory conflict resolution, and partial rollback remain design extensions.Source: §8.4 · p. 24

9 Conclusion

• Recoverability makes reuse an explicit decision to select a supported source and permitted action, or withhold continuation, linking evidence, execution, and recovery bounds.The RPR architecture connects persistence, validation, planning, and control to implement this responsibility.Source: §9 · p. 24
• Accurate restoration and eventual success can conceal an excluded starting point, while independently held policy evidence can expose violations that internally consistent records cannot.Shared checkpoint restoration supplies the demonstrated benefit of retaining validated work.Source: §9 · p. 24
• Within supplied policies and the declared trust model, the framework makes continuation conditions enforceable and testable, but it does not infer trustworthy policies or undo effects detected after they occur.Its contribution is an independently specifiable and checkable basis for reusing progress.Source: §9 · p. 24

A.1 Frozen Implementations and Model Calls

• The deterministic and file runtimes are frozen as separate artifacts, with manifests binding retained evidence; their inclusion in a private release candidate does not establish public availability.Fresh deterministic runs may produce different UUID-derived object identifiers, so reproduction targets reported results rather than identical raw JSONL bytes.Source: §A.1 · p. 27
• Study C retained 20 candidate and 40 repair generations with no observed error in that matrix, but this is not a count of all provider calls or a controlled repeatable model evaluation.The endpoint reported model ID gpt-5.6-luna, but the upstream model and infrastructure were not independently verified; repeating calls depends on endpoint access and serving conditions.Source: §A.1 · p. 27
• Study D’s artifact supports recomputation of retained deterministic evidence under its declared profile, with results bound to candidate tree v14 and the specified run.Later packaging changes left the experimental implementation unchanged.Source: §A.1 · p. 27

A.2 Qualifications of the Authority Evidence

• The 84 enforcement probes use frozen manifest v1 and sealed-session recomputation, not an 84-row case-bound manifest with per-row hash bindings.Their structure and pass conditions are fixed by the manifest.Source: §A.2 · p. 27
• Semantic controls retain packet/trace documents and independent-process oracle output, while enforcement and recovery-bound probes retain hash-chained authority-session evidence.The latter do not claim the same packet shape.Source: §A.2 · p. 27
• The apparatus claim relies on Section 5.3’s threat model, while post hoc byte integrity is checked separately using manifest, tree, Git, and governance identities.The sealed workspace depends on a commit-pinned public base; only the vendored archive is self-contained offline.Source: §A.2 · p. 27
• Historical governance date errors are corrected by later clarification entries that preserve earlier hashes, and reported results use terminal evidence identities.These records distinguish historical entries from the identities governing the reported results.Source: §A.2 · p. 27
• Offline auditors cannot re-observe an exited process’s OS exit code, so they verify the seal’s mapping while the live runner/client observes the process-exit interlock.Overall, retained bytes support recomputation only for some observations; others require live execution or an additional trust assumption.Source: §A.2 · p. 28

A.3 Authority Verification Inventory and Comparison Identifiers

• The offline pass recomputed 392 manifest files, verified 210 authority documents, and reconciled 54 qualification/main records with zero layer-4 failures.These counts measure retained verification coverage, not additional independent task samples.Source: §A.3 · p. 28
• Both conditions advance the authority cursor from 0 to 1, but only the client retaining canonical caller configuration rejects conformance against independent policy evidence.The replacement client expands resume_retry handlers; round 12 copies its reference from client.config and accepts, while round 13 rejects as mismatch/authority_evidence, confirmed offline.Source: §A.3 · p. 28