Make the architecture beneath a problem, system, method, or body of work explicit.
Best when you know the domain but need a clean structural read of what it is actually built on.
The Lens Brief is for situations where the immediate problem is not yet “why does this keep failing?” but “what is the underlying architecture here?” It extracts the structure so the domain can be reasoned about clearly.
What it answers
What is this system or body of work actually organised around? Which functions matter? Where are the real boundaries and dependencies? Which tensions are structural rather than incidental?
What you send
The problem, system, method, or body of work you want made legible, plus the source material needed to understand it. A recurring failure is not required.
What you receive
A 6–10 page PDF naming the underlying architecture, principal functions, boundaries, dependencies, and structural tensions in plain enough language to circulate and use.
Boundary of the brief
- Architecture extraction, not a full governing failure diagnosis
- No complete enforcement map or diagnostic classification unless required to explain the architecture
- No redesign specification or migration sequence
- Complete standalone artifact — not paid discovery and not a mandatory precursor to a Diagnostic Artifact
Expose the real structure behind recurring failure.
Best when the immediate need is a single structural read.
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. The fixed fee reflects the bounded scope and the upstream diagnostic rigour required to produce a structural read that holds.
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 is the first structural break, and what does it imply must change first?
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.
For some public platforms and institutions, externally visible failure patterns may be enough to begin diagnosis. Internal access is preferred where available, and required where the failure is not externally observable. This is particularly relevant for platforms and institutions where contributor or user failure patterns are documented in the public domain.
What you receive
One structured diagnostic document — a single structural read, internally circulable, and decision-ready. Decision owners get a common reference point that ends interpretation drift. Builders get a clear basis for what must change first, without having to invent design midstream.
What the artifact makes explicit
- The primitive: what the system is actually organised to do, not what it claims to do
- 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
- The governing diagnosis — the central structural truth from which the rest of the failure follows, written so decision-makers can circulate it and builders can act against it
- A build map showing structural implications for sequence, interfaces, and transition logic
£25,000 includes the complete four-artifact set for most systems: Translation Artifact, Diagnostic Artifact, Redesign Executive Summary, and Full Redesign Artifact. No hourly rates.
Diagnose the structural break, then define the new boundary and order of change.
One governed engagement, one diagnostic frame, one change sequence.
Best when the failure is serious enough that naming it is not sufficient — and leaving builders without a change sequence would simply restart the cycle.
When the failure is serious enough that naming it and defining the change sequence should happen in one governed engagement.
The standard fixed fee is £25,000. If the system is unusually large — multiple institutions, dozens of interfaces, or high-consequence redesign — I will scope separately and provide a tailored quote during fit assessment.
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. Two companion documents — the Translation Artifact and the Redesign Executive Summary — ensure the work is accessible to non-specialist decision-makers and can circulate internally without the full restricted specification changing hands.
What you send
The same five-line brief. The Diagnostic Artifact is delivered first. After its clarification pass, the diagnostic frame is confirmed in writing before the redesign artifacts are released — keeping all four artifacts coherent by construction.
What you receive
Four linked written artifacts delivered as one governed sequence: a Translation Artifact (shared language layer for leadership, operations, and non-specialist audiences), a Diagnostic Artifact (structural diagnosis, governing diagnosis, and build map), a Redesign Executive Summary (board-level public summary of the restricted specification, designed to circulate internally and externally), and a Full Redesign Artifact (corrected primitive, transition sequence, dependency order, refusal invariants, recapture gates, and builder handoff).
Structural outputs
- Translation Artifact — shared language layer ensuring leadership, operations, and non-specialist teams have a common structural read before builders begin
- Redesign Executive Summary — board-level public summary of the restricted specification, designed to circulate without exposing the full builder specification
- 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
Fixed scope. Fixed fee. Fixed timeline. How it works →
A governed production sequence — not subjective consulting.
The amount of diagnostic machinery depends on the service. A Lens Brief extracts architecture. A Diagnostic Artifact classifies and locks the governing break. Full Structural Engagement carries that locked diagnosis into redesign. AI can assist drafting and production; it does not determine the governing diagnosis or correction order.
Stops at architecture extraction. It does not need a recurring failure or full diagnostic classification.
Runs through classification and governing diagnosis. Stops when the structural failure has been named completely.
Uses the same diagnostic frame to produce the Translation Artifact, Diagnostic Artifact, Redesign Executive Summary, and Full Redesign Artifact. The Diagnostic Artifact is delivered first; redesign is released after that frame is confirmed.
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.
All three engagements produce fixed-scope written artifacts. None includes delivery ownership, ongoing access, or execution support.
Not a strategy deck
These are not vision documents, workshop outputs, or open-ended advisory reports. They are structural reads built to govern action.
- No workshops or facilitation
- No transformation programmes
- No ongoing coaching or retainer access
- No delivery ownership or program management
- No code audits or technical root-cause analysis
Not implementation support
The artifact defines what must change and in what order. Execution is yours. The artifact makes that execution possible without reinventing design midstream.
- No implementation or build execution
- No architecture or infrastructure work
- No live incident response
- No security or compliance audits
- No open-ended advisory without defined scope
- No partial artifact delivery — the Full Structural Engagement is delivered as a complete four-artifact governed sequence, not as individual components on separate request.
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
Structural fit examples
- A platform that recruits one kind of worker but operationally runs on a different capability profile — resulting in persistent mismatch, routing failure, and accumulated workaround logic
- A healthcare system in which continuity is nominally the institution's responsibility but is actually held by families and frontline staff outside the formal record
- A product team in which every sprint produces fixes that do not hold, because the structural rule governing the failure has never been named
- An organisation in which builders are inventing design decisions during implementation because the upstream architecture was never resolved
I do not take engagements outside these boundaries. If the problem is primarily technical, already understood at the structural layer, or not credibly diagnosable from available evidence, I will say so at fit assessment rather than deliver work that would not hold under scrutiny.
Choose the simplest entry route. Request a Structural Lens when you need architecture extracted. Send the Five-Line Brief when you have a recurring failure. Or contact me directly if you are not sure.
I review fit and scope. I confirm whether the work belongs in a Lens Brief, Diagnostic Artifact, Full Structural Engagement, or nowhere in this practice. Redesign never bypasses diagnosis.
You receive the agreed written artifact. Scope, fee, delivery window, inputs, and endpoint are fixed before work begins.
- 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 the work is not the right fit, I will say so.
Clarification pass
One minor clarification pass is included for each applicable delivery stage. This covers clarification of the document as delivered — not new analysis, extended scope, or additional research.
For the Full Structural Engagement, one clarification pass applies to the Diagnostic Artifact and one to the Full Redesign Artifact. The Translation Artifact and Redesign Executive Summary are derived from those locked frames and do not require separate clarification passes.
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.
In the Full Structural Engagement, the Diagnostic Artifact is delivered first. Redesign is released only after the diagnostic frame is confirmed in writing.
The Full Structural Engagement remains a 14-day engagement window, subject to timely client inputs and diagnostic confirmation. If client-side delay prevents timely confirmation of the diagnostic frame, final redesign release may extend beyond day 14. If the diagnosis shows that redesign is not valid within the engagement boundary, I will say so rather than release a speculative artifact.
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.