Error catalog

The error catalog names the missing fact or bounded lifecycle stage so the application can choose a safe next step. It complements, rather than replaces, the result taxonomy.

Before dispatch

Malformed input, missing identity, unsupported operation, ambiguous candidate, stale trusted context, or authorization denial should stop before the provider boundary. Correct the input, refresh context, ask a precise clarification question, or explain the bounded denial. Do not expose credentials, stack traces, private policy details, or provider URLs.

For an inventory transfer with two possible destination bins, clarification is required. If authorization denies the transfer, no provider call should occur. The error category is not a model instruction to retry.

After dispatch

A timeout, connection close, provider uncertainty, verifier outage, contradictory read, or projection problem may leave effect truth unresolved. Preserve operation, effect, execution, and attempt identities and classify the result according to the closed taxonomy. A provider acknowledgement is not independent effect evidence.

For UNKNOWN, preserve the exact returned Actions result object and reconcile that same object on the same runtime for one verifier-only authoritative read-back. After process loss, do not reconstruct it: the distinct Runtime durable recovery path requires a host-retained closed DurableRecoveryRecordV2, accepted recovery authority, and stable verifier registration. Both paths perform zero provider redispatch and leave the original historical result immutable. Never add an automatic blind retry. The host owns provider and verifier configuration, durable records, operational logs, and support escalation; the Core package owns bounded classification and safe result projection.