Failure model

One preserves failure meaning across languages, protocols, providers, and interfaces. A generic error string is never allowed to collapse outcomes that require different user actions or recovery.

The intended result vocabulary

The product intends exactly these class names as the outer outcomes. A language projection may change letter case or wrap them in a target-appropriate type, but it maps one-to-one to these names and must not invent a synonym. In particular, the success class is always Success; Ready, Completed, Accepted, and Applied are not alternate success names. A per-operation domain fault stays a separate value carried by the domain-fault outcome and is never itself an outer class.

The operation, fault, effect, and idempotency contracts behind these outcomes are defined in operations and outcomes.

Semantic outcomes

Outcome	Meaning	Typical response
Success	The operation's declared success value was produced	Continue
Domain fault	The operation ran and returned a declared business outcome	Handle according to the domain contract
Rejected input	The request did not satisfy its schema or preconditions	Correct the request
Conflict	Current semantic or resource state prevents the transition	Refresh, resolve, or choose another valid transition

Domain faults are part of the public operation. They are not platform defects and do not automatically trigger retries.

Authority and admission outcomes

Outcome	Meaning	Typical response
Denied	Policy rejected the exact request	Change scope or obtain appropriate approval
Indeterminate	Policy could not establish permission	Deny safely and repair policy evidence
Expired or revoked	Prior authority is no longer valid	Reauthorize under current policy
Untrusted	Required provenance, identity, admission, or assurance is absent	Supply or establish accepted evidence

Authentication does not imply authorization. Approval does not imply a current grant. A grant does not prove enforcement succeeded.

Execution and communication outcomes

Outcome	Meaning	Typical response
Cancelled	The caller or owner requested that work stop	Inspect whether dispatch or cleanup occurred
Deadline exceeded	The execution contract's time bound elapsed	Apply the operation's retry or reconciliation policy
Resource exhausted	A declared capacity, quota, credit, or budget was reached	Shed, wait, scale, or replan
Incompatible	Selected schemas, protocols, targets, or versions cannot interoperate	Rebuild, remap, or replan
Unavailable	The selected realization cannot currently serve	Retry or fail over only inside the admitted envelope
Outcome unknown	Dispatch may have happened, but exact outcome is not established	Reconcile before unsafe repetition

Cancellation and timeout describe the caller's knowledge, not necessarily the external world's state.

Composition and realization outcomes

Outcome	Meaning	Typical response
Unsupported	No declared contract or implementation path provides the requested semantics	Add or select a real implementation
Unsatisfied	The contract is supported, but no eligible realization meets this root's constraints	Change constraints, evidence, or provider availability
Ambiguous	More than one valid result exists where the contract requires one canonical answer	Add an explicit owner-valid preference
Missing evidence	A required record or proof cannot be resolved	Restore or reproduce the exact owning evidence
Stale evidence	Evidence exists but no longer meets freshness or epoch policy	Reobserve, revalidate, or reauthorize

One never substitutes a nearby digest, cached display value, installed package, or earlier-stage record to make these cases disappear.

Defects and external anomalies

A defect means an implementation, provider, tool, or One invariant was violated. A malformed provider response, impossible state transition, invalid receipt, corrupted artifact, and non-conforming codec are defects rather than domain faults.

Defects carry the responsible boundary, exact inputs, affected claim, safe disposition, and retained evidence. Sensitive values remain redacted. A later defect or revocation can trigger bounded impact analysis without rewriting the original history.

Aggregation does not erase partial failure

Workspace batches, composites, fan-out operations, pipelines, rollouts, and multi-provider routes retain per-member results. Aggregate policy may define quorum or success, but unsuccessful, skipped, unknown, and unavailable members remain inspectable.

Example

Illustrative code handles semantic and outer outcomes separately:

Rust

match result {
    Succeeded(value) => use_value(value),
    Rejected(fault) => correct_input(fault),
    Denied(denial) => request_access(denial),
    OutcomeUnknown(effect) => reconcile(effect),
    Failed(cause) => recover(cause),
}

See recovery and continuity for the operational response to unknown and partial outcomes, or follow Handle failures without flattening them.