Developer Manual
Results and errors
Handle closed outcomes and recovery boundaries safely.
Treat Core’s effect outcomes as a closed set and branch explicitly. Actions has separate pre-dispatch result kinds; the four effect outcomes below are not an exhaustive Actions result union. Use the versioned Actions API for its exact returned kinds.
Lifecycle outcomes
| Outcome | Meaning | Safe application action | Prohibited action |
|---|---|---|---|
NOT_DISPATCHED | Protected provider boundary was not crossed | Handle the bounded preparation, grounding or authorization issue | Claim an external effect occurred |
COMMITTED | PRESENT evidence establishes the exact requested effect | Render only a matching returned permitted positive claim with the trusted request association | Claim more than was verified |
DISPROVED | ABSENT_FINAL evidence establishes final authoritative absence or contradiction of the exact effect | Render only the matching returned permitted negative claim; otherwise neutral wording | Treat “not confirmed” as final absence or retry permission |
UNKNOWN | Available evidence cannot establish effect or final absence | Preserve evidence; use a permitted verifier-only continuation | Blind redispatch or ordinary success/failure wording |
Diagnostic categories
These diagnostics explain a boundary or integration issue; they are not additional lifecycle outcomes. This table retains the manual’s troubleshooting labels, not an enumeration of returned API codes. Handle the actual returned outcome, versioned API kind and claim permission separately.
| Diagnostic category | Meaning | Application action |
|---|---|---|
CLARIFICATION_REQUIRED | Proposal or grounding is insufficient | Ask for bounded clarification before dispatch |
AUTHORIZATION_DENIED | Policy did not permit the exact operation | Stop; do not change trusted context to bypass policy |
PROVIDER_REJECTED | Provider returned a bounded rejection | Retain the attempt; rejection alone is not final absence |
PRECONDITION_FAILED | A provider precondition failed | Refresh or clarify under host policy; no blind retry |
INTEGRATION_FAILURE | The host could not complete its integration boundary | Retain bounded diagnostics; do not expose secrets or claim success |
UNKNOWN is unresolved world state, not ordinary success or permission to retry. Reconciliation verifies the original effect and never creates a second provider dispatch.
The host may supply one exact legacy proposition or a complete outcome-aware plan. InitialExecutionClaimPlan, LiveReconciliationClaimPlan, and RecoveryClaimPlan each hold mutually exclusive COMMITTED, DISPROVED, and UNKNOWN alternatives. Authoritative truth is established first; only the matching proposition is selected for Core evaluation. A result category is data, not blanket wording authority: DISPROVED never authorizes arbitrary negative language. Render no outcome claim unless the returned permission supports the exact proposition.
A ClaimPermission is authentic only when it is returned by the accepted lifecycle; matching visible fields, copying, or reconstructing an object does not create authority. Plan-based UNKNOWN authority is intrinsically historical and appears only in observationClaims: RELATED_INITIAL_VERIFICATION_OBSERVATION_ONLY, RELATED_LIVE_RECONCILIATION_OBSERVATION_ONLY, or RELATED_RECOVERY_OBSERVATION_ONLY. None establishes current unresolved state or permission to retry, redispatch, compensate, or assert future truth.