Failure

Version

v2 · 2026-09-28 · History

Prime #

1566

Domain group

Applied Sciences & Engineering

Origin domain

Engineering & Design (beyond software)

Subdomains

Reliability Engineering, Failure Analysis → Engineering & Design (beyond software)

Also from

Organizational & Management Science

Aliases

Nonattainment, Loss of required function

Core Idea

Failure is non-satisfaction of an applicable criterion. A carrier—a component, action, process, system, prediction, institution, or attempted outcome—is expected or required to meet an objective, function, threshold, or acceptance condition. Failure occurs when, under the conditions in which that criterion governs, the carrier does not meet it. The criterion can concern attaining a goal, maintaining function, avoiding a forbidden state, meeting a deadline, preserving integrity, or producing a warranted result. Because criteria differ, the same event can be failure under one frame and acceptable performance under another.

How would you explain it like I'm…

Didn't Do Its Job

Failure means something didn't do what it was supposed to do. A cup is supposed to hold juice; if it has a hole and the juice leaks out, the cup failed at holding juice. But the same leaky cup could still be fine as a flower pot—it depends on what job you gave it.

Missing the Goal

Failure is when something doesn't meet the goal or rule it was supposed to meet. That something could be a machine, a plan, a guess, or a team. Whether it counts as failure depends on which goal you're checking: a paper airplane that flies only a little way fails a distance contest but might pass a "make it fly at all" test. Failure doesn't automatically tell you why it happened, how bad it is, or whose fault it is. It can be small and partial, or huge and total.

Not Meeting the Criterion

Failure is not meeting an applicable criterion. Something (a part, an action, a system, a prediction, an organization) is expected to meet a goal, function, threshold, or deadline, and it fails when, under the conditions where that standard applies, it doesn't. Because the standard can change, the same event can be a failure under one frame and acceptable under another. Failure by itself says nothing about cause, severity, blame, or permanence; failures can be partial, intermittent, graceful, hidden, or catastrophic. It also helps to keep related words separate: a fault is a defect that might cause failure, an error is a wrong state or result that could still be caught before a requirement is missed, a failure mode is how failure shows up, and a failure mechanism is the process that produces it.

 

Failure is the non-satisfaction of an applicable criterion. A carrier, whether a component, action, process, system, prediction, institution, or attempted outcome, is required or expected to meet an objective, function, threshold, or acceptance condition, and failure occurs when, under the conditions in which that criterion governs, the carrier does not meet it. The criterion may concern reaching a goal, maintaining function, avoiding a forbidden state, meeting a deadline, preserving integrity, or producing a warranted result, so the same event can be failure in one frame and acceptable performance in another. Failure can be modeled as a state (a bearing that can no longer carry its rated load), an event (a launch that misses its mission condition), an episode, or a verdict (a proof attempt with an invalid step). The term alone does not specify cause, mechanism, severity, blame, permanence, or total collapse, which is why partial, intermittent, graceful, latent, and catastrophic failures can all share the same core. It is useful to separate failure as an outcome classification from its explanation: a fault is a defect or abnormal condition that may cause failure, an error is an incorrect state that might be detected and corrected before a requirement is lost, a failure mode is how failure manifests, a failure mechanism is the process producing it, damage is adverse change, and risk concerns possible future loss. Keeping these distinct lets the concept travel across engineering, medicine, computing, institutions, and ecology without lumping every bad event together.

Broad Use

Failure applies wherever its complete role structure is present; the source domain is historical provenance, not a boundary on the Prime. Engineering. a component or system loses required function under specified load and environment Computing. a service violates correctness, availability, latency, durability, or security requirements Projects. a delivery misses binding scope, time, cost, quality, or benefit criteria Medicine. an intervention fails relative to a declared clinical endpoint while other outcomes may still improve Biology. an organism or regulatory process does not maintain a function under.

Clarity

Use Failure only after naming the carrier and the relation that makes the case one. The minimal definition is: Failure is the criterion-relative state or event in which a system, action, component, process, or attempted outcome does not satisfy a required objective, function, or acceptance condition under the circumstances where that condition applies. The most common ambiguity is to substitute a neighbor, an enabling condition, or a consequence for the identity itself.

Manages Complexity

Failure manages complexity by compressing many implementations into a stable role structure without erasing the variables that control validity. Analysts can compare cases by filling the same slots, locate disagreement in a missing role, and separate the constitutive relation from causes, instruments, representations, and consequences. The compression is intentionally reversible: the short label expands into carrier, applicable criterion, operating circumstances, observed performance, non-satisfaction relation, detection boundary, with explicit boundaries for variation and collapse.

Abstract Reasoning

1. Carrier move. Identify the system, component, action, process, prediction, institution, or outcome being assessed and record what observation supports the assignment.
2. Applicable Criterion move. Identify the required objective, function, threshold, prohibition, acceptance rule, or service condition and record what observation supports the assignment.
3. Operating Circumstances move. Identify the load, environment, time, user, mission phase, or jurisdiction under which the criterion applies and record what observation supports the assignment.
4. Observed Performance move.

Knowledge Transfer

Cross-domain transfer. Carrier, applicable criterion, operating condition, observed performance, and non-satisfaction travel across technical, biological, institutional, and action substrates; the choice of criterion remains explicitly framed. The invariant is not the source-domain vocabulary but the typed relation expressed by the one-line definition. Transfer is literal when a receiving domain can fill the same roles and expose the same failure boundary; it is analogical when only a visual, verbal, or narrative resemblance survives. Local warrants for Failure. Different domains establish those roles differently.

Example

A storage service promises that an acknowledged write will remain retrievable after any single-disk loss. One disk develops a fault, but redundancy preserves the data; there is a fault without service failure. Later, a correlated controller defect causes acknowledged data to disappear after a disk loss. The observed performance violates the durability criterion under a covered operating condition, so failure has occurred. The controller defect is a cause, data disappearance is the failure mode, customer loss is a consequence, and the probability of recurrence contributes to risk.

Relationships to Other Abstractions

Current abstraction Failure Prime

Foundational — no parent edges in the catalog.

Children (1) — more specific cases that build on this

• Breach of Contract Domain-specific is a kind of Failure

  A breach is observed non-satisfaction of an applicable contractual duty or present no-renunciation criterion under governing law.

Distinction from Neighbors

• Fault. A fault is a defect or abnormal condition capable of producing failure; redundant systems can contain faults without losing required function.

• Error. An error is an incorrect internal state, judgment, or result; correction can prevent it from crossing the failure boundary.

• Damage. Damage is adverse change to integrity or performance and may be tolerated within requirements.