How I diagnose recurring structural failure.
I do not begin with symptoms alone. I begin by identifying the structure producing them.
Most recurring failure is not just a matter of local execution, poor communication, or one bad decision. It is structural. Something in the system is doing the wrong job, not doing any job at all, or forcing humans to absorb work the system should absorb itself.
My method is designed to make that visible.
This method applies when the same problem keeps returning under different names, when teams do not share the same structural read, when workarounds have quietly become load-bearing, or when builders are being forced to invent the design while implementing it.
The purpose is not to generate more commentary around the problem. The purpose is to produce one serious structural read that decision-makers and builders can act against.
How the diagnosis works
Define the system properly
The first task is to identify what system is actually under analysis. That means defining the real boundary, the real scope, the adjacent systems, and where the work actually lives. Domain names and team names often describe the surface, not the operational structure underneath. Before diagnosis can be trusted, the system being named must be made explicit.
Identify the primitive and governing rules
Once the system is defined, I identify what it repeatedly does — the primitive: the smallest unit of real work the system is organised around. I then surface what the system optimises for in practice, and the rules, constraints, and invariants that govern that repeated action. The question is not just what the policy says. It is what must actually hold for the system to function without drift.
Trace the failure path
The next task is to identify where rules become real, where they fail, and what happens when they do. This includes interfaces, handoffs, decision points, enforcement points, and the places where burden quietly moves elsewhere. I look for where work stalls, where ambiguity crosses boundaries, where compensation mechanisms appear, and where humans have become the hidden reliability layer. Recurring failure follows a path. The path must be traced.
Separate the stated problem from the actual problem
Clients usually arrive with a real pain pattern, but not always with the real diagnosis. One of the central tasks of the artifact is to separate what the client thinks is failing from what is actually producing the failure — and to explain why prior fixes have not held. This is where the governing diagnosis is formed: the central structural truth from which the rest of the failure follows.
Make the stakes legible
A diagnosis is incomplete if it does not make consequence visible. I make the current cost of the failure legible in practical terms: operational cost, human cost, financial cost, coordination cost, and future compounding risk where relevant. If the structural cost remains vague, the system will continue to absorb it invisibly.
Produce the artifact
The final task is to turn the diagnosis into a builder-readable structural document. The artifact names the system clearly, locates the rule that is breaking, explains the mismatch, defines what must change first, and shows what depends on what. It is not a brainstorming document and not a generic strategy deck. It is a source of structural truth that decision-makers and builders can use as a common reference point.
What I am looking for
Across different systems, I am often looking for the same classes of structural problem. The goal is not to collect every symptom. The goal is to identify the smallest set of structural truths that explains the recurring pattern.
I am also looking for places where a failure appears local but is actually systemic, where a named product is really functioning as something else, or where burden is being displaced onto the wrong people, teams, or functions.
- Hidden incentives misaligned with stated purpose
- Unclear ownership across interfaces
- Weak or absent system boundaries
- Broken or unenforced rules
- Fragmented sources of structural truth
- Recurring misclassification of work
- Drift between policy and operating reality
- Repeated human workarounds that have become the operating model
What the artifact contains
The exact shape of the artifact varies with the system, but the principle stays the same: the output must be serious enough to align decision-makers and concrete enough for builders to work from.
It is designed to give your team one document that makes the real failure visible, names what must change first, and reduces interpretation drift across the people responsible for acting on it.
- 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
Why this is different
This is not a technical root-cause analysis, a live incident response service, or a general consulting workshop. It is not designed to debug one isolated bug, patch one urgent issue, or produce vague strategy language that every team can interpret differently.
It is designed to identify the structural layer beneath recurring failure and convert that diagnosis into one written artifact that can actually govern action.
Many systems are repeatedly fixed at the symptom layer while the governing structure remains untouched. This work starts where surface explanation stops being sufficient.
How I produce the work
The work is architecture-led. I develop the frameworks, structural distinctions, diagnostic logic, and final conclusions myself. AI assists execution — I use it as a drafting, articulation, and production tool to work more clearly and efficiently, but not to replace reasoning.
I do not begin with generated output and work backwards from something plausible-sounding. I begin with structure. AI may help me organise material, test phrasing, refine drafts, or reduce production friction, but it does not decide what system is actually being diagnosed, which rule is breaking, or what must change first.
The thinking, the framework, and the responsibility are mine.
- Articulating complex ideas more clearly
- Organising material into more usable forms
- Drafting and redrafting prose
- Testing alternative phrasings and structures
- Supporting research exploration
- Reducing production friction across writing and artifacts
Review and accountability
Everything published or delivered under my name is reviewed by me. That means I am responsible for the framing, the reasoning, the recommendations, the final form of the work, and the decision to publish or deliver it.
I do not treat model output as authoritative on its own, and I do not deliver work simply because it sounds plausible. If something appears under my name, I stand behind it.
What this means for clients
If you engage me for a Diagnostic Artifact or Redesign Artifact, you are not paying for automated output.
You are paying for structural judgment, clear framing, serious synthesis, and a written artifact built to be used by decision-makers and builders.
AI may assist parts of the production process, but the diagnostic logic, structural interpretation, and final recommendations remain mine. The aim is to give you one document that makes the real failure visible, names what must change first, and reduces interpretation drift across the people responsible for acting on it.
If your system keeps failing in the same way under growth, send the failure pattern first. Describe what keeps returning, what it is costing, where it shows up, what has already been tried, and what cannot change.