The method begins with a decision
A predefined solution assumes the problem category is already known.
The diagnostic begins by naming the decision that has become late, unclear, unreliable, or disconnected from consequence. Without an affected decision, the work has no useful boundary.
1. Frame the condition
Recognition establishes the visible pain, who carries the consequence, and why the affected decision matters now.
The visible pain is treated as a starting signal, not as proof of the cause.
2. Reconstruct current reality
This is not a theoretical process diagram. It looks at people, process, systems, handoffs, decisions, exceptions, reports, informal knowledge, workarounds, and repeated corrections.
The aim is to understand how the relevant work actually moves and where the official description stops matching reality.
3. Trace the knowledge spine
The diagnostic follows the signal into context, decision, action, and learning. It asks where knowledge is created, translated, delayed, simplified, or lost.
This makes the break visible across strategy, people, process, technology, and value flow rather than assigning it to one tool too early.
4. Name the intelligence break
A break may mean that signal is not captured, data lacks context, context does not reach the decision, action comes too late, or the outcome never returns as learning.
The method must name which break affects which decision.
5. Define proof before form
Before a large solution is designed or implemented, the diagnostic should clarify what would prove that the direction is correct.
The useful next step may be a decision brief, a redesigned handoff, a working prototype, an analysis cycle, or another bounded proof. The form is chosen only after the break and the proof are clear.
6. Produce an owner decision
The diagnostic deliverable records the condition examined, the supported break, the affected decision and consequence, the proof required, and the justified direction of intervention.
It does not automatically become an implementation blueprint. It gives the owner a basis to stop, make a bounded change, or authorize a separate design and build phase.
The operating principle
Price the diagnosis. Do not pre-price the cure.
The diagnostic can have clear scope, timeframe, output, and fee. A later solution should not be priced before the condition is understood.
That boundary is the condition for doing the work responsibly.
For the role of knowledge across the method, read When the Business Stops Learning in Time.
For concrete examples of domains where diagnosis can lead, read Where Diagnosis Can Lead.