# 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.

## 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,ignore
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](/one/lifecycle/recovery) for the operational
response to unknown and partial outcomes, or follow
[Handle failures without flattening them](/one/examples/failure-handling).