Diagnostic and Replacement Series · Paper 11

The Complete Diagnostic Taxonomy

Recurring failure is not random. It belongs to a class. The class names the correction. The sub-type determines the correction sequence.

This is the classification standard for structural failure in organisations, platforms, and institutions. If your system keeps producing the same failure despite correction effort — this is the reference that names what kind of failure it is, what qualifies as that failure, and what the correction path looks like.

Nine failure classes. Fifty-four sub-types. Formal inclusion and exclusion criteria, false positive tests, refusal conditions, and corrective directions for each. Built from eleven papers of structural diagnostic research.

9 Failure classes
54 Sub-types
11 Paper in series
How to use this page

Start with the decision tree below — nine questions that route you to a failure class. Then open the relevant class section and check your failure against the inclusion, exclusion, and refusal criteria. A failure only belongs to a class when it survives all four tests.

Paper 11 · v6.3 · May 2026 · Current diagnostic standard
quick reference — all nine classes

Every recurring structural failure belongs to one of these nine classes. Click any class to jump directly to its criteria, sub-types, and corrective direction.

diagnostic decision tree

Start at Q1. Follow the path. Most real failures trigger multiple branches — the branch with the strongest structural signal is the primary failure class.

Q1Does the organisation operate through a system it does not control — another platform's rules, a regulator, a marketplace, or infrastructure it cannot change?Yes → Class 1
Q2Did the failure emerge or worsen significantly as the system scaled in size, volume, or team complexity?Yes → Class 2
Q3Was the organisation built around an assumption about what users want, what technology can do, or what the market looks like — and has that assumption been materially disproved?Yes → Class 3
Q4Does the failure live at the interface between two systems that were designed separately and are now expected to work together?Yes → Class 4
Q5Does the system work technically, but nobody has clear authority to make, enforce, remember, or correct a specific class of decision?Yes → Class 5
Q6Are rational people following their incentives and producing outcomes the organisation does not want — without anyone behaving badly?Yes → Class 6
Q7Does the failure occur because the system assumes humans will behave in ways they cannot sustain under real conditions of load, ambiguity, or complexity?Yes → Class 7
Q8Is the system currently in transition — migrating, merging, upgrading, or operating under an external deadline — and the failure lives in the movement rather than the steady state?Yes → Class 8
Q9Is a person or user absorbing institutional burden that a governing system should be carrying — around access, records, consent, proof, reputation, care, or meaning?Yes → Class 9
on compound failures and misclassification

Most real failures are compounds. A compound failure contains a primary governing break, secondary consequences, and tertiary adaptations. Do not diagnose every symptom as a separate primary failure. The diagnostic question is always: which break, if corrected, would change the behaviour of the others? That is the primary class. The others are secondary.

The primary class governs the correction sequence. Fix the governing break first, then address secondary failures in dependency order. When two classes are triggered simultaneously, ask which one is upstream. The upstream class is primary.

Misclassification rules — do not classify by:

Do not
The loudest symptom. Classify by the break that makes the failure recur.
Do not
The department where the pain appears. The source and the symptom are rarely in the same place.
Do not
The first visible incident. The first incident is rarely the governing break.
Do not
Who is blamed. Blame follows visibility, not structural causation.
Do not
What would be easiest to fix. The easiest correction is rarely the structural one.
Refuse if
There is no recurrence. Structural diagnosis should be refused if the failure does not recur.
the nine classes — expand to view sub-types and criteria

A company is forced to operate through a system it does not control — a host platform, regulator, marketplace, payment authority, or infrastructure provider — while still carrying the user-facing consequence of any failure or mismatch that system produces.

Core diagnostic question: What external system governs the condition of success while this organisation carries the consequence of failure?

Boundary with Class 3: Remove the external constraint mentally. If the company's model would work without it, the failure is Class 1. If the model is structurally broken regardless, the failure is Class 3.

Include when all three hold

An external system governs a condition of operating success; the company cannot change the rules of that external system; and the company carries the user-facing consequence when that system fails or misaligns.

Exclude when

The company voluntarily chose the dependency and can exit it without structural consequence; the external system's rules are compatible with the company's promise; or the failure is in the company's own response to the constraint rather than in the constraint itself.

Sub-types
1.1 Host Platform Constraint

The product must pass through another company's rules, payment grammar, or distribution logic to reach its users, and those rules are incompatible with the product's core promise.

ExamplePatreon operating inside Apple's App Store subscription grammar. Creator patronage is a relationship primitive; Apple's system is a subscription primitive. The two are structurally incompatible. Patreon carries the consequence.
RefusalRefuse if the product's primitive is genuinely compatible with the host's grammar — the constraint is then operational, not structural.
CorrectionIdentify the primitive mismatch. Redesign the interface layer to govern the relationship independently of the host's grammar, or build an admissible off-platform path.
Paper anchorPaper 08 — Host-Constrained Primitive Mismatch
1.2 Payment Authority Constraint

The company owns the customer relationship but not the payment authority. A third party controls refunds, payouts, entitlement logic, or subscription state.

ExampleA creator platform where Apple owns subscription state and payout timing. The creator blames the platform. The platform cannot fix it without Apple's system acting.
RefusalRefuse if the payment authority boundary is acknowledged, navigable, and not generating recurring user-consequence.
CorrectionSeparate relationship authority from payment authority architecturally. Design explicit continuity for cases where payment state and relationship state diverge.
1.3Marketplace Dependency Constraint

Discovery, ranking, pricing, or access is governed externally with no structural alternative the company controls.

ExampleAn independent seller whose entire revenue depends on Amazon search ranking. When the algorithm changes, revenue changes — the seller had no say.
CorrectionBuild a discovery primitive the company owns: direct relationship, owned audience, or alternative distribution. The marketplace becomes optional, not load-bearing.
1.4Regulatory Constraint

External regulation reshapes the operating model faster than the architecture can follow, creating compliance regimes that grow without resolving the underlying structural mismatch.

ExampleA financial services platform simultaneously required to comply with GDPR (data minimisation) and AML regulations (maximum data retention). Both legally mandatory. They conflict architecturally.
CorrectionIdentify the specific incompatibility between regulatory requirements and operating architecture. Redesign around the constraint rather than building compliance workarounds inside it.
1.5Infrastructure Dependency Constraint

The product's reliability has a ceiling set by a provider the company does not control. When the upstream provider degrades, the product degrades with it.

ExampleA SaaS platform whose availability is directly capped by AWS us-east-1 uptime. When AWS degrades, the platform degrades. The platform carries the customer complaint.
CorrectionMap the propagation chain from provider to user consequence. Design redundancy at each single-point dependency. Where redundancy is structurally impossible, disclose the ceiling to users.
1.6User-Expectation Constraint

Users now structurally expect something the architecture was never built to provide — continuity, ownership, personalisation — and every product improvement falls short because the underlying architecture cannot satisfy the expectation.

ExampleNHS primary care: patients expect continuity of relationship. The architecture provides continuity of record. The gap between relationship and record is structural and cannot be closed with record improvements alone.
Paper anchorPaper 03 · NHS proof set
1.7Inherited Architecture Constraint

The organisation was designed for a world that no longer exists. Reform programmes stall at the same architectural boundary each cycle because the founding structure cannot be redesigned from inside it.

ExampleA national public institution designed around in-person, paper-based governance trying to operate digital services. Each reform programme hits the same data-sharing, consent, and authority boundary.
CorrectionApply the Institutional Replacement Pipeline (Paper 5): diagnose the governing break, extract the kernel of what the architecture must carry, redesign around that kernel rather than reforming the inherited structure.
Paper anchorPapers 04 · 05 — Institution Migration · Institutional Replacement Pipeline

The failure is not in the people or the execution — it is in the mismatch between the design's load assumptions and the current load.

Core diagnostic question: What scale condition did the original design never have to survive?

Boundary with Class 5: Ask whether the authority problem would exist at the original scale. If yes, the failure is Class 5 — it was always a governance problem, scale merely made it visible. If no, the failure is Class 2.

Include when all three hold

The system functioned adequately at a prior scale; the failure emerged or worsened significantly as the system scaled; and the design was not updated to match the new operating conditions.

Exclude when

The authority to govern the scaled system is missing (Class 5); humans absorb scale load because the system was designed around impossible human behaviour (Class 7); or the failure exists at original scale as well as current scale.

Sub-types
2.1Volume Scaling Failure

The same process runs on more inputs than it was designed for. Quality, accuracy, or reliability degrades proportionally to volume.

ExampleA content moderation system designed for 10,000 posts/day now receiving 10 million. Same rules, same team structure — the design was never built for this load.
CorrectionRedesign the process for the real operating volume. Do not solve volume scaling failure with more people inside an unchanged process design.
2.2Complexity Scaling Failure

Edge cases grow faster than the rules designed to handle them. At founding scale the common cases dominate. At current scale the edge cases multiply until they become the majority.

ExampleA two-sided marketplace's trust and safety policies. At 1,000 users, common cases dominate. At 100 million users, edge cases — fraud patterns, ambiguous content, cross-cultural norms — become the majority of case load.
CorrectionAudit the ratio of common-case to edge-case volume. Redesign the governance layer for the actual complexity profile now present, not the founding profile.
2.3Coordination Scaling Failure

Informal coordination that worked at small scale has no structural replacement at large scale. Nobody knows who owns the decision when twelve teams need to make it simultaneously.

ExampleAn engineering organisation that grew from 5 to 500 engineers while retaining the same ad hoc coordination practices. Decisions that two people could make in a corridor now require twelve teams and three timezones with no owned process.
CorrectionBuild formal coordination primitives for the scale now present: decision ownership, escalation paths, cross-team authority, and memory systems.
2.4Trust Scaling Failure

The platform was built on human reputation and relationships. At scale, those mechanisms stop working — the signals are too thin, the relationships too distant — and fraud, abuse, and quality collapse fill the gap.

ExampleAirbnb at 1,000 listings: host reputation is visible, reviews meaningful. At 8 million listings: the same review system is gamed, reputation signals manufactured, trust architecture structurally insufficient.
CorrectionRedesign the trust primitives for actual operating scale: structural verification, statistical signal detection, and governance mechanisms that do not depend on relationship density.
2.5Maintenance Decay Failure

The system was never designed for the maintenance load it now carries. Technical debt, documentation decay, and dependency accumulation create a structural maintenance burden that exceeds the organisation's capacity to manage it.

ExampleA legacy codebase where the maintenance burden of undocumented dependencies exceeds the capacity of the current engineering team — even with headcount increases the system continues to degrade.
CorrectionIdentify the maintenance primitives the system must carry and redesign for sustainability at the actual scale of the maintenance load, not the founding load.

The founding premise — about what users want, what technology can do, what the market looks like, or what the competitive environment allows — was wrong or has become wrong. The organisation continues to operate as if the premise holds.

Core diagnostic question: Which founding assumption is the organisation still executing against that has been materially disproved?

Include when

A core premise on which the operating model was built has been materially disproved; the organisation continues to execute against the original model; and the recurring failure traces back to that original mismatch.

Exclude when

The failure is caused by an external constraint the organisation cannot remove (Class 1); or the failure is in execution of a sound model rather than in the model itself.

Sub-types
3.1Market Premise Failure

The organisation was built for a market that does not exist at the assumed size, shape, or willingness to pay.

CorrectionDiagnose what market actually exists and whether the product can be redesigned to serve it. Do not iterate the product toward the assumed market — restate the premise.
3.2Technology Premise Failure

The product's core value depended on a technology capability that does not exist, cannot be achieved at the assumed cost, or has been commoditised.

CorrectionIdentify which layer of the value stack remains valid and redesign the model around what is genuinely achievable at the real technology cost.
3.3Economic Premise Failure

The unit economics the model was built on cannot be achieved at the operating scale required for sustainability.

CorrectionRestate the unit economics at real operating parameters. Identify whether a viable model exists within those parameters before continuing to execute the original model.
3.4Competitive Premise Failure

The competitive position the model assumed — first-mover advantage, network effects, structural moat — has been eroded or never materialised.

CorrectionDiagnose whether a defensible position exists given the actual competitive landscape. The correction is a new model, not a new marketing strategy.

Two or more systems are expected to interoperate, but their boundaries — around data, authority, timing, vocabulary, or ownership — were designed independently and are now structurally incompatible.

Core diagnostic question: Where do two systems meet, and what does each system assume about the other that the other cannot satisfy?

Include when

A failure lives at the interface between two systems; both systems function adequately in isolation; and the failure recurs at the boundary regardless of changes made within either system.

Exclude when

The failure is within a single system rather than at an interface; or the boundary is shared with an external party the organisation cannot negotiate with (Class 1).

Sub-types
4.1Data Boundary Failure

Two systems expect to share data that is defined, formatted, or updated differently in each. The mismatch is structural, not a communication failure.

CorrectionDefine the canonical data structure that both systems must work from, and establish which system owns it. Do not build translation layers indefinitely — fix the source definition.
4.2Authority Boundary Failure

Two systems each believe they have authority over the same decision. The conflict is structural: both systems were designed to own the same thing.

CorrectionAssign formal authority to one system and establish the interface through which the other system receives the decision. One system governs, the other consults.
4.3Timing Boundary Failure

Two systems operate at different time scales and the mismatch creates structural failure at the handoff point.

CorrectionIdentify the timing mismatch and design an explicit buffer or state-management layer at the boundary that holds state until both systems can align.
4.4Vocabulary Boundary Failure

Two systems use the same word to mean structurally different things, creating failures that appear to be communication problems but are actually definitional conflicts.

CorrectionProduce a bounded vocabulary that defines each term precisely for each system, and redesign handoffs to use the bounded vocabulary rather than natural language.
4.5Ownership Boundary Failure

Nobody owns the space between two systems. The interface is everyone's problem and therefore nobody's problem.

CorrectionAssign formal ownership of the interface itself. The interface is a system; it requires a governing owner, defined inputs and outputs, and a correction path when it fails.
4.6Cascading Dependency Failure

A failure in one system triggers failures in dependent systems in a sequence that amplifies faster than any single system can absorb or correct.

CorrectionMap the dependency chain and identify the structural isolation points that are missing. Design circuit-breaker conditions that prevent cascade propagation before redesigning the dependent systems.

The failure is not in the technology or the people — it is in the absence of a structural decision-making, enforcement, memory, or correction authority for a specific class of decisions.

Core diagnostic question: What class of decision has no structural owner — no person or system with the authority, information, and accountability to make, enforce, remember, or correct it?

Include when

A specific class of decision recurs; the decision has no structural owner; and the failure repeats because the absence of authority is not remedied by adding more people, process, or technology within the current structure.

Exclude when

Authority exists but is poorly exercised — that is an execution failure. Exclude if the governance gap is caused by scaling (Class 2) rather than by an inherent absence of authority design.

Sub-types
5.1Decision Authority Failure

No person or system has the structural authority to make a specific class of decision. Decisions are deferred, escalated, or made inconsistently because ownership is absent.

CorrectionAssign formal decision authority to a specific role or system. Specify the scope, the information required, and the escalation conditions. Communicate the assignment structurally, not through culture.
5.2Enforcement Authority Failure

Decisions are made but there is no structural authority to enforce them. Rules exist on paper; nobody is structurally empowered to require compliance.

CorrectionSeparate the decision-making authority from the enforcement authority and assign both explicitly. Enforcement requires its own owner, its own information, and its own correction path.
5.3Institutional Memory Failure

Decisions are made but not recorded in a form that persists across personnel changes. The same decision is remade repeatedly because the prior decision left no structural trace.

CorrectionDesign a memory system for the specific class of decision: who owns it, where it is recorded, who can retrieve it, and how it is updated. Memory is a structural function, not a documentation task.
5.4Correction Authority Failure

When decisions produce wrong outcomes, there is no structural authority to recognise the error and correct it. Errors persist because the correction path does not exist.

CorrectionDesign a correction authority that is distinct from the decision authority: who can observe outcomes, who can name errors, and who can override or revise the original decision.
5.5Feedback Loop Failure

The system has no structural mechanism for converting outcomes into decision inputs. Decisions are made without access to what previous decisions produced.

CorrectionDesign a feedback loop as a structural component: what signal is captured, by what system, in what form, and how it reaches the decision authority on the next cycle.

The incentive structure produces outcomes that diverge from organisational goals. Nobody is acting irrationally or maliciously. The structure itself is the problem.

Core diagnostic question: What rational behaviour does the current incentive structure reward that produces the outcome the organisation does not want?

Include when

The failure produces outcomes the organisation does not want; the people producing those outcomes are following rational incentives; and changing the people without changing the incentive structure would not change the outcome.

Exclude when

The failure is caused by deliberate bad behaviour rather than rational incentive-following; or the incentive structure is sound and the failure is in execution or measurement.

Sub-types
6.1Measurement Misalignment

The metric being optimised is not the outcome the organisation actually needs. People maximise the measured thing at the expense of the unmeasured thing that matters.

CorrectionIdentify what is being measured versus what the organisation actually needs. Redesign the measurement system around the genuine outcome, not its proxy.
6.2Reward Misalignment

The reward structure compensates behaviour that produces the wrong outcome. People are rewarded for activity that looks right but produces structural harm.

CorrectionMap the reward structure against the actual outcomes it produces. Redesign so the reward is coupled to the structural outcome, not the visible activity.
6.3Time Horizon Misalignment

Decision-makers are rewarded on short-term outcomes; the structural costs of those decisions are paid on long-term timescales they will not personally experience.

CorrectionExtend the consequence window for decision-makers through delayed vesting, structural accountability, or decision logging that creates personal consequence for long-term outcomes.
6.4Principal-Agent Misalignment

The agent is structurally positioned to benefit from outcomes that harm the principal. The relationship is structurally conflicted, not a matter of individual integrity.

CorrectionIdentify the structural conflict of interest and redesign the relationship so the agent's reward is coupled to the principal's outcome, not to an intermediate metric the agent controls.

The failure is not in the humans — it is in the system's design assumption that humans will reliably do something they structurally cannot sustain. The system places cognitive, procedural, or interpretive demands that exceed what humans can reliably carry under real operating conditions.

Core diagnostic question: What does this system require humans to reliably do that humans cannot reliably do under actual conditions?

Include when

The failure traces to a structural assumption about human behaviour; that assumption is violated under real operating conditions of load, ambiguity, or complexity; and the failure would disappear if the system stopped making that assumption.

Exclude when

The failure is caused by individual bad behaviour or deliberate violation. Exclude if the human load has simply grown beyond design capacity — that is Class 2 (Volume Scaling Failure).

Sub-types
7.1Cognitive Load Failure

The system requires humans to hold too much in working memory simultaneously. Errors are produced not by incompetence but by structural overload.

CorrectionIdentify what the system is requiring humans to hold in working memory and redesign the system to carry it structurally. Move the cognitive load from the human to the system.
7.2Ambiguity Absorption Failure

The system produces ambiguous outputs or instructions and relies on humans to resolve the ambiguity consistently. The resolution is inconsistent because the ambiguity is structural.

CorrectionIdentify where the system produces ambiguity and redesign it to produce unambiguous outputs. Move ambiguity resolution from humans to system design.
7.3Procedure-Reality Gap Failure

The documented procedure and the real operating practice have diverged. Humans work around the procedure to get the job done; the procedure is nominal.

CorrectionDocument the actual practice and redesign the formal procedure around it. Do not enforce a nominal procedure against a diverged reality — the divergence is a signal about what the system actually requires.
7.4Alarm and Signal Failure

The system produces more signals than humans can process, or produces signals that cannot be distinguished from noise. Critical signals are missed because the signal architecture is structurally unusable.

CorrectionAudit the signal-to-noise ratio. Redesign the signal architecture so critical signals are structurally distinguishable and actionable without requiring sustained human attention to monitor noise.
7.5Black Box Decision Failure

The system makes decisions humans cannot understand, override, or correct. Accountability is structurally absent because the decision process is opaque.

CorrectionDesign a legibility layer that makes the system's decisions understandable, a correction path that allows humans to override or revise them, and an accountability structure that assigns responsibility for outcomes.
7.6Shadow System Proliferation

Humans have built informal systems — spreadsheets, workarounds, offline processes — to do the work the formal system cannot do. The shadow systems have become load-bearing.

CorrectionMap what the shadow systems are doing that the formal system cannot. Redesign the formal system to carry that function structurally, then retire the shadow systems in dependency order.

The failure is not in the origin state or the target state — it is in the transition itself. The movement between states has not been designed as a governed sequence, and failure occurs in the space between.

Core diagnostic question: What is the system in movement between, and where does the transition itself produce failure that neither the origin nor the target state contains?

Include when

The system is currently in transition between states; the failure occurs in the transition itself rather than in the origin or target state; and the failure would not occur if the system were stable at either end.

Exclude when

The failure is in the target state design rather than the transition; or the failure is a steady-state failure that was present before the transition began.

Sub-types
8.1Parallel Operation Failure

The old system and the new system are running simultaneously, creating conflicting states, duplicate processes, and accountability gaps in the overlap zone.

CorrectionDesign the parallel operation period as a governed transition with a defined handover sequence, explicit ownership at each stage, and a retirement date for the origin system.
8.2Dependency Sequencing Failure

The transition is being executed in the wrong order. Changes are being made to dependent systems before the systems they depend on have been changed.

CorrectionMap the dependency order and redesign the transition sequence so dependencies are resolved before the systems that depend on them are migrated.
8.3Identity Continuity Failure

During a merger, acquisition, or reorganisation, the new entity cannot establish a stable identity — who owns what, who has authority, whose processes govern — and the resulting ambiguity produces recurring failure.

CorrectionDefine the governing structure of the new entity explicitly before the transition completes. Authority, ownership, and process governance must be assigned to the new entity, not carried over implicitly from both predecessors.
8.4Deadline-Driven Compression Failure

An external deadline has compressed the transition timeline to the point where structural dependencies cannot be resolved in order. The deadline produces a structurally incomplete transition.

CorrectionIdentify which dependencies cannot be resolved within the deadline and design an explicit interim state that is structurally stable until the remaining dependencies can be addressed. Do not compress the dependency sequence — compress the scope of what the deadline delivers.

The institution compresses its own governance obligations onto the individual. The individual must carry administrative, evidential, reputational, or relational burden that the institution was designed to carry — and cannot carry it without losing access to what the institution controls.

Core diagnostic question: What institutional obligation has been transferred to the individual — and what does the individual lose when they cannot carry it?

Include when

An individual is absorbing burden that a governing institution should carry; that burden recurs structurally rather than as a one-off administrative friction; and the individual loses access or entitlement when they cannot carry the burden.

Exclude when

The administrative burden is genuinely reasonable given the nature of what is being accessed; or the failure is a one-off error rather than a structural pattern.

Sub-types · 9.1–9.13
9.1Access Allocation Failure

Access to a resource or entitlement is allocated through a process the individual cannot navigate without specialist knowledge, persistent effort, or insider information. The allocation mechanism compresses the institution's obligation to distribute access fairly onto the individual's capacity to navigate complexity.

9.2Record-Return Paradox

The individual needs records to access entitlements, but the institution holds those records and will not release them without prior authorisation from the entitlement the individual cannot yet access. A closed loop where access requires proof and proof requires access.

9.3Consent Compression Failure

Consent is obtained in a form — volume, complexity, or frequency — that makes genuine informed consent structurally impossible. The individual must consent without understanding, or lose access.

9.4Verification Burden Failure

The institution places the burden of identity or eligibility verification on the individual in a form that creates structural exclusion for those who cannot provide the required documentation.

9.5Reputation Compression Failure

The individual's access or treatment is determined by a reputational signal they cannot understand, contest, or correct. The reputation system is opaque and the individual cannot navigate it.

9.6Relationship Continuity Failure

A relationship that requires continuity — care, support, professional relationship — is interrupted by institutional structure, and the individual must rebuild it from scratch each time.

9.7Commitment Compression Failure

The institution makes commitments it cannot keep, and the individual must absorb the gap between the commitment and the reality without recourse.

9.8Care Continuity Failure

Care — medical, social, or professional — is fragmented by institutional structure so that no single actor carries the individual's full picture. The individual must carry their own care continuity across a system designed to provide it.

9.9Entitlement Reset Failure

An entitlement the individual had built up is reset — by system change, institutional restructuring, or policy shift — without acknowledgment or compensation. The individual must restart from zero.

9.10Narrative Compression Failure

The institution reduces the individual to a category or data point that does not capture their actual situation. The individual must carry the burden of being misrepresented in a system that makes decisions based on that misrepresentation.

9.11Punitive Memory Failure

The institution retains a record of the individual's past failure — a penalty, a debt, a classification — beyond the point where that record serves a structural purpose. The individual cannot escape the record.

9.12Category Misassignment Failure

The individual has been placed in the wrong category by the institution — the wrong risk band, the wrong eligibility tier, the wrong classification — and cannot correct the assignment through normal channels.

9.13Treatment Continuity Failure

Ongoing treatment — medical, therapeutic, legal, or administrative — is interrupted by institutional structure rather than by the individual's situation. The interruption creates harm that the institution is not designed to track or repair.

what to do next
Not sure which class fits?

Run the 60-Second Scan first. Four questions that surface your system's purpose, primitive, and failure signal — so you know which class to test before entering the criteria.

RUN THE 60-SECOND SCAN →
Know your class. Need the correction?

The taxonomy names the class. The Diagnostic Artifact names the governing break inside your specific system and produces the correction sequence your builders execute against.

EMAIL FIVE-LINE BRIEF
This taxonomy is Paper 11 of the Diagnostic and Replacement Series — the classification standard that makes all prior papers interoperable. Papers 12–59 will anchor each sub-type in deeper evidence. Paper 11 is the permanent reference point. Read the full research series →  ·  See how the method applies it →
Ready to apply this?

Send the repeated failure. Five lines and any relevant material.

EMAIL FIVE-LINE BRIEF RUN THE SCAN →