The AI Model Diagnostic Framework
“Diagnose before you retrain. The most expensive fix in AI is the one that solves the wrong problem.”
This framework combines three proven methodologies into a sequential diagnostic process for AI model performance issues. It is designed for AI leaders, transformation advisors, and program managers who need to diagnose problems without being data scientists.
Use this framework every time someone says “the model is wrong” — before agreeing to any fix.
How to use this framework
Layer 1 first — the horizontal scan — maps the full problem landscape before going deep. Then Layer 2 — the 5 Whys vertical drill — finds the true root cause. Then Layer 3 — the Design Thinking check — ensures your fix will actually be adopted.
The most important rule: complete all three layers before recommending any fix. The most expensive mistake in AI diagnostics is solving the wrong problem — and the wrong problem almost always looks like the right problem at Layer 1.
Layer 01 — The horizontal scan
Who What When Where Why How — map the full landscape before you drill
Before you diagnose anything you need a complete picture of the situation. Without this scan you risk running the 5 Whys on the wrong symptom.
WHO — Who is affected?
- Which users or teams are experiencing the problem?
- Is it everyone or specific groups only?
- Who reported it first and when?
- Who owns the system — technically and operationally?
- Who are the downstream recipients of the wrong outputs?
WHAT — What exactly is happening?
- What type of wrong answer — confidently wrong, outdated, vague, inconsistent, or discriminatory?
- What is the model being asked to do?
- What does a correct answer look like?
- What has already been tried to fix it?
- What is the business impact of the wrong answer?
WHEN — When did it start?
- When did the wrong answers first appear?
- Was onset sudden or gradual?
- When does it happen — always, intermittently, at specific times?
- What changed in the business or environment around that time?
- When was the model last updated or retrained?
WHERE — Where in the system?
- Where in the workflow does the wrong answer appear?
- Is it isolated to one business unit or system-wide?
- Where does the model get its information from?
- Where is the knowledge base stored and who manages it?
- Where does the output go after the model generates it?
WHY — Why does it matter?
- Why is this output consequential — what decisions does it inform?
- Why are users relying on this output without verification?
- Why hasn’t it been fixed already?
- Why does the team believe retraining is the solution?
- Why was the system designed this way originally?
HOW — How is it manifesting?
- How often does it happen?
- How is the wrong answer different from the correct one?
- How is the model currently monitored?
- How were users trained to use the system?
- How confident does the model appear when it gives wrong answers?
Layer 1 output: After the horizontal scan you should be able to answer how many distinct problem types are present, who is affected by each, and what pattern the timing and location suggest. If you have more than one distinct symptom — run Layer 2 separately for each one. Do not combine them.
Layer 02 — The 5 Whys vertical drill
Ask why five times — each answer becomes the input to the next question
The 5 Whys is a root cause analysis technique from lean manufacturing adapted here for AI model diagnostics. The principle: the first answer is almost never the real cause. Most organisations stop at Why 2 or Why 3 and fix the symptom. The true root cause is almost always at Why 4 or Why 5.
Run the 5 Whys separately for each distinct symptom identified in Layer 1.
Example 1 — Stale knowledge symptom
| Why | Question | Answer |
|---|---|---|
| Why 1 | Why did the rep give wrong information? | Because the model said the discount was valid. |
| Why 2 | Why did the model say it was valid? | Because the knowledge base contained the old policy. |
| Why 3 | Why was the old policy still there? | Because nobody had updated it when the policy changed. |
| Why 4 | Why had nobody updated it? | Because there was no defined process for keeping the knowledge base current. |
| Why 5 | Why was there no process? | Because knowledge base governance was never assigned to anyone. Nobody owned it. |
True root cause: Governance problem. No ownership. No update process. Fix direction: Assign ownership, define update cadence, implement RAG with live documents.
Example 2 — Vague results in different business unit
| Why | Question | Answer |
|---|---|---|
| Why 1 | Why were the answers vague? | Because the model wasn’t giving specific, actionable responses. |
| Why 2 | Why wasn’t it specific? | Because it wasn’t retrieving the right documents for this unit’s queries. |
| Why 3 | Why not the right documents? | Because the reps were using different terminology than the original unit. |
| Why 4 | Why different terminology? | Because the model was optimised for one business unit’s language only. |
| Why 5 | Why deployed without adjustment? | Because the deployment assumed the model was generic when it was domain-specific. |
True root cause: Deployment assumption problem. Not a model quality issue. Fix direction: Domain-specific prompt layer, terminology mapping, separate knowledge base per unit.
Example 3 — Rate answers intermittently wrong
| Why | Question | Answer |
|---|---|---|
| Why 1 | Why were rate answers sometimes wrong? | Because the model was returning outdated rates. |
| Why 2 | Why outdated? | Because rate data in the knowledge base wasn’t being updated when rates changed. |
| Why 3 | Why wasn’t it being updated? | Because rate data was treated as static content. |
| Why 4 | Why treated as static? | Because the architecture didn’t distinguish stable from time-sensitive information. |
| Why 5 | Why was that distinction not made? | Because nobody assessed information volatility during the design phase. |
True root cause: Architecture and design problem. Retraining would not have fixed this. Fix direction: Connect to live data source, classify information by volatility, separate static from dynamic layers.
Symptom to root cause quick reference
| Surface symptom | Likely root cause at Why 4-5 | Fix direction |
|---|---|---|
| Confident wrong answers | No grounding — model using memory not documents | RAG implementation |
| Outdated information | No knowledge base ownership or update process | Governance and process |
| Accuracy declining over time | Concept drift — real world changed, model didn’t | Retraining + monitoring |
| Vague or unhelpful answers | Domain mismatch — wrong knowledge base for this user | Prompt and retrieval layer |
| Different outcomes for same inputs | Historical bias encoded in training data | Fairness audit + legal escalation |
| Works in testing, fails in production | Test data not representative of real users | Test set redesign |
| Inconsistent answers | Temperature too high or no grounding | Configuration + RAG |
The 5 Whys rule: If your Why 5 answer still sounds like a technical fix — you have not gone deep enough. The true root cause is almost always a governance gap, ownership gap, design assumption, or process failure — not a model failure.
Layer 03 — The Design Thinking check
Desirability · Usability · Feasibility · Viability — ensure your fix will actually be adopted
This is the layer that purely technical diagnostics miss. A model can be technically correct and still fail — because users have stopped trusting it, the fix creates more friction than it removes, or the business case doesn’t justify the cost.
Apply all four dimensions to your proposed fix before recommending it.
Desirability — Will people actually want to use it?
- Do users trust the model enough to use the fix?
- Has previous failure damaged adoption? How do we rebuild trust?
- Does the fix align with how users actually work?
- Have users been involved in designing the solution?
- What does success look like from the user’s perspective?
Usability — Can they use it without friction?
- Does the fix add steps to the user’s workflow?
- Is the output format usable in the context where it appears?
- Do users need training to use the fixed system?
- Is there a fallback when the model is uncertain?
- Can users provide feedback when something is wrong?
Feasibility — Can it technically work?
- Is the data available and clean enough for the fix to work?
- Does the team have the skills to implement it?
- Can it be implemented in a timeframe that matters?
- Does it integrate with existing systems?
- Can it be tested before full deployment?
Viability — Does it make business sense?
- What is the cost of the fix vs the cost of the problem?
- Does it create ongoing maintenance burden?
- What is the ROI timeline?
- Does it comply with regulatory requirements?
- Is it sustainable as the AI programme scales?
The adoption warning: If users have already lost trust in the tool — the technical fix alone will not restore adoption. You need a trust-rebuilding plan alongside the technical fix.
The diagnostic sequence — quick reference
- Resist the instinct to fix. The first recommended fix is almost always wrong. Gather facts before prescribing solutions.
- Run the horizontal scan. Map the full problem landscape. Identify how many distinct symptoms are present.
- Run 5 Whys separately for each symptom. Do not combine symptoms. Each one may have a completely different root cause.
- Keep asking until you reach a human decision. The true root cause is almost always a governance gap, ownership gap, design assumption, or process failure — not a model failure.
- Apply the Design Thinking check to your proposed fix. All four dimensions must pass.
- Recommend immediate AND structural fix. The immediate fix stops the bleeding. The structural fix prevents recurrence.
- Flag the regulatory implication. In financial services every model performance issue has a potential regulatory dimension — FCA, CFPB, DORA, SR 11-7. Name it explicitly.
Rashmi Mittal is an AI Transformation & Product Leader with 15+ years in financial services. This framework was developed from real enterprise AI engagements — it is designed to be used, not just read. 🌐 futureempowered.com
#AITransformation #AIDiagnostics #ModelPerformance #DesignThinking #5Whys #EnterpriseAI #AIGovernance #FutureEmpowered
