--- slug: failure-response-mode type: concept summary: "The six independent decisions a system makes after failure: permission, hazard, continuity, detection, aggregation, and recovery." created: 2026-08-30 updated: 2026-08-30 related: failure-mode: relation: depends-on note: "A response mode answers what happens after a particular failure mode occurs." fail-fast-and-loud: relation: specialized-by note: "Fail Fast and Loud works out one response on the detection axis." rollback: relation: specialized-by note: "Rollback is the backward answer on the recovery axis." approval-policy: relation: implemented-by note: "An approval policy decides whether uncertainty permits or denies an agent action." permission-classifier: relation: implemented-by note: "A permission classifier turns the permission-axis choice into an executable gate." agentic-payments: relation: implemented-by note: "Payment caps provide a concrete fail-closed control for agent spending." circuit-breaker: relation: implemented-by note: "A circuit breaker fails fast at the call boundary while letting the wider service degrade." cascade-failure: relation: mitigates note: "Different continuity choices at component boundaries can keep one failure from becoming a cascade." sweep: relation: used-by note: "A sweep can fail fast at each site while collecting independent failures across the whole pass." agent-teams: relation: used-by note: "Parallel agents need an explicit aggregation posture when one member fails." --- # Failure Response Mode > **Concept:** Vocabulary that names a phenomenon. *A failure response mode describes what a system does after something goes wrong, across six decisions that can be made independently.* One check fails, and a dozen questions arrive at once. Does the system deny the operation? Can it keep serving other requests? Should parallel work continue? Do you restore the old state or repair the new one? Calling the whole answer "fail-safe" hides decisions that need separate names. ## What It Is A [failure mode](failure-mode.md) names how a system breaks. A failure response mode names what the system does next. The response isn't one choice on a line from cautious to reckless. It combines choices across six axes: - **Permission: fail-open or fail-closed.** When the system can't decide whether an operation is allowed, fail-open permits it and fail-closed denies it. This is the axis behind an authorization service deciding what an outage means. - **Hazard: fail-safe or fail-secure.** Fail-safe means entering the state that minimizes the relevant harm. Fail-secure means preserving a security boundary. The same physical state won't satisfy both for every hazard. - **Continuity: fail-operational or fail-soft.** A fail-operational system preserves its required function despite the fault. A fail-soft system sheds capability and continues in a degraded form. Either choice differs from stopping outright. - **Detection: fail-fast, fail-silent, or fail-stop.** Fail-fast surfaces invalid state near its cause. Fail-silent lets the defect pass without a usable signal. Fail-stop is stronger: a component halts before its bad effects become visible, and other components can reliably detect the halt. - **Aggregation: fail-fast or fail-collect.** A fail-fast aggregate stops at the first relevant failure. A fail-collect aggregate continues independent operations, records every success and failure, and reports the complete result at convergence. - **Recovery: fail-forward or fail-back.** Fail-forward repairs the current state with another change. Fail-back restores a previously known-good state, usually through [Rollback](rollback.md). The repeated terms can mislead. *Fail-fast* can mean "reject this invalid value immediately" or "abort this 200-target batch after its first bad target." Those are separate choices. You may want every target to reject invalid state at once while still letting the other 199 targets run. The word *safe* carries an older collision. In safety engineering, safe means minimizing the hazard: a fire exit should unlock when power fails, while a bank vault should stay locked. Access-control hardware calls the first behavior *fail-safe* and the second *fail-secure*. Saltzer and Schroeder's security principle of *fail-safe defaults* means default-deny, which is fail-closed. The phrase doesn't identify a response until you name the hazard and the tradition using it. ### Fail-Collect *Fail-collect* gives the aggregation choice its own name. The behavior is familiar even when the term isn't. JavaScript's `Promise.allSettled` waits for every promise and returns every outcome, while `Promise.all` rejects on the first rejection. A test suite without `-x` reports all failures it reaches; `-x` stops after one. Libraries that accumulate validation errors make the same choice. Independence is the precondition. If step two consumes step one's output, continuing after step one fails doesn't collect useful evidence; it manufactures secondary failures. Fail-collect fits fan-out work whose branches can finish on their own. It doesn't fit a dependent pipeline. Partial success becomes normal under fail-collect, so the caller must inspect the aggregate. Collecting five failures and then reporting "done" turns fail-collect into fail-silent at the fan-in boundary. ## Why It Matters Failure policy often hides in defaults. A permission client catches an exception and returns `true`. A shell wrapper ends with `echo complete`, masking the command's exit code. A parallel runner cancels every healthy branch because one branch failed. A migration tool keeps patching a half-applied state because it has no tested way back. Each default chooses a response mode whether or not anyone named it. The six-axis vocabulary makes those defaults reviewable. "The checker is unavailable" isn't enough to decide behavior. You can instead say: deny the high-risk action, keep low-risk reads operational, fail loudly, collect the outcomes of independent checks, and roll back any state written before the refusal. That is one coherent response, not one setting. Agentic systems make the distinction sharper. A language model can produce a plausible answer after a tool fails, but it can't provide an independent, trusted signal that its own output should be rejected. It also can't establish the fail-stop property from inside the same generation. The surrounding harness has to interpret tool failures, preserve exit status, check artifacts, and refuse completion when evidence is missing. This makes the failure posture a property of the harness, not the model. A model's confident "done" can become a fail-silent defect, a fail-open permission decision, or harmless draft text depending on what the harness checks before accepting it. ## How to Recognize It You are looking at an unspecified failure response when a design says "handle errors" but can't answer what happens to permission, service, sibling operations, and state. The following questions expose the missing choices: - If the deciding service is unavailable, does the operation proceed or stop? - Which harm defines *safe* here, and does protecting security require a different state? - Which functions must keep working, and which may degrade? - Where does the failure become visible, and can another component distinguish failure from silence? - Are the remaining operations independent enough to continue, and who inspects the aggregate result? - Is the current state cheaper to repair or cheaper to replace with a known-good one? A deliberate design answers all six at its important boundaries. It may choose different answers at different layers. A circuit breaker can fail fast at one service call, let the product fail soft by serving cached data, fail closed on writes, and fail forward by probing until the dependency recovers. There is no contradiction because each term answers a different question. ## How It Plays Out An agent asks a permission classifier whether it may rotate a production credential. The classifier times out. The harness fails closed on permission and rejects the rotation, but it stays operational for read-only tasks. It emits a visible error and includes the blocked action in the run's aggregate report. One fault produces four deliberate choices: closed, operational, loud, and collected. A refactoring agent sweeps 200 call sites. Each site validates its edit immediately and reports a local failure without building on broken state. The orchestrator doesn't cancel the other sites because they don't depend on one another. At fan-in it presents 193 successes and seven failures, with every failed path named. The run is fail-fast per site and fail-collect across the batch. A database migration applies 17 of 20 steps before the process dies. The team can restore the pre-migration snapshot or write migration 21 to reconcile the half-applied state. Repairing forward may preserve hours of valid work, but it compounds damage if the diagnosis is wrong. The team chooses fail-forward only because a tested rollback remains cheap and available. Without that alternative, "forward" would describe captivity, not a decision. A document pipeline loses access to its source store midway through a batch. It marks the current document failed, skips any transforms that depend on that document, and continues unrelated documents. The final report stays red until a caller acknowledges every failed item. This is fail-collect with dependency boundaries, not blind continuation. ## Consequences **Benefits.** Separate axes give teams precise design language. Reviews can spot an unstated default before an outage chooses it. Components can combine postures without arguing over whether the whole system is "fail-safe." Fan-out work can report a full defect set in one run while each branch still rejects broken state early. Agent harnesses gain a concrete checklist for permission, evidence, aggregation, and recovery. **Liabilities.** Six decisions cost more thought than one slogan. The right answer depends on the hazard and the boundary, so teams can't copy one posture everywhere. Fail-closed systems can deny legitimate work during an outage. Fail-operational systems need redundancy. Fail-collect consumes resources after the first failure and requires careful fan-in logic. Fail-forward can turn one mistaken diagnosis into a chain of plausible patches. The axes also interact. A fail-soft service may preserve reads while failing closed on writes. A fail-collect batch may still need a global stop when failures cross a threshold or threaten shared state. Naming each choice doesn't remove the tradeoffs; it makes the tradeoffs visible before the failure makes them for you. ## Sources - Jerome Saltzer and Michael Schroeder's [*The Protection of Information in Computer Systems*](https://web.mit.edu/Saltzer/www/publications/protection/) (1975) introduced *fail-safe defaults* as the security rule that access rests on permission rather than on the absence of a prohibition. - Richard Schlichting and Fred Schneider's [*Fail-Stop Processors: An Approach to Designing Fault-Tolerant Computing Systems*](https://dl.acm.org/doi/10.1145/357369.357371) (1983) formalized the detectable halt property that distinguishes fail-stop behavior from an ordinary crash. - The Cats documentation for [`Validated`](https://typelevel.org/cats/datatypes/validated.html) explains why independent validations can accumulate errors while dependent computations normally short-circuit, the formal split behind fail-collect. - ECMAScript's [`Promise.allSettled`](https://tc39.es/proposal-promise-allSettled/) records the same aggregation choice in a widely used programming interface: wait for every independent outcome rather than reject on the first failure. --- - [Next: Layers and Generators](layers-generators.md) - [Previous: Failure Mode](failure-mode.md)