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 bounded snapshot and reconcile the exact live handle with the authoritative system. Never add an automatic blind retry. The host owns provider and verifier configuration, durable records, operational logs, and support escalation; Core owns bounded classification and safe result projection.