Allowed outcomes
Every failure should land on a named public outcome. Anything else is an incomplete product state.
Failure matrix
checking
Allowed outcomes
checking
Outcome counts
checking
What the label gives you
A failed path should still tell the user what happened, whether it can be retried, and which receipt or state is authoritative.
CheckVerify the receipt first.
Confirm whether the object, payment, or proof lane already has a canonical state.
Receipt path RetryUse the right retrieval path.Cold restore, hot query, and public rented access fail differently and should be retried differently.
Access path TraceFollow the public evidence.Replay, duplicate payment, and stale update cases should point back to a named receipt.
Evidence path ObserveCheck whether the lane is stale.Status labels help separate a user error from a delayed gateway or stale public snapshot.
Status pathNamed failure casesConcrete failure cases separated by signer, chain, provider, retention, payment, and route state.
Failure cases
checking
Receipts and retry rulesWhat happened, what can be retried, and what cannot be inferred from failure.
Failure outcomes
checking
Product boundary
A visible failure is healthier than a hidden success claim. Infra says stale, refused, queued, quarantined, downgraded, repairing, or terminal when that is the real state.
Replay
Replay and duplicate evidence links to canonical state instead of creating duplicate payment, work, or storage.
Storage
Hot provider failure, cold restore delay, provider proof mismatch, repair exhaustion, and capacity exhaustion stay separate.
Website
Website stale head or public stats conflict becomes stale or refused public state, not chain truth.
Interop
QUAD/Core, Bridge, and Liquid outages queue, retry, or stale-label their paths without inventing sibling-chain facts.