Handling every result

What does each result mean?

Treat Core’s effect-outcome taxonomy as closed: NOT_DISPATCHED, COMMITTED, DISPROVED, and UNKNOWN are its four effect outcomes. Actions exposes additional pre-dispatch result kinds; use its versioned API rather than treating this list as the complete Actions union. Application code must handle every permitted value explicitly and reject missing or unfamiliar values instead of treating them as success.

NOT_DISPATCHED means the protected provider boundary was not crossed. COMMITTED means authoritative evidence supports the intended effect. DISPROVED means authoritative evidence supports final absence or contradiction of that effect. UNKNOWN means the available evidence cannot determine the effect. PRESENT maps to COMMITTED; ABSENT_FINAL maps to DISPROVED; INDETERMINATE maps to UNKNOWN.

Provider observations are not final results

ACKNOWLEDGED is an intermediate provider observation, never a success claim. REJECTED and PRECONDITION_FAILED map to NOT_DISPATCHED only when dispatch did not cross the protected boundary; after dispatch, insufficient evidence can leave the result UNKNOWN. UNCERTAIN means provider knowledge is incomplete.

Provider-specific states remain private observations until an independent authoritative verifier supports a normalized result. The provider must not verify itself. Omitted, malformed, or contradictory information must not become an optimistic guess. A verifier read that finds the intended effect maps PRESENT to COMMITTED; final authoritative absence maps ABSENT_FINAL to DISPROVED; an unavailable or contradictory read maps INDETERMINATE to UNKNOWN.

Recovery belongs to the application

Your application decides what happens next. Before dispatch, it may correct the request, refresh trusted context, ask for clarification, or obtain authorization. After dispatch, an unresolved result may permit either live verifier-only reconciliation using the exact process-local UNKNOWN authority or the distinct Runtime durable recovery path after process loss. Durable recovery requires a host-retained closed DurableRecoveryRecordV2, accepted recovery authority, stable verifier registration, and the documented lease, fencing, source-record digest, and CAS controls. Both paths perform zero provider redispatch, create a related result, and leave the original historical result immutable. Neither is automatic restart recovery. The Core package classifies the bounded lifecycle outcome, preserves the dispatch distinction, projects a safe claim, and prevents blind redispatch through protected continuation. It does not automatically retry or choose the recovery workflow.

Never add an automatic blind retry: an unresolved effect must be investigated or reconciled before any genuinely new attempt.

The application or integrator is responsible for presenting clarification, obtaining new input or authorization, refreshing context, deciding whether to create a genuinely new proposal, choosing user-facing wording from the permitted result, and invoking allowed verifier-only reconciliation. Core supplies the bounded lifecycle classification and safe claim projection. The original result remains immutable during reconciliation, which performs zero provider redispatch.

Example: canceling a software subscription

A customer-support application proposes canceling subscription sub-381. Its authenticated backend supplies the subscription record and the policy service checks the support agent’s permission. If the identifier is missing or ambiguous, or the agent lacks permission, the result is NOT_DISPATCHED; the billing provider was not crossed. If the billing system’s authoritative record confirms cancellation, the result is COMMITTED.

If a final authoritative read confirms that the subscription remains active and the intended cancellation is absent, the result is DISPROVED. If the provider accepted the request but the independent billing-system read-back is unavailable or contradictory, the result is UNKNOWN. Provider acknowledgment alone does not establish billing-system truth, and the application must not automatically repeat the cancellation.

A practical handling table

Result	What it establishes	Safe application response	Do not infer
`NOT_DISPATCHED`	The protected boundary was not crossed.	Correct input, refresh context, clarify, or obtain authorization.	That an external change occurred.
`COMMITTED`	Authoritative evidence supports the exact intended effect.	Use the approved, scope-limited success claim.	More than the verified operation.
`DISPROVED`	Final authoritative evidence supports absence or contradiction.	Render only the matching permitted negative claim: final authoritative evidence establishes absence or contradiction of the exact requested effect. Otherwise use neutral wording. A new proposal requires a separate policy decision.	That the original attempt is safe to repeat automatically.
`UNKNOWN`	Dispatch may have crossed, but effect truth is unresolved.	Investigate; use exact-authority live reconciliation while the process-local association exists, or separately use authorized Runtime durable recovery from a retained closed record after process loss.	Success, ordinary failure, or permission to redispatch.

If public projection fails after an effect may have occurred, preserve internal truth, expose only bounded uncertainty, and do not redispatch. Runtime preview.5 and Actions preview.8 map post-dispatch projection failure to UNKNOWN while preserving internal truth. This contract does not certify an integration; read the current limitations and conformance guidance.