Agent Operation Continuity Across Executor Replacement

Introduction A worker may submit a consequential request to a payment, messaging, infrastructure, or other effecting provider and then fail before it can persist the provider's response. Replacing that worker does not make the earlier request disappear. A successor that treats the work as fresh can duplicate the effect, while a successor that discards the work can lose an unresolved obligation. Several native mechanisms provide relevant pieces. AADP provides durable per-action authorization intent, decision and report idempotency, and an attempted/result-unknown report. Succession Receipts can record a completed predecessor-to-successor transition and carried commitments. AEB separates provider entry from effect outcome and requires authenticated reconciliation. Bounded Capability Receipts define durable reservation, provider-entry accounting, replay tombstones, and an admission epoch. This document specifies the missing composition contract: preserve one provider-operation occurrence and its evidence across replacement without restoring spent authority, resetting provider keys, or inventing a favorable outcome. The contract is deliberately bounded to one authoritative coordination domain and its covered provider paths.

Conventions and Definitions The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Operation occurrence: One intended consequential provider operation whose continuity is being preserved. Its reference may reuse an existing native operation identifier that satisfies this profile. This document creates no new identifier namespace.
Occurrence-creation binding: The durable, coordination-domain-owned idempotency input or pinned system-of-record reference by which the domain recognizes retries of an occurrence-creation request.
Coordination boundary: The trusted admission component for the declared coordination domain. It owns or validates occurrence creation, serializes authority state and provider entry, and fences stale worker executors. It is distinct from the replaceable worker executor.
Executor generation: A monotonically ordered generation or epoch used by the coordination domain to distinguish the current executor from a retired predecessor.
Provider binding: The immutable tuple of provider profile, provider account or environment, exact request representation or digest, native idempotency-key rule and value where available, and provider operation reference where issued.
Provider entry: The authority-accounting boundary after which the provider may have received the request. Under BCR-06, this is the atomic provider_entered transition that moves reserved authority to consumed before adapter invocation.
Attempt evidence: Append-only evidence about preparation, provider entry, acknowledgement, status, or terminal reconciliation for one bound attempt.
Missing knowledge: An explicit statement that configured status sources cannot establish a required fact. It is not provider failure, non-entry, success, or permission to retry.

Scope, Assumptions, and Non-Goals This profile covers one authoritative coordination domain that serializes admission for a protected provider path. The domain admits or refuses each covered occurrence and preserves it when the worker executor is replaced. The profile assumes that every covered executor uses the coordination boundary before provider entry; that the deployment pins a provider profile, account or environment, exact request representation, native key and reference rules, status sources, and retention expectations; and that each native authority mechanism retains its own accounting and replay semantics. The profile does not make an uncovered credential path safe. An implementation MUST disclose direct, administrator, break-glass, queued, alternate-protocol, and system-of-record paths that bypass the coordination domain. This document does not define a universal customer, job, responsibility, task, action-digest, agent, or worker identifier; a new succession or authorization receipt; a portable authority ledger; a universal provider key or outcome vocabulary; payment, refund, compensation, reputation, or acceptance semantics; a mandatory evidence format; or equivalence between native identifiers or verdicts.

Continuity Requirements

AOC-REQ-001: One Authoritative Coordination Domain For every covered operation occurrence, an implementation MUST identify one authoritative coordination domain that serializes reservation, provider-entry admission, executor-generation changes, and terminal reconciliation. A profile instance MUST NOT claim exclusive admission control beyond paths mediated by that domain.

AOC-REQ-002: Stable Occurrence Identity Without a New Namespace The coordination domain MUST select or assign a stable operation-occurrence identifier before provider entry and MUST retain it through executor replacement and terminal reconciliation. An implementation MAY use an existing native operation identifier, such as a BCR operation identifier, when it is stable, occurrence-specific, and replay-protected under the selected native profile. This document does not define a new universal identifier. The coordination domain MUST own the occurrence-creation rule or validate it against a pinned authoritative system of record. It MUST either resolve a stable system-of-record occurrence reference or atomically mint a new occurrence only after local policy determines that the request is a distinct intended occurrence. Creation retries MUST use a durable occurrence-creation binding and return the original occurrence. A caller-supplied business occurrence identifier MAY be used when the coordination boundary authenticates it and validates its uniqueness and semantics under that rule. A caller-selected relabel, grant, task, or retry ID MUST NOT by itself establish a new occurrence. The occurrence identifier MUST NOT be an authority grant identifier, reusable task identifier, or action digest. A caller retry identifier MAY map to the occurrence only after the coordination boundary resolves it under the durable occurrence-creation binding. Identical action digests MAY represent separate legitimate occurrences when the occurrence-creation rule and local policy distinguish them. A deployment requiring at most one occurrence for a material action MUST use a durable action fence or bind the unique occurrence into the material action under its pinned definition; it MUST NOT silently treat an action digest as an occurrence identifier. An implementation MAY map AADP request_id, AADP permit_id, a Succession Receipt identifier, BCR operation_id, a provider-native key, and a provider operation reference to the occurrence, but MUST retain their types and native meanings and MUST NOT claim semantic equivalence merely because values are stored together or carry equal text.

AOC-REQ-003: Immutable Provider Binding Before provider entry, the coordination domain MUST durably bind the occurrence to all of the following:

the exact provider profile and version;
the provider account, tenant, environment, or equivalent effecting namespace;
the exact provider request bytes, or a deterministic digest over the complete request representation defined by the profile;
the native idempotency-key derivation rule and resulting key, when the provider supports one; and
the provider operation reference, acknowledgement reference, or status locator when one becomes available.

Every later admission, status query, response, or reconciliation transition MUST match this binding. An implementation MUST NOT rebind the occurrence to another profile, account, request, native key, or provider reference to escape an unresolved or terminal state.

AOC-REQ-004: Append-Only Attempt Evidence The coordination domain MUST preserve an append-only history sufficient to distinguish preparation with no serialized provider entry; serialized provider entry without authoritative acknowledgement; provider acknowledgement or native reference; each provider-status observation with source, time, and profile interpretation; and the terminal reconciliation decision with its evidence binding. An implementation MAY use different local state labels. It MUST NOT overwrite a prior observation in a way that hides provider entry, uncertainty, a retired executor, a conflicting observation, or a prior terminal decision.

AOC-REQ-005: Preserve Uncertainty Through Replacement Replacing an executor MUST NOT change the occurrence identifier, discard its provider binding or attempt evidence, clear its unresolved state, replenish or recreate its authority, or authorize another provider attempt. The successor MUST receive, or be able to query, the current occurrence state and its unresolved evidence before it can act on that occurrence.

AOC-REQ-006: Fence Retired Executors The coordination domain MUST advance the executor generation and retire the predecessor before admitting new work for the successor. Reservation and provider-entry transactions MUST compare the current generation with the generation captured for the pending attempt. A retired executor MUST NOT create a new reservation, enter the provider, replace the native provider key, or claim a new attempt. The deployment MUST define finite limits for pending and in-flight occurrences so executor failure cannot create unbounded held state. Fencing inside the coordination domain MUST NOT be described as revoking credentials or stopping paths outside that domain.

AOC-REQ-007: Historical Responses Are Evidence, Not Authority An authenticated provider response received after executor replacement MAY be accepted when it matches the immutable provider binding and the exact predecessor attempt. Accepting that response MUST NOT reactivate the retired executor, create a new admission, extend authority, or authorize replay. A response that cannot be bound to the exact prior attempt MUST leave the occurrence unresolved.

AOC-REQ-008: Pre-Entry Release Requires Serialized Non-Entry Held pre-entry authority MAY be released only when the authoritative coordination domain serially establishes that provider entry did not occur while the operation remains in its pre-entry reservation state. The release transition MUST authenticate the reservation owner, match the occurrence and exact request binding, be atomic with the authority adjustment, and retain a terminal replay tombstone. This requirement governs the AOC/provider-occurrence exposure and any native authority reservation whose profile makes release depend on provider non-entry. It does not suppress a distinct AADP-native permit-reservation expiry transition; the accounting separation and unsupported-alias rule are stated in . Deadline expiry, executor death, absence of a provider response, an unrecognized provider reference, or an unauthenticated provider claim MUST NOT by itself establish non-entry. A later presentation of the same occurrence or native key MUST NOT create a new reservation.

AOC-REQ-009: Status-Source Truth and Missing Knowledge Each provider profile MUST identify all of the following:

authoritative status sources and their authentication pins;
the account and environment in which status is authoritative;
the native key or reference used for lookup;
the status retention horizon and freshness rules;
whether a result is complete for the bound account and interval;
the native meanings mapped to accepted, not_accepted, final_failure, and success; and
how unavailable, expired, incomplete, conflicting, or unknown results are represented as missing knowledge.

The implementation MUST preserve the native response and profile interpretation separately. It MUST NOT infer a terminal result from HTTP class, transport completion, absence from a non-complete listing, local exception text, elapsed time, or a provider label that the pinned profile does not define.

AOC-REQ-010: Refuse Rebinding and Duplicate Attempts Once an occurrence has a provider binding, a request to change the provider account, exact request, profile version, native key, or provider reference MUST be rejected as a conflicting operation. A request with the same occurrence-creation binding MUST resolve to the existing occurrence. Creating a new caller-selected operation identifier, grant, task, action digest, occurrence identifier, or executor generation MUST NOT bypass this refusal. An unresolved or terminal occurrence MUST NOT enter the provider again. A provider-native idempotency key is a defense at the provider boundary, not permission for the coordination domain to admit a second attempt.

AOC-REQ-011: Provider-Specific Terminal Interpretation The following terms are profile-level interpretations, not universal provider states:

accepted: The provider acknowledges receipt or ownership of the bound request. This does not by itself mean the requested effect succeeded.
not_accepted: The pinned profile has authoritative evidence that the provider did not accept the request under the stated scope. This does not retroactively prove that the local provider-entry boundary was not crossed.
final_failure: The provider reports a terminal failure under pinned native semantics. The profile MUST state whether the evidence also establishes that no protected effect occurred. Unless it does, the provider workflow may be terminal while the protected-effect outcome remains unresolved.
success: The pinned provider status source reports the profile-defined successful result for the exact binding. Its truth is bounded by that source and does not establish independent physical, legal, or commercial truth.

Unknown, pending, stale, incomplete, conflicting, or unmapped native states MUST leave the occurrence unresolved.

AOC-REQ-012: Provider Entry Consumes Authority When the native authority profile consumes or commits authority at provider entry, later not_accepted, final_failure, compensation, reversal, refund, or other remedy evidence MUST NOT restore, erase, or relabel the original consumed authority merely because the protected effect failed or was compensated. A provider-specific terminal no-effect result MAY resolve outcome uncertainty, but it does not imply an accounting refund under every authority policy. Any later adjustment, replacement attempt, compensation, or new allocation MUST be separately authorized under its governing native policy, linked to the original occurrence, and assigned its own replay-protected operation identity. The original occurrence identity, provider binding, consumed-authority record, and prior history entries MUST remain immutable. Authenticated reconciliation evidence and separately authorized adjustments MAY be appended without rewriting those facts.

AOC-REQ-013: No Migration or Format-Equivalence Claim This profile MUST NOT be used to claim that copying an operation record transfers exclusive ownership of a live ledger, that a Succession Receipt fences a provider path, that AADP and BCR state machines are interchangeable, or that any EP evidence format is mandatory. A cross-domain ledger migration requires a separately specified exclusive cutover protocol and is outside this profile.

Native Composition Boundaries This profile relies on, but does not amend, AADP-02 Sections 4 and 7 for durable intent, decision and report idempotency, the timeout report for attempted/result-unknown, and the prohibition on blind retry; Succession Receipts-02 for evidence of a completed predecessor-to-successor registry transition and carried commitments; AEB-05 Sections 5.8 through 5.11 for atomic consumption or reservation, dispatch intent, outcome separation, and authenticated reconciliation; and BCR-06 Sections 10 and 11.1 for provider-entry accounting, replay tombstones, crash recovery, and admission epochs. AADP's request_id remains a decision-idempotency key and its permit_id remains a single-use permit/report identity. A Succession Receipt remains evidence of an issuer-recorded completed transition. AEB's effect states remain native AEB states. BCR's capability-scoped operation_id and provider-entry accounting remain native BCR semantics. Storing these values with one occurrence does not make them wire-compatible or semantically equivalent. AADP-02 Section 4 natively requires the PDP to append an expiry event and release its permit reservation when execute_within passes without a report. AADP timeout remains the native report outcome when a report is made for attempted/result-unknown; no-report expiry is a distinct transition. AOC does not amend or suppress the AADP expiry transition. In a composed deployment, the AADP permit reservation and the AOC/provider-occurrence exposure MUST be represented as distinct native accounting facts unless another specification defines their joint state machine. AADP expiry MAY release only the AADP-native permit reservation; it MUST NOT erase the AOC occurrence tombstone, relabel serialized provider entry as non-entry, restore BCR allowance already consumed at provider entry, or authorize another attempt for that occurrence. If an implementation aliases the AADP reservation to the same counter AOC/BCR requires held or consumed after provider entry, it cannot claim simultaneous conformance to both contradictory transitions and MUST report the composition unsupported. The AOC occurrence remains unresolved until its provider-entry and effect evidence meet this profile. This is a source-level composition tension, not a tested onedoor defect, and AOC does not invent an AADP verdict. No EP, AADP, Succession Receipt, AEB, BCR, provider-native, or local evidence format is mandatory. Verification of an artifact proves only that artifact's native claims under its pinned trust rules.

Provider Profile Contract A provider mapping satisfies this profile only when it pins provider identity, account or tenant, environment, API or profile version, authenticated status sources, exact request representation, native key derivation, reference-creation semantics, native status meanings, terminality, no-effect meaning, retention and freshness horizons, completeness and pagination guarantees, and the evidence needed to bind a result to the occurrence. A result outside those exact mappings is missing knowledge. In particular, generic FAILED is not proof of non-entry or no protected effect. A profile may define an authenticated provider result equivalent to NO_EFFECT_CONFIRMED, but even that result does not rewind provider entry or automatically restore authority.

Conformance A conforming implementation MUST satisfy every requirement from AOC-REQ-001 through AOC-REQ-013 and pass every case in this section under its declared provider profile. It MUST report unsupported cases, missing status knowledge, bypass paths, and untested provider semantics rather than treating them as passes. A report MUST identify the implementation and provider profile versions, test-input digest, occurrence identifier, executor generation, provider-binding digest, terminal or unresolved state, provider-entry and authority-accounting state, provider-entry attempt count, evidence-source and missing-knowledge flags, case results, and requirement IDs evaluated. It MUST NOT expose credentials, reservation tokens, or private provider requests.

AOC-CASE-001: Normal single-generation success. One generation reserves, binds, enters, receives a bound reference, and obtains profile-defined success. Exactly one entry occurs, authority is consumed once, and evidence remains append-only.
AOC-CASE-002: Crash before serialized provider entry. The domain proves serialized non-entry, fences the predecessor, atomically releases the reservation, and retains a tombstone. No provider call or reuse occurs.
AOC-CASE-003: Crash after entry before acknowledgement. Replacement preserves an unresolved occurrence and consumed authority. Neither generation performs another provider entry.
AOC-CASE-004: Historical response closes the predecessor attempt. An authenticated, exact-bound response may reconcile the original attempt without reactivating the predecessor, admitting a new attempt, or changing authority again.
AOC-CASE-005: Retired executor races the successor. The stale generation is refused, the successor cannot re-enter a possibly entered occurrence, and bypass paths remain disclosed rather than falsely fenced.
AOC-CASE-006: Native key reset attack. Changing caller-selected occurrence, task, grant, AADP, BCR, generation, digest, or provider key labels resolves to the original creation binding or is refused. A separately intended identical action is allowed only through the authoritative occurrence-creation rule.
AOC-CASE-007: Provider binding substitution. A change to profile, account, environment, request, native key, provider reference, or status source is refused and cannot resolve, release, or reauthorize the occurrence.
AOC-CASE-008: Missing retention or incomplete lookup. Not-found beyond retention or absence from an incomplete result is missing knowledge, leaves the occurrence unresolved, and creates no refund or retry right.
AOC-CASE-009: Conflicting or unauthenticated evidence. Observations are preserved, the occurrence stays unresolved, and the implementation does not select a favorable result.
AOC-CASE-010: Terminal provider failure after entry. Generic final failure may leave the protected effect unresolved; authenticated no-effect evidence may close that bounded outcome. In both branches, entered authority stays consumed and any new attempt is separately authorized.
AOC-CASE-011: Compensation does not rewrite the occurrence. A remedy has its own authorization, identity, replay protection, and outcome, while the original occurrence identity, provider binding, consumed-authority record, and prior history entries remain immutable. Reconciliation and remedy evidence may be appended.
AOC-CASE-012: Pending and in-flight limit under replacement. Work beyond the declared finite limit is refused without provider entry, while existing unresolved records remain queryable and unchanged.

A same-team model or runner MUST be labeled as such. Passing abstract local cases establishes consistency with the profile, not independent interoperability, live-provider correctness, deployment, or adoption. Independent interoperability requires at least two independently maintained implementations to exercise locked cases with an agreed provider profile and compare observable decisions.

Security Considerations The principal security failures addressed by this profile are duplicate provider effects after worker replacement, authority restoration after provider entry, stale-executor admission, provider-key rebinding, loss or rewriting of uncertain evidence, and false terminal conclusions from incomplete status sources. The coordination boundary is a security-critical serialized state owner. Implementations need atomic durability for occurrence creation, reservation, provider entry, generation changes, pre-entry release, and terminal reconciliation. If an attacker can roll back or fork that state, the profile cannot prevent double admission. Provider responses and status sources need authentication and binding to the exact provider profile, account, environment, request, native key, and reference. A valid response for another account or request is not evidence for the occurrence. Clock, retention, completeness, and pagination assumptions are part of the provider profile and cannot be inferred from transport success. An admission epoch fences only transactions mediated by the declared coordination domain. It does not recall a request already admitted to the provider and does not revoke credentials or stop direct, queued, administrator, or alternate-protocol paths. Those paths need separate controls and disclosure. A malicious caller may relabel a retry as a fresh occurrence. The coordination boundary therefore owns or authoritatively validates the occurrence-creation rule. Conversely, equal action digests are not enough to collapse two legitimate repeated operations; deployments requiring material-action uniqueness need the explicit action fence in . Provider entry and protected-effect outcome are distinct. Failure, compensation, refund, or a provider-specific no-effect result cannot silently restore authority already consumed at entry. A separate remedy requires separate authorization and replay protection.

Implementation Status This section records implementation information in the spirit of and is intended for removal before publication as an RFC. A same-team local model and synthetic provider runner exercise the thirteen requirement identifiers and twelve conformance cases in this draft. The runner is bounded evidence of the model's behavior only. It does not execute the AADP onedoor implementation, a live provider API, a production authorization boundary, or an independently maintained implementation. Its results therefore do not establish full native protocol conformance, independent interoperability, deployment, adoption, or provider truth. The implementation report identifies unsupported and synthetic boundaries rather than treating them as externally verified.

Privacy Considerations Continuity records may link customer or tenant accounts, worker generations, exact request digests, provider references, timestamps, outcomes, and remedies over long periods. That correlation can expose commercial relationships, operational schedules, and sensitive activity. Implementations should minimize retained plaintext, separate access to provider requests from access to coordination metadata, and apply purpose-limited authorization and audit to status and history queries. Retention cannot be shortened below the interval needed to prevent replay or reconcile provider uncertainty merely for convenience. A deployment should document the retention basis, deletion constraints, cryptographic key lifecycle, and whether redaction leaves enough durable binding to reject replay without retaining unnecessary content. Conformance reports must not disclose bearer credentials, reservation tokens, or raw private provider requests. Digests may still enable guessing of low-entropy data and therefore require an appropriate canonicalization and confidentiality policy.

IANA Considerations This document has no IANA actions.