What I do

When the same failure keeps returning, the problem is no longer execution. It is structure.

I make the hidden rules visible, locate the structural failure precisely, and produce a written artifact your team can act against.

Two fixed-scope engagements: a Diagnostic Artifact that names the real failure, and a Redesign Artifact that defines the change sequence. Read the method →


The same failure costs more the second time than the first. At some point, the structure has to be named.

What this is →
A Diagnostic Artifact that names the structural failure, and a Redesign Artifact that defines the change sequence.
What it solves →
Recurring failure caused by hidden structure in interfaces, incentives, ownership, or enforcement.
Who it is for →
Founders, CTOs, and product or platform leads who need a structural read their builders can execute against.
How to start →
Email five lines plus any relevant materials you already have.
what changes

What changes once the artifact exists.

It does not add another summary or interpretation layer. It gives decision owners and builders a shared structural read of the failure, the rule that is breaking, and the order in which change must happen.

01

The failure is named correctly

The repeated symptom stops being discussed as a moving target. The structural failure is named once and located precisely.

02

Builders stop designing while implementing

The artifact becomes the design source. Builders execute against a written structure instead of inventing interpretation midstream.

03

Humans stop patching structural gaps

Humans stop carrying work the system should carry. The artifact defines what the system must enforce, what it must not absorb, and where the boundary sits.

VIEW SERVICES →
core offerings
Core offerings

Start with the artifact that matches the state of the problem.

Two fixed-scope written engagements. Start with diagnosis when the failure is still structurally unclear. Move to redesign when the failure is visible but the transition path is not.

01 // Diagnostic Artifact
£10,000Fixed fee

A structural diagnosis your team can circulate and act against.

entry engagement 14 days fixed-scope

Start here when something keeps breaking but the real failure is not yet visible. Use it to make the real rules visible before builders move.

When to use this: The same failure keeps reappearing. Teams disagree on what the problem actually is. Policy and reality have drifted apart. No one has a single structural read everyone can act against.

What you receive
  • System topology: where work actually flows and where the burden really lands
  • Primitive definition: the real unit of work
  • Invariants: rules that must not break
  • Enforcement map: where rules live vs where they break
  • Mismatch analysis: stated design vs operating reality
  • Build map: what must change first, and what depends on what
REQUEST DIAGNOSTIC Fixed fee · 14-day delivery · One clarification pass
02 // Redesign Artifact
£15k–25kScope-dependent

A redesign blueprint builders can execute with confidence.

follow-on engagement 14 days builder handoff

Start here when the failure is visible but the change sequence is not. Use it to define what changes first, what stays fixed, and how regression is blocked.

When to use this: The failure is understood but the transition path is not. Builders are being forced to invent design midstream. Implementation keeps drifting back to the same broken state.

What you receive
  • Target boundary spec: what changes and what does not
  • Transition sequence: Step 1 → N
  • Interface changes: what must be tightened, removed, or clarified
  • Dependency order: what moves first, and what depends on what
  • Drift refusal gates: constraints that prevent regression
  • Execution handoff: a builder-readable sequence for implementation
REQUEST REDESIGN Requires prior diagnosis or bounded brief · 14-day delivery
diagnostic scan

Not sure if your problem is structural?

Four questions. Answer them honestly and the structural problem — if there is one — becomes visible. Use this before you send a brief.

// Diagnostic Scan
RUN THE SCAN →
selected research
// Selected research Diagnostic Lens Trilogy · 3 papers on SSRN

Three papers diagnosing recurring failure across platforms, institutions, and self-correcting systems. Together they move from mismatch between signalled and consumed capability, to collapse through function fusion under consequence, to the missing redesign layer that internal correction loops cannot reliably produce.

Paper 01 Preprint on SSRN
Cover: The Expertise Illusion in AI Task Marketplaces

The Expertise Illusion in AI Task Marketplaces

How reliability pipelines borrow the language of expertise. Introduces interface-legitimacy mismatch and the Transfer Test: systems that signal one kind of capability while operationally consuming another.

Paper 02 Preprint on SSRN
Cover: The Four-Function Law of Scalable Institutions

The Four-Function Law of Scalable Institutions

Introduces the Four-Function Law: institutions fail under scale when sensing, interpretation, authority, and memory remain fused in the same human node at the point of consequence.

Paper 03 Preprint on SSRN
Cover: Why Systems Can't Fix Themselves

Why Systems Can't Fix Themselves: The Missing Redesign Layer

Introduces the Redesign Law and correction collapse. Distinguishes execution, diagnosis, and redesign, and shows why the first two cannot reliably produce the third from within the same correction loops.

3Preprints on SSRN
4Books in progress
2Current builds
READ THE TRILOGY → FULL RESEARCH PAGE
fit and scope
// Fit and scope who this is for
Good fit

A failure has started repeating and nobody has a single structural read of what is actually wrong.

  • The same failure keeps returning under different labels
  • Teams disagree on what the real problem actually is
  • Builders are inventing design while implementing
  • Manual workarounds are carrying load the system should absorb
  • Ownership is blurred across roles, teams, or interfaces
  • Policy, tooling, and operating reality have drifted apart
  • The cost is recurring but the cause is structurally unclear
Not a fit

The issue is narrow, isolated, and already understood at the technical layer.

  • A one-off bug with a clear technical owner
  • A known defect requiring engineering execution
  • A live incident needing operational command
  • Code-level root-cause analysis from logs or infrastructure
  • Architecture, security, or infrastructure work
  • Vague dissatisfaction without a bounded failure pattern
  • Implementation support where the design is already settled
how to start
// How to start entry route

If your system keeps failing in the same way under growth, send the failure pattern first. I review fit and determine whether the work should begin with diagnosis or move directly to redesign.

The five-line brief is a fit screen, not the diagnosis itself.

Step 01

Send the brief. Five lines plus any relevant material you already have.

Step 02

I review fit. Diagnosis if the structure is still unclear; redesign if the failure is already visible.

Step 03

You receive the artifact. One written document built for decision-making and builder execution.

Submit a five-line brief
  1. 01What keeps going wrong? Describe the failure that keeps returning.
  2. 02What is it costing? Describe the cost in money, time, trust, load, delay, or drift.
  3. 03Where does it show up? Name the teams, roles, systems, or customer touchpoints involved.
  4. 04What has already been tried? List any fixes, workarounds, or decisions already attempted.
  5. 05What cannot change? State the non-negotiables, constraints, or conditions that must still hold.

If neither engagement is the right fit, I will say so.

↑ BACK TO TOP