Execution and reconciliation

Execution separates preparation, provider dispatch, observation, result data, and claim authority. Result data answers what authoritative effect state was observed. Claim authority answers whether one exact structured proposition may be asserted. A DISPROVED result does not automatically authorize arbitrary negative wording, and AnswerUp does not invent every truthful statement it could formulate.

Initial execution

Initial execution performs one provider dispatch and one authoritative verification. Default behavior remains success-oriented and proposition-specific: DISPROVED does not automatically grant negative natural-language authority, and initial UNKNOWN does not grant ordinary safe-claim authority. An action can opt in at registration with a bounded data-only InitialExecutionClaimPlan. Its COMMITTED, DISPROVED, and UNKNOWN entries are mutually exclusive alternatives. Runtime selects and evaluates only the branch matching authoritative truth; unused branches never become authority.

Legacy claims.build remains a one-proposition compatibility path. Actions captures its callback at registration, and Runtime snapshots, validates, and freezes the returned proposition before provider dispatch. Later mutation of the caller-owned definition, callback property, or returned proposition cannot change what Core evaluates.

Acknowledgment is not effect truth

The provider adapter may return an acknowledgment, rejection, precondition failure, or uncertain result. An acknowledgment means the provider accepted or received the request; it does not establish that the authoritative system contains the intended effect. The independent verifier reads the authoritative system and returns bounded evidence such as PRESENT, ABSENT_FINAL, or INDETERMINATE.

PRESENT can support COMMITTED, ABSENT_FINAL can support DISPROVED, and unresolved evidence remains UNKNOWN. Preserve operation, effect, execution, and attempt identities so the original effect can be reconciled.

Live reconciliation

While the process is live, retain the exact Actions-owned UNKNOWN result and pass it to the same ProtectedActionRuntime. The exact returned UNKNOWN object carries a one-shot live association that cannot survive process loss. The continuation is verifier-only and performs zero provider redispatch. Clones, spreads, reconstructed or serialized values, cross-instance results, terminal results, and already-consumed results carry no live authority. A related UNKNOWN may carry the next one-shot association.

The optional LiveReconciliationClaimPlan is supplied when reconciliation is requested. Authoritative reconciliation truth is established first, Runtime selects the matching one of its three propositions, and Core evaluates that exact proposition. The one-argument overload preserves legacy proposition-specific, fail-closed behavior.

Durable recovery

After process loss, Runtime durable recovery is a separate host-operated verifier-only flow from a host-retained closed DurableRecoveryRecordV2, accepted recovery authority, and stable verifier registration. The preferred RecoveryClaimPlan contains common subject/attributes and mutually exclusive COMMITTED, DISPROVED, and UNKNOWN propositions. The sequence is accepted authority, verifier-only recovery, authoritative recovered truth, mechanical matching-proposition selection, Core evaluation, then an accepted related result and bounded claim authority. The legacy single-proposal overload remains outcome-specific compatibility behavior.

The accepted contract preserves preview.3 version-2 record compatibility, stable verifier binding, source-record digest, leases/fencing/CAS ownership, related recovered results, and zero redispatch. Recovery is authoritative read-back only and cannot authorize mutation or redispatch. It does not reconstruct live authority. Recovery does not automatically happen after restart: the host must retain or export the appropriate durable material and provide accepted recovery authority. Rehydration is not permission to execute, retry, or redispatch. The host owns persistence, authority controls, scheduling, monitoring, and bounded delivery; this is not hosted recovery, exactly-once execution, or universal production durability.

Historical observation authority

Permitted plan-based UNKNOWN branches appear in observationClaims, not ordinary safeClaims. RELATED_INITIAL_VERIFICATION_OBSERVATION_ONLY, RELATED_LIVE_RECONCILIATION_OBSERVATION_ONLY, and RELATED_RECOVERY_OBSERVATION_ONLY each describe only one exact historical observation. They do not establish current unresolved state, success, failure, retry, redispatch, compensation, or future-state truth.

See Results and errors, the Runtime API Reference, and reconciliation concepts.