This page explains the engagement process. For the diagnostic logic behind the work itself, read the method →
working protocol
01 // Working protocol how we interact

Written-first, asynchronous, and bounded.

written-first async by default fixed process

Most of the work is conducted through written exchange and artifact review. I do not move into your workflow, join your Slack, or begin with a chain of meetings. The point is to preserve structural objectivity and keep the process efficient.

Default mode

Email, document review, and written clarification. This keeps the engagement focused on structural signal rather than conversational noise.

Clarifying questions

If something important is missing, I may ask targeted questions. These are used to tighten scope and locate the real boundary — not to create a meeting cycle.

What this prevents

Premature implementation, endless alignment calls, and the slow drift that happens when the work stays verbally defined rather than written down.

the process
02 // The process start to finish

A fixed sequence from intake to delivery.

Five steps. Each one is defined before the next begins. The process does not expand, loop back, or drift into ongoing advisory. It ends with a written artifact.

01Five-Line Brief

You begin by emailing five lines: The Pattern, The Stake, The Interfaces, Concentration, and Constraints. Attach any materials that reflect the current state — diagrams, policies, workflows, contracts, post-mortems, screenshots. Accuracy matters more than polish.

02Fit Assessment

I review the brief and materials to determine whether the issue is structurally suited to this approach, whether the boundary can be clearly defined, and whether the correct starting point is Diagnosis or Redesign. If it is not a fit, I say so here.

03Scope Confirmation

If the fit is correct, the engagement is confirmed as a fixed-scope written intervention. The boundary of the work is set explicitly before analysis begins. This is the point at which the process becomes binding.

04Upstream Work

I work through the materials. For Diagnosis: I expose the real structure — the primitive, invariants, enforcement map, mismatch, and build map. For Redesign: I define the target boundary, transition sequence, interface changes, dependency order, and drift refusal gates. In both cases, the goal is to make the next move structurally legible before execution begins.

05Delivery and Clarification

You receive one structured written artifact within 14 days of engagement start. It is designed for internal circulation, decision-making, and builder handoff. One minor clarification pass is included after delivery. If the boundary changes or new analysis is required, that becomes a new engagement.

which route applies
03 // Which route applies diagnosis vs redesign

Not every system starts in the same place.

The Five-Line Brief exists partly to answer this question. Both routes end with a written artifact. The difference is where the structural uncertainty currently sits.

Start with Diagnosis

When the real structure is still hidden

Begin with Diagnosis when the failure keeps recurring under different names, the team is still debating what is actually breaking, or the real rules have never been made explicit. The Diagnostic Artifact makes the structure visible before anyone moves.

Start with Redesign

When the path to change is unclear

Move directly to Redesign when the failure mode is already obvious, the boundary is already visible, and the real bottleneck is a lack of a clear, ordered transition sequence. The Redesign Artifact defines what changes first and prevents regression.

If the correct route is unclear

The fit assessment resolves this. If you are unsure whether you need Diagnosis or Redesign, send the Five-Line Brief and I will determine the correct entry point. You do not need to know before you send.

what you provide
04 // What you provide client inputs

Useful signal, not polished presentation.

You do not need a perfect brief or a well-organised document pack. Most clients arrive with messy, partial, or contradictory materials — that is normal. What matters is that the materials reflect what is actually happening, not what the official narrative says.

What to send
  • 01 A completed Five-Line Brief
  • 02 Diagrams, policies, workflows, notes, contracts, or screenshots
  • 03 Post-mortems, incident reports, or internal documents that show what actually happened
  • 04 A clear statement of known constraints: technical, legal, budgetary, or operational
  • 05 Timely written responses if clarifying questions are required
What matters most
  • Accuracy over polish — rough materials are fine if they reflect reality
  • Operating reality over official narrative — what actually happens, not what the policy says
  • Boundary signal over volume — knowing what cannot change is as useful as knowing what keeps breaking
  • Honest constraints — hidden constraints discovered mid-engagement create scope problems

If you are unsure whether you have enough to send, send what you have. The fit assessment will determine whether there is sufficient signal to proceed.

what you receive
05 // What you receive the deliverable

A structured document, not a deck.

Every engagement ends with one written artifact. It is designed to be read, circulated internally, and handed directly to the people who need to make decisions or execute against it. It is not a slide deck, a workshop package, or an open-ended memo.

Who it is for

Decision owners who need a single source of structural truth, and builders who need a clear basis for what must change first. Both can use the same document.

What it does

Resolves structural uncertainty, reduces debate about what changes first, supports internal alignment, and provides a stable handoff point for execution teams.

What it is not

Not a slide deck. Not a workshop or facilitation package. Not implementation execution. Not an open-ended advisory retainer. One document. One engagement.

when it is not a fit
06 // When it is not a fit clear refusal logic

Not every problem belongs in this process.

The intake exists to determine whether this approach is appropriate — not to force every problem into the same engagement. If it is not a fit, I say so at the fit assessment stage.

Not a fit when

  • The issue is too broad or undefined for a bounded written intervention
  • The real need is implementation ownership, delivery leadership, or ongoing facilitation
  • The available inputs do not contain enough signal to define a reliable boundary
  • The failure is primarily operational noise rather than a structural problem
  • Multiple unrelated failure modes are being combined into one request
What happens then

If it is not a fit, I say so at the fit assessment stage. There is no charge for this. The point of the intake is to determine whether this approach is appropriate.

If the problem is structurally interesting but outside the defined scope of these engagements, I may be able to point toward a more appropriate route.

after delivery
07 // After delivery what comes next

The engagement ends. The artifact does not.

The artifact is yours to circulate, act against, and use as a stable reference point. The engagement itself is bounded — it does not continue into ongoing advisory, retainer access, or implementation support.

Clarification pass

One minor clarification pass is included after delivery. This covers clarification of the document as delivered — not new analysis, extended scope, or additional research.

When new work is required

If the boundary expands, the problem changes shape, or new analysis is required after delivery, that becomes a separate engagement. Scope creep is not absorbed silently.

How to start the next one

The entry route is always the same. Send a Five-Line Brief, attach anything useful, and I will determine whether there is a fit and where the work should begin.

Before you send the brief

The five-line brief is a fit screen, not the diagnosis itself. I use it to determine whether the problem is structurally diagnosable, whether the work should begin with diagnosis or redesign, or whether the issue is outside scope.

If the failure is one-off, purely technical, or not credibly diagnosable from the available evidence, I will say so.

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

Not ready to send a brief yet? Run a Diagnostic Scan — five questions that surface the structural pattern before you commit to an engagement.