Expose the real structure behind recurring failure.
For systems that keep breaking in the same place under growth, complexity, or organisational scale — the point where more meetings have stopped helping and the real structure needs to be made explicit.
Core purpose: Most systems don’t fail because people are incompetent. They fail because the actual rules, invariants, and enforcement boundaries were never made explicit. This artifact makes them visible in a form builders can act on.
What it answers
- What is this system actually doing — not what it claims to do?
- Which rules are breaking that must not break?
- Where does stated design diverge from operating reality?
- What does that imply builders now need to address?
What you send
The recurring failure pattern, the interfaces involved, and any materials that reflect the current state: diagrams, policies, workflows, notes, contracts, screenshots, or internal documents.
What you receive
One structured diagnostic document for internal decision-making and builder handoff. Decision owners get a single source of structural truth. Builders get a clearer basis for what must change first.
Included
- Clarity on what kind of system you are actually running, and why that matters
- Invariant definition: the rules that must not break
- Enforcement visibility: where those rules live in reality, not only in policy
- Boundary visibility across teams, services, policies, and contracts
- A build map showing structural implications for sequence, interfaces, and transition logic
Define the new boundary and the order of change.
When the failure is already visible but the route to change is still unclear. This engagement defines what must change, where responsibility moves, and in what order implementation can safely begin.
Core purpose: Systems can’t self-correct because the correction logic must be designed upstream of execution. This artifact provides that logic — explicitly sequenced so builders can execute against it instead of inventing design midstream.
What it defines
The target boundary, the transition sequence, the interface changes required, the dependency order, and the explicit constraints that prevent local workarounds from quietly reintroducing the same failure pattern.
What you send
Either the completed Diagnostic document plus current materials, or a clear failure description with known constraints if the need for redesign is already obvious and bounded.
What you receive
One structured redesign document that defines the new operating boundary and the order of change. Builders get a stable sequence to execute against instead of being forced to invent design midstream.
Included
- Boundary redesign
- Transition sequence and dependency order
- Interface and handoff clarification
- Change logic that builders can execute against
- Explicit constraints that prevent drift, workaround logic, or quiet re-coupling
Answer four questions about any system you run or operate inside. The scan surfaces whether the failure is likely structural, and where to look first.
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
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
I do not take engagements outside these boundaries. If the issue is primarily technical, already understood, or not credibly diagnosable from available evidence, I will say so at fit assessment.
Both engagements produce written artifacts. Neither includes delivery ownership, ongoing access, or execution support of any kind.
Not included
- Delivery ownership or program management
- Implementation or build execution
- Org-change programs or transformation leadership
- Ongoing coaching, facilitation, or retainer access
- Stakeholder alignment workshops
This fits when
- Your system keeps failing in the same way under growth or scale
- Your teams are stuck in a policy-versus-reality gap
- Decision owners need structure, not more interpretation
- Implementation is blocked by upstream ambiguity
- Builders are being forced to reinvent design during execution
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.
Send the brief. Five lines plus any relevant material you already have.
I review fit. Diagnosis if the structure is still unclear; redesign if the failure is already visible.
You receive the artifact. One written document built for decision-making and builder execution.
- 01 What keeps going wrong? Describe the failure that keeps returning.
- 02 What is it costing? Describe the cost in money, time, trust, load, delay, or drift.
- 03 Where does it show up? Name the teams, roles, systems, or customer touchpoints involved.
- 04 What has already been tried? List any fixes, workarounds, or decisions already attempted.
- 05 What cannot change? State the non-negotiables, constraints, or conditions that must still hold.
If neither engagement is the right fit, I will say so.
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 analysis deepens, or the problem changes shape after delivery, that becomes a separate engagement. Scope creep is not absorbed silently.
Confidentiality
All materials you share are treated as confidential. The artifact is yours. It is not shared, referenced, or used as a case study without your explicit permission.
This is architecture-led work. The diagnostic logic, structural interpretation, and final recommendations are mine. See the Method page for how AI is used in production.