Symptoms masquerade as causes
The place where pain appears is often far from where it began.
Working draft · Specification v0.3
Understand the system.
Then change it.
A structured way to explain how complex systems produce outcomes—and find the points where intervention has the most leverage.
THE PROBLEM BENEATH THE PROBLEM
Organizations rarely fail for lack of solutions.
They fail because they become certain too early. A visible symptom becomes “the problem.” A plausible story becomes “the cause.” Activity begins before understanding does.
One story crowds out alternatives
The first coherent explanation earns confidence it has not yet earned.
Origins are mistaken for leverage
Where a cause began may not be where the system can best be changed.
THE DIAGNOSTIC GRAMMAR
Seven moves from signal to responsible action.
Every step produces an artifact that can be challenged, revised, and traced.
System context
Within what declared context is this diagnosis valid?
Produces: Primary system · Context · FocusOutcome & manifestations
What happened, and what signals show it?
Produces: Observable outcome · Measurable signalsOrigin network
What interacting contributors made this possible?
Produces: Technical · Human · Organizational originsPropagation
How did effects move through the system?
Produces: Physical · Informational · Organizational pathsEvidence & confidence
What supports this explanation—and what contradicts it?
Produces: Evidence · Gaps · ConfidenceControl points
Where can we most effectively influence what happens next?
Produces: Ranked points of leverageDiagnostic sufficiency
Do we understand enough for the next responsible action?
Produces: Act · Investigate · ReframeHOW TO USE EDF
Start small. Make the reasoning visible.
A useful diagnosis is the smallest evidence-backed model that supports the next responsible action.
One local issue.
Low disagreement.
Use a quick card when evidence is direct and one action can safely test the explanation.
Example: a conference-room light will not turn on.Several explanations.
Consequences matter.
Make alternatives, evidence, unknowns, and control-point ranking explicit.
Example: a cooling system hums but does not start.Interacting systems.
Distributed control.
Map technical, human, organizational, and contextual origins.
Example: aircraft design, certification, training, and safety.- 01
Frame the system
Name the primary system, larger context, and narrow focus.
“Checkout flow, within the mobile storefront, focused on payment completion.”
- 02
State the outcome
Write what happened without causal language, blame, or a proposed fix.
“Payment completion fell from 71% to 54% after Tuesday’s release.”
- 03
Build competing explanations
List interacting origins and trace how each could reach the manifestation.
“SDK change → timeout → retry loop → abandoned checkout.”
- 04
Test with evidence
Record support, contradiction, source quality, and unknowns.
“Logs support timeouts; web checkout did not decline.”
- 05
Rank control points
Compare influence, controllability, cost, and confidence.
“Rollback outranks retraining: faster, reversible, directly testable.”
- 06
Check sufficiency
Ask whether you know enough for the next responsible action.
“Yes for rollback; no for declaring the incident fully explained.”
THREE SCALES · ONE GRAMMAR
See what a finished diagnosis looks like.
The fields stay stable as complexity grows. The evidence burden and origin network expand.
Conference-room lighting
- Outcome
- Lights did not turn on during use.
- Evidence
- A replacement bulb restored lighting.
- Origin → path
- Failed bulb → no illumination.
- Control
- Replace the bulb.
Residential cooling startup
- Outcome
- Temperature stayed above target.
- Evidence
- Unit hummed; capacitor measured out of range.
- Origin → path
- Failed capacitor → motor did not start → no cooling.
- Control
- Replace capacitor, then verify startup.
Apollo 11 success
- Outcome
- The mission landed and returned safely.
- Origins
- Engineering rigor, testing culture, clarity, integration.
- Propagation
- Clear goals and testing shaped design and execution.
- Control
- Preserve testing discipline.
WORKED EXAMPLE · CHALLENGER
The O-ring failed. The diagnosis cannot stop there.
“O-ring failure” identifies a physical origin. It does not explain why known warning signals failed to stop the launch.
EVIDENCE, NOT CERTAINTY THEATER
What the research supports—and what it does not yet.
EDF separates public claims by evidence state. The framework is frozen at v0.3 while validation continues.
One grammar can analyze failure and success
Challenger, Boeing, Apollo 11, Pixar, and Toyota produced comparable structures.
EDF improves control-point identification
Multiple cases support the claim; quantitative scoring is still needed.
EDF scales to everyday operational problems
A simple case is encouraging, but more testing is required.
Known limitation. Results remain provisional until tested with independent human analysts. Speed, learning curve, visualization, and quantitative metrics are active gaps.
YOUR FIRST EDF–0
Before proposing a solution, write down what you actually know.
01 · SYSTEM CONTEXT Primary system · larger context · narrow focus
02 · OUTCOME What happened—without interpretation?
03 · ORIGIN + PATH What contributed, and how did the effect travel?
04 · EVIDENCE What supports, contradicts, or remains unknown?
05 · CONTROL Which intervention offers the best leverage?
06 · SUFFICIENCY Do you know enough for a responsible, testable action?