How recurring failure becomes a structural diagnosis — and, when needed, a redesign.
Recurring failure is rarely caused by one bad decision or a lack of effort. When the same outcome keeps returning despite correction, the problem usually sits in the structure producing it. This method is designed to locate that break, explain why previous fixes have not held, and determine what must change.
It begins where symptom-level explanation stops being sufficient.
When correction keeps failing.
- The same failure returns despite repeated correction.
- Reform programmes stall at the same structural boundary.
- A platform, regulator, or inherited architecture cannot be changed directly.
- Workarounds have become load-bearing.
- Builders are making design decisions while implementing.
The purpose is not more commentary. It is one structural read that can survive the journey from leadership to operators to builders.
The 60-Second Scan
Four questions that surface the structural reality of a system before analysis begins.
The scan is not the diagnosis. It is the orientation layer — the minimum structural read needed to know whether a system is a candidate for structural diagnosis at all. Purpose → Primitive → Rules → Failure. Answer all four clearly and the likely structural pattern begins to emerge. If the answers are hard to state, that is useful signal in itself.
Not the stated mission. The real action the system exists to make happen. The job it would stop doing if it broke.
The primitive — the basic unit of real work the system is organised around. In plain terms: what does this system repeatedly do?
The invariants — the conditions that must actually stay true for the system to work. Not just the written policy: the rules reality depends on.
The failure signal — what the system does instead, who absorbs the burden, and how the failure recurs. This is where the structural break first becomes visible.
The scan connects directly to the Five-Line Brief. Once the four questions have a clear answer, the failure pattern is ready to brief. Run the scan first. Send the brief second. The scan sharpens the signal before it enters the diagnostic process.
Diagnostic Taxonomy
Nine failure classes. Fifty-four subtypes. Formal inclusion, exclusion, and refusal criteria.
The taxonomy gives recurring failures a consistent classification instead of treating each case as unique. Nine top-level classes locate the kind of structural break; 54 subtypes identify the more specific mechanism. That classification constrains the diagnosis and helps determine what kind of correction could actually hold.
Artifact Production Pipeline
Failure signal through to builder-ready artifact. A governed production sequence — not subjective consulting.
Every artifact follows the same pipeline. The work is not produced by opinion or instinct. The structural conclusions, diagnostic logic, and correction order are governed by the taxonomy and the diagnostic sequence below. AI assists drafting and production. It does not determine the governing diagnosis, the redesign boundary, or the correction order.
Proof Standard
The same pressure applied to different systems produces different responses. The proof standard determines what holds.
Every diagnostic claim must survive the following test: if the system were stressed at the point of claimed failure, would the structural break appear where it is said to appear? A claim that cannot survive scrutiny does not belong in the artifact. A plausible-sounding diagnosis that is wrong is actively harmful.
- It must name a structural condition — not a symptom, not a behaviour
- It must locate the break precisely — not "communication" or "culture"
- It must explain why prior fixes have not held
- It must survive the removal test: if corrected, does the failure pattern change?
- It must be falsifiable — if it cannot be wrong, it is not diagnostic
- A pattern that matches without locating a structural cause
- An inference unsupported by the material in scope
- A claim that renames the symptom without naming the break
- A redesign released before the diagnostic frame is confirmed
- A conclusion the system's owner already held before the work began
When diagnosis cannot be completed: Sometimes the available material is not sufficient to produce a diagnostic conclusion that can hold under scrutiny. The failure pattern may be too ambiguous, the system boundary too contested, or the material too thin. In these cases, I will say so rather than produce an artifact that appears complete but is not. Refusal is part of the method, not a failure of it.
How recurring-failure diagnosis works — the seven-step sequence
Define the system properly
The first task is to identify what system is actually under analysis — the real boundary, real scope, adjacent systems, and where work actually lives. Domain and team names often describe the surface, not the operational structure. This step must come first because every subsequent diagnostic claim depends on having the right system in scope. A diagnosis of the wrong system is not a partial diagnosis. It is a different artifact entirely.
Identify the primitive and governing rules
Once the system is defined, I identify its primitive — the smallest unit of real work the system is organised around — and the rules, constraints, and invariants that govern that action. The question is not what the policy says. It is what must actually hold for the system to function without drift. This step must come before failure tracing because a broken rule can only be identified once the governing rule has been named.
Trace the failure path
With the system and its governing rules established, I trace where rules become real, where they fail, and what happens when they do — interfaces, handoffs, decision points, enforcement points, and places where burden moves elsewhere. I look for where humans have become the hidden reliability layer. This step must precede diagnosis because the failure path shows where the break actually lives, which is rarely where it first appears.
Form the governing diagnosis
This is the central moment of the method. The governing diagnosis is the structural truth from which the rest of the failure follows — the one claim that, if correct, explains why prior fixes have not held and what must change before any intervention will. It separates what the client thinks is failing from what is actually producing the failure. Everything in the artifact either leads toward this paragraph or flows from it. It is the paragraph decision-makers will circulate internally.
Make the stakes legible
A diagnosis is incomplete if it does not make consequence visible. I make the current cost of the failure legible: operational cost, human cost, financial cost, coordination cost, and future compounding risk. Structural cost that remains vague continues to be absorbed invisibly — and invisible cost does not produce structural decisions.
Lock the diagnostic frame
The Diagnostic Artifact is delivered first. Its governing diagnosis is clarified and confirmed before redesign is released as the governing replacement. This prevents an unconfirmed frame from directing the change sequence while keeping the Full Structural Engagement inside one 14-day production window. A redesign released before the diagnostic frame is confirmed would be speculative. A speculative redesign is not what this practice delivers.
Produce the artifact
The final task in recurring-failure work is to produce the agreed artifact path — either a Diagnostic Artifact alone, or the complete four-artifact governed sequence in the Full Structural Engagement. The Structural Lens Brief sits outside this seven-step diagnostic sequence because it extracts architecture rather than diagnosing a recurring failure. In the full engagement, the same locked diagnosis produces four linked outputs:
- Translation Artifact — shared language layer for leadership, operations, and non-specialist audiences
- Diagnostic Artifact — governing diagnosis, evidence base, and build map
- Redesign Executive Summary — board-level public summary of the restricted specification
- Full Redesign Artifact — restricted builder specification: corrected primitive, transition sequence, dependency order, refusal invariants, recapture gates, and builder handoff
Redesign sequence — diagnosis before redesign
Redesign is not produced by brainstorming solutions against a problem statement. It follows from the locked diagnosis. The sequence is non-negotiable. Each stage depends on the one before it.
What the artifacts contain
The three engagements produce different levels of structural work. The Lens exposes architecture. The Diagnostic names the recurring structural break. The Full Engagement carries a locked diagnosis into shared language, executive decision-making, and an implementation-ready redesign sequence.
- The underlying structure of the problem, system, method, or body of work
- The principal functions the structure must perform
- Key boundaries and dependencies
- Structural tensions or mismatches worth making explicit
- A concise architecture map in a 6–10 page written brief
- Plain-language explanation of the structural failure
- Shared vocabulary across leadership, operations, and non-specialist roles
- Accessible explanation of the governing diagnosis
- Why prior fixes have not held
- Plain-language summary of the replacement direction
- Audience routing guidance — who reads what and where to go next
- A clear definition of the system under analysis
- A structural view of how work actually flows
- The primitive and governing rules
- The key interfaces and failure path
- The distinction between stated and actual problem
- The governing diagnosis
- The present and future cost of the failure
- What must change first, and what depends on what
- Board-level replacement logic
- Corrected primitive
- Minimum valid replacement conditions
- Fake-progress tests
- Proof standard and consequence of deferral
- Dependency order in plain terms
- The corrected primitive — what the system must actually be organised to do
- Target boundary — what changes and what does not
- Transition sequence — the dependency-ordered change path
- Interface changes — what must be tightened, removed, or clarified
- Drift refusal gates — constraints that prevent regression
- Builder handoff — the execution-ready sequence
How I produce the work
The work is architecture-led. The frameworks, structural distinctions, diagnostic logic, and conclusions are mine. AI assists drafting and production — it helps me work more clearly and efficiently. In a Full Structural Engagement, AI may also assist with consistency checking across all four artifacts. It does not decide what is being diagnosed, which rule is breaking, or what must change first, and does not determine the final recommendations in any artifact.
Every artifact is reviewed before delivery. The structural conclusions are mine. The diagnostic sequence, governing laws, and correction order are not delegated to AI, pattern-matching, or probabilistic inference. If a claim cannot survive scrutiny, it does not belong in the artifact.
- Drafting and refining prose
- Organising material into usable forms
- Testing phrasings and structures
- Structuring large volumes of background material
- Determine the governing diagnosis
- Decide the redesign boundary or correction order
- Generate the structural laws the work applies
- Replace review, judgment, or accountability
The research behind the method
The method is grounded in 10 published research papers and the complete Diagnostic Taxonomy, all within a 59-paper research programme that is already mapped. The published papers define the structural laws the method applies: primitive mismatch, function collapse, burden transfer, the missing redesign layer, institution migration, replacement pipeline construction, admissibility conditions, governed correction sequences, host-constrained primitive compression, and kernel reduction. The taxonomy provides the shared classification standard: nine failure classes, fifty-four subtypes, with formal inclusion, exclusion, and refusal criteria.
The papers are not the method. They are the public form of the structural laws the method is built on. The artifacts are the applied form of those laws within a bounded system.
When to start
If you need architecture exposed: request a Structural Lens Brief. That route does not require a recurring failure or the Five-Line Brief.
If the same failure keeps returning: run the 60-Second Scan if useful, then send the Five-Line Brief. I will confirm whether the right recurring-failure path is the Diagnostic Artifact alone or the Full Structural Engagement. Both use the same locked diagnostic frame; Full then carries that diagnosis into the four linked redesign artifacts.
Send the repeated failure. Five lines and any relevant material.