When the same failure keeps returning, the problem is no longer execution. It is structure.
I write fixed-scope diagnostic and redesign artifacts for founders, operators, and decision owners facing recurring structural failure. Two paths from £10,000. Diagnosis first. Redesign only from a locked diagnostic frame. Start with the five-line brief.
Written artifacts · Fixed scope · No hourly rates
The same failure costs more the second time than the first. At some point the structure has to be named.
Jamie Forrester
Independent Systems Architect
Most consultants fix the symptom. I name the structure producing it.
- ✓The same failure keeps returning under different names
- ✓Internal fixes have not held — the correction loop is missing the real break
- ✓The team cannot agree on what is actually breaking
- ✓Builders are inventing design decisions during implementation
- ✓Workarounds have become part of the operating model
- ✓The visible symptom is downstream of a rule, boundary, or primitive mismatch
- ✗You need code debugging or a technical audit
- ✗You need live incident response
- ✗You need implementation ownership or delivery
- ✗You need generic strategy advice
- ✗The failure is one-off or already diagnosed
- ✗The diagnosis is known and you only need delivery
The full field pipeline — where the engagement sits
The full path from first failure signal to governed implementation.
The engagement covers Signal through Qualify. Your builders carry Build through Govern against the artifact. Extract is where reusable value, laws, and future systems are derived.
Read the method →Three systems. Same method. Public proof it repeats.
Self-screen before sending a brief.
Four questions. Answer them honestly and you will know whether the failure is structural, and where to look first. Use this as a first-pass fit check before briefing.
Two paths. Fixed scope. No hourly rates.
Use diagnosis when the failure must be named. Use full engagement when the correction sequence must be specified.
Commissioned separately, diagnosis and redesign total £35,000. As one governed sequence, £25,000. Full service details →
Send the repeated failure. Not the proposed fix.
The five-line brief. No diagnosis yet. Just the signal.
Send five lines plus any relevant material.
I review fit and confirm the right path. No one moves to redesign without diagnosis first.
You receive the artifact — either the Diagnostic Artifact or the full four-artifact sequence.
- 01What keeps going wrong?
- 02What is it costing? Money, time, trust, load, or drift.
- 03Where does it show up? Teams, roles, systems, or touchpoints.
- 04What has already been tried?
- 05What cannot change? Non-negotiables and constraints.
If neither engagement is the right fit, I will say so.
The structural laws the method applies. The Diagnostic Taxonomy is the classification standard behind every engagement. The papers expose the public logic behind the four-artifact sequence.
The Complete Diagnostic Taxonomy
Nine failure classes · 54 sub-types · formal inclusion, exclusion, and refusal criteria
The classification standard that makes the entire research series interoperable. Every engagement is classified against this taxonomy before diagnosis begins.
View full taxonomy →
The Four-Function Law
How institutions fail under scale when four functions remain fused
Institutions fail under scale when sensing, interpretation, authority, and memory remain fused in the same node at the point of consequence. The law that governs structural collapse at scale.
All 11 papers →The research is public and free to read. The taxonomy and papers define the structural laws the method applies — not the client artifacts themselves.
The failure recurs. Your fixes aim inside the frame. The break is outside it.
- ✓Your teams are fixing the same symptoms across different departments, systems, or codebases
- ✓You operate through a platform or system you cannot change — and it keeps producing a failure you carry
- ✓The failure lives at a seam between two systems — and neither team owns it
- ✓Manual workarounds have become load-bearing
- ✓No one has authority over the decision class producing the failure
The failure is narrow, isolated, or already understood — or the organisation has chosen to retain the governing break.
- ✗A one-off bug with a clear technical owner
- ✗A live incident needing operational command
- ✗A structural mismatch the organisation already understands and has decided to retain
- ✗Architecture, security, or infrastructure work
- ✗Vague dissatisfaction without a repeated failure pattern