#!RFC-AI/2;id=17;draft=5;v=0.5.0;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=a6bc6e5530e682879339b1351518b3c7bb4e4346c3099b1b09daa17199e45d6a
For easier reading, view RFC-AI documents using RFC-AI Reader software.

RFC-AI 17 — DURABLE CONTINUITY, CHECKPOINTS AND RECOVERY
DOCUMENT CLASS: AI RFC — INTELLIGENT-WORK GUIDANCE
STATUS: DRAFT FOR CEO REVIEW — ENTIRE RFC-AI SYSTEM UNIMPLEMENTED

1. PURPOSE — WHAT AND WHY
Preserve unfinished work through interruptions. A lost session must not erase an authorized objective or cause a committed external action to be repeated.

2. INTELLIGENT-WORK DIRECTION
Maintain durable, source-grounded checkpoints using the responsible continuity Interface, investigate interrupted outcomes and resume the actual remaining obligation through an authorized worker.

3. PROPOSED IMPLEMENTATION APPROACH
Use the relevant authorized Interface, component and expressly designated Standard: RFC-AI 4, 31 and 35. Investigate the complete relevant context before deciding what the assignment means (see RFC-AI 11). A competent worker may discover, invent and improve the necessary methods during implementation; this guiding AI RFC is not required to repeat low-level APIs, algorithms or technology choices. Previous and legacy systems are research evidence only, never an implementation of this draft.

4. EVALUATION AND ACCOUNTABILITY
Use independent DAVG as described in RFC-AI 22 to challenge whether the eventual real-world result meets the objective, not whether the AI RFC looks like a traditional API specification. A missing prerequisite creates an active cross-worker recovery obligation through the worker coordination Interface, not a reason to abandon the task (RFC-AI 20 and 31). Report only verified effects and preserve lessons without reintroducing old operational mistakes.

5. DESIGN CUSTODY
Original subject-specific intended contract: Resumable task identity, exact last successful operations, committed vs uncommitted steps, provider-independent handoff, idempotency, cold-start tests; reconcile RFC-AI 4.
Implementation tasks, legacy-derived candidate methods, proposed data schemas, tests and open engineering questions are kept with this draft's append-only objectives.txt or the responsible Interface/Standard. This RFC has NOT been implemented; it does not approve a deployment or create a new CEO release gate. Rewritten 2026-11-02T20:28:09.285Z.


## HISTORICAL FAILURE EVIDENCE — RESEARCH ONLY; NOT AN RFC-AI IMPLEMENTATION
Historical context: An interrupted worker or retry sometimes left partial deliverables or risked repeating already committed actions.
Historical reports have mixed evidence quality; verify primary facts before adopting a claimed root cause. Preserve source provenance and do NOT operationalize retired legacy policies as current RFC authority.

## MUST-DESIGN CRITERIA — CEO-DIRECTED PROPOSED FUTURE SYSTEM
MUST-17-01: MUST make retries materially different in response to new evidence, diagnosis or recovery action; identical failing retries without changed circumstances are FORBIDDEN.
MUST-17-02: MUST reconcile uncertain committed side effects before executing again, through the responsible Interface.
MUST-17-03: MUST preserve an unfulfilled assignment through crash, timeout, worker replacement or unavailable provider.

IMPLEMENTATION STATUS: Entire RFC-AI system NOT IMPLEMENTED. Historical systems are independent past research material; no test or existing service may be counted as implementing this RFC-AI.


## ADDITIONAL MUST-DESIGN CRITERIA — 2026-11-02 (PROPOSED, NOT IMPLEMENTED)
Historical trigger: legacy materials repeatedly confused authored progress, scripts and document content with real observed execution; this is research evidence, not proof of any new RFC implementation.
MUST: Persist event correlation, assignment owner epoch and work-piece approvals as independent state; do not mistake worker-authored progress for events, and do not replay committed side effects.
MUST consider the concrete literal behavior of competent AI workers and enforce required hard safeguards by simple, separately running Interface logic where an actual boundary exists. MUST not delegate Interface internal details back to this guiding document. MUST preserve the requirement in relevant top-level objectives.txt and independently verify that future implementation satisfies it. New requirements here remain draft, not live controls.

## DESIGN REVIEW ADDENDUM 2026-11-03 — DURABLE ASSIGNMENT AND FENCING
REQ-AI-17-LEASE-001: Identity-bound Continuity and current Context MUST survive worker migration independently of current Assignment. Durable assignment ownership MUST have a revisioned epoch/lease; a stale owner MUST fail at protected storage/effect boundary even if an old request is otherwise valid.
REQ-AI-17-LEASE-002: Unknown provider commit is reconciled before retry; previously committed effects are never replayed merely because the worker lost its conversation. Persist next action and unresolved obligation while respecting backpressure and resource quotas.

DESIGN CORRECTION WORK-06 — Durable worker assignment and stale-owner fencing
RATIONALE: A chat turn, a heartbeat line and a durable assignment are different facts; the October workforce reports illustrate the cost of confusing them.
REQUIRED FUTURE BEHAVIOR: The future coordination Standard MUST specify durable assignment identity, claim lease, owner epoch, accepted START/RUNTIME evidence, active effect receipt, checkpoint revision and exactly defined terminal outcomes. A stale previous owner MUST fail when committing a protected effect after assignment reassignment, regardless of valid past context or a delayed provider request. A worker that is not executing MUST still retain its obligated next action without declaring it running. Failure/reconnect produces reconciliation rather than invented progress.
ADVERSARIAL DESIGN ACCEPTANCE: A claims epoch 5; lease expires and B claims epoch 6 and commits. A's late epoch-5 save must fail while B's commit survives. A stale heartbeat with no fresh runtime/process/changed artifact cannot show WORKING.
SCOPE: Proposed future contract, NOT running RFC-AI functionality; implementation HOW remains assigned to relevant Standard/Interface.