Epistemic Stability Framework: 5 Techniques Against LLM Hallucinations — No Fine-Tuning, No Complex Infrastructure

All five are separate prompt strategies. You can use them independently or combine them.

M4: Enriched Data Registry (the most effective)
  Step 1: Add 6 metadata fields to every data record
          → what it is, normal range, fault threshold, dependencies, implications, units
  Step 2: Give the enriched data + the question in one prompt
          → An answer grounded in clear context, not guesswork

M3: Chain of Specialized Agents
  Agent 1: Root cause analysis only → output
  Agent 2: Severity assessment only (receives A1 output) → output
  Agent 3: Remediation plan only (receives A1+A2) → output
  Agent 4: Final report only (receives everything) → final document
  [Each agent = a separate LLM request]

M5: Glossary Injection
  Step 1: At the start of the prompt, define every term and abbreviation
          → strict, unambiguous interpretation
  Step 2: Give the task
          → An answer without ambiguous readings of terms

M1: Iterative Convergence
  Step 1: Generate a first answer
  Step 2: Generate a second answer to the same prompt
  Step 3: Compare — are they similar enough?
          → If yes: return the latest answer
          → If no: repeat (up to 5 iterations)

M2: Decomposition (extraction → synthesis)
  Step 1: Extract only the facts from the complex request → a structured list
  Step 2: Synthesize an answer only from the extracted facts → final answer
  ⚠️ The naive version is worse than a direct request. It only works with the right extraction format.

Task: You're the founder of a small mobile game studio. There's an incident — after an app update, your App Store rating dropped from 4.7 to 3.9 in three days. Complaints about crashes, lost progress, freezes. You need to figure out what happened, how critical it is, what to do and how to explain it to the team.

We apply M3 — a chain of four specialized agents.

**Request 1 — Root cause agent:**

You are a mobile app incident analysis specialist. 
Your only task: find the root cause of the incident.

Incident: After update v2.4.1 at 2:00 PM Friday, the app "PixelQuest" 
received within 72 hours: 847 one- and two-star reviews (vs ~30/week before), the rating dropped 
from 4.7 to 3.9, crash rate rose from 0.3% to 4.1%, crashes on the loading 
screen are mentioned in 60% of negative reviews, lost progress in 25%.

Perform ONLY the root cause analysis. No recommendations.
Format: 
- Most likely root cause
- Confidence level (high/medium/low) and justification
- What needs to be verified

---

**Request 2 — Severity assessment agent:**
[paste Agent 1's output]

You are a risk management specialist. Your only task: 
assess the severity of the incident.

Based on the analysis above, assess ONLY severity and urgency.
Format:
- Criticality level (critical/high/medium/low)
- Business risks over the next 7 days if nothing is done
- What will happen to the rating if nothing is done

---

**Request 3 — Remediation plan agent:**
[paste the outputs of Agents 1 and 2]

You are the CTO. Your only task: write a remediation plan.

Based on the analysis above, write ONLY an action plan.
Format:
- Actions in the next 2 hours
- Actions within the day
- Actions within the week
- Success metrics for each stage

---

**Request 4 — Final report agent:**
[paste the outputs of Agents 1, 2 and 3]

You are the head of communications. Your only task: 
write an internal post-mortem report.

Based on all the analyses above, write only the final document for the team.
Format: cause → consequences → plan → lessons for the future.
Tone: honest, no panic, action-oriented.

Result: Four separate answers — each focused and specific. Agent 4 gets structured input from the first three instead of trying to be a detective, a risk manager and a CTO all at once. An error in the first step won't drag down the whole document. The final post-mortem will rest on explicitly recorded conclusions, not guesswork.

An LLM is optimized for the "statistically plausible next token", not for "the right answer for this specific case"**. That's a fundamental difference. When you give it a complex multi-part question, the model tries to satisfy every requirement at once — and quietly "drops" some of them without warning. Structurally the answer looks complete. In reality it isn't.

An LLM's strength is working with explicitly structured context. If instead of a raw {"id": "CHW-V-01", "state": 100} you give {"id": "CHW-V-01", "state": 100, "normal_range": "20–80%", "fault_implication": "not enough cooling in the system"}, the model doesn't need to "guess" what the value 100 means. The context already holds the answer. The model's job shrinks from "guess what this means" to "read and apply".

The methods use this strength in different ways: - M4 eliminates information starvation at the input — the model doesn't invent context - M3 eliminates multitasking — no agent can "forget" its task, because it only has one - M5 eliminates term ambiguity — a word always means one specific thing - M1 uses instability as a signal — if two answers differ, the model doesn't know; we look for the moment it "makes up its mind"

Control levers: - Number of agents in M3 — you can add a "Reconciler" agent that reads all the outputs and resolves contradictions - Metadata fields in M4 — add only the ones that actually change the interpretation; the authors tried 20 fields and kept the 6 most influential - Glossary in M5 — make it dynamic: inject only the terms relevant to the specific request - Similarity threshold in M1 — the higher it is (85%), the stricter the stability criterion; lower it to 70% for creative tasks

M4 — Enriched Data Registry (universal template)

Before answering, study the enriched data below. 
Each record contains not only a value but also the context needed to interpret it.

=== DATA ===
[
  {
    "parameter": "{parameter_name_1}",
    "value": "{current_value_1}",
    "normal": "{normal_range_1}",
    "alarm_threshold": "{when_it_is_a_problem_1}",
    "depends_on": ["{related_parameter_1}"],
    "if_deviation": "{what_it_means_for_the_task_1}",
    "unit": "{unit_of_measure_1}"
  },
  {
    "parameter": "{parameter_name_2}",
    "value": "{current_value_2}",
    "normal": "{normal_range_2}",
    "alarm_threshold": "{when_it_is_a_problem_2}",
    "depends_on": ["{related_parameter_2}"],
    "if_deviation": "{what_it_means_for_the_task_2}",
    "unit": "{unit_of_measure_2}"
  }
]
=== END OF DATA ===

Task: {question_or_task}

Base your answer only on the data above. 
If the data is insufficient, state explicitly what information is missing.

What to fill in: - {parameter_name} — a metric, indicator or table field - {current_value} — the actual number or status right now - {normal} — what counts as normal for this metric in your context - {alarm_threshold} — at what value it becomes a problem - {depends_on} — what affects this metric or what it drives - {if_deviation} — what a deviation from normal means in your task - {question_or_task} — what you need to find out or do

M3 — Agent chain (template for 4-step tasks)

=== AGENT {number}: {specialization} ===

You are a {specialist_role}. 
Your ONLY task: {one_specific_task}.

{if_not_the_first_agent: Context from previous agents:
[paste the outputs of the previous agents]}

Input data: {situation_description}

Perform ONLY {one_specific_task}. 
Do not {what_this_agent_should_NOT_do}.

Output format:
- {field_1}: ...
- {field_2}: ...
- {field_3}: ...

What to fill in: - {specialization} — root cause analysis / risk assessment / action plan / final report - {specialist_role} — detective, risk manager, CTO, editor - {one_specific_task} — strictly one, no "and also" - {what_NOT_to_do} — explicitly forbid what the other agents do

M5 — Glossary Injection

=== GLOSSARY: use these definitions throughout your answer ===
{term_1} — {clear_definition_in_your_context}
{term_2} — {clear_definition_in_your_context}
{abbreviation_1} — {expansion_and_context}
=== END OF GLOSSARY ===

{main_request}

🚀 Quick start — paste into the chat:

Here's the M4 template (Enriched Data Registry). 
Adapt it to my task: {describe the task}. 
Ask me questions to fill in all the fields.

[paste the template above]

The LLM will ask about your data: what each parameter means, what counts as normal, what counts as a failure — because without that the "normal" and "if_deviation" fields will be empty, and that's where all the power of the method lives.

⚠️ M3 needs several requests in a row: Four agents means four separate chat messages. You have to copy each output into the next one. For long chains it's tedious, but doable by hand.

⚠️ M4 requires prep work: You have to know what "normal" and "alarm threshold" mean for your data. The LLM won't guess — that knowledge comes from the domain. If you don't know the norms yourself, the method won't help.

⚠️ M1 multiplies token usage: Each iteration is a new request. With 5 iterations you spend 5 times as much. On free accounts you may hit the limits.

⚠️ M2 in its naive version is worse than a direct request: The authors got 34% on the first try. "Just split it into parts" doesn't work. You need to strictly control the fact-extraction format before synthesis.

⚠️ No technique guarantees correctness: All the methods improve stability and consistency, not truth. If the data has an error, the model will faithfully reproduce the error.

⚠️ Results were also judged by an LLM: The researchers used the same model as the judge. That creates a risk of "circular evaluation" — the model approves its own patterns. The authors openly admit this.

Engineers at Trane Technologies (a maker of climate control systems) ran into real problems in production systems: HVAC diagnostics gave different answers to the same question, abbreviations were interpreted differently across sessions, complex prompts lost requirements. They took five techniques, each attacking one specific cause of hallucinations, and ran each one 100 times on a fixed prompt at temperature 0.7 (deliberately high, to preserve stochasticity and honestly measure variability).

The judge was the same model (Azure OpenAI, presumably GPT-4o or newer). That's a limitation, but the authors acknowledge it openly. Here's what's interesting: M2 flopped at 34% in its first version — worse than a plain direct request. It's a rare case of a study honestly showing "the idea didn't work as intended" and digging into why. It turned out that just splitting a complex prompt into "fact extraction → synthesis" isn't enough — you need to strictly format the facts and explicitly link the steps. After the rework, M2 v2 rose from 34% to 80% — the biggest jump of any method.

The most unexpected result is M4 scoring 100/100. That's a total win, rarely seen in studies like this. The explanation is simple: the model wasn't guessing what state: 100 means for a valve — it was reading "normal: 20-80%, value 100 = valve fully open = not enough cooling". The information was in the prompt; there was nothing left to hallucinate.

M4 — Enhanced Data Registry (verbatim from the paper):

Example row (raw): {"id": "CHW-V-01", "state": 100}

Example row (enriched): {
  "id": "CHW-V-01", 
  "state": 100, 
  "component_type": "chilled water supply valve", 
  "normal_range": "20–80%", 
  "fault_threshold": ">95% for >5 min", 
  "depends_on": ["CHW-PUMP-01"], 
  "fault_implication": "chiller plant starved; warm air downstream", 
  "units": "%"
}

Context: The researchers were testing HVAC system diagnostics. A raw record is just an ID and a number. An enriched record tells the whole story: what it physically is, when it's normal, when to raise the alarm, what happens next.

M3 — Single-Task Agent Chain (algorithm structure):

Input: Incident scenario I
Output: Post-mortem report R_pm

1: c ← RootCauseAgent(I)
2: s ← SeverityAgent(I, c)
3: r ← RemediationAgent(I, c, s)
4: R_pm ← PostMortemAgent(I, c, s, r)
5: return R_pm

Context: It was tested on an ERP incident with six simultaneous symptoms: connection pool exhaustion (500/500), App Server 2 memory at 97% with a forced kill, cascading timeouts across six microservices, three failed overnight jobs, 100% CPU for 18 minutes, and a 40x traffic spike on one node.

1. M4 for analyzing financial statements

You send the model a P&L — it sees rows of numbers. Without context, "$230K revenue against a $300K plan" is just a fact. With context, it's an alarm signal.

💡 Adaptation for financial analysis:

=== REPORT DATA (enriched) ===
[
  {
    "parameter": "Revenue, November",
    "value": "$230,000",
    "normal": "$280,000 – $320,000 (planned range)",
    "alarm_threshold": "below $250,000 — threatens operating liquidity",
    "depends_on": ["Number of new customers", "Average order value", "Churn"],
    "if_deviation": "Not enough to cover payroll without tapping working capital",
    "unit": "USD"
  },
  {
    "parameter": "Customer churn",
    "value": "8.2%",
    "normal": "Up to 4% per month",
    "alarm_threshold": "above 7% — a systemic problem with the product or service",
    "depends_on": ["Last quarter's NPS", "Support complaints"],
    "if_deviation": "ARR loss is accelerating; critical mass within 2 months",
    "unit": "%"
  }
]
=== END OF DATA ===

Task: What's happening with the business? What are the three biggest risks over the next 60 days?

2. M5 + M3 together: a glossary for the first agent

🔧 Technique: glossary → agent chain

Insert the M5 glossary before the first agent. Each subsequent agent inherits the definitions through the context. That way a word means one thing across the whole chain — interpretation errors don't pile up from agent to agent.

=== PROJECT GLOSSARY (for all agents) ===
"deadline" — the date the feature must be in production, not in staging
"critical bug" — a bug that blocks payment or sign-up
"stakeholder" — only Alex Miller and Maria Lopez, not the whole team
=== END OF GLOSSARY ===

=== AGENT 1: Root cause analysis ===
[then the standard M3 template]

3. M1 as a cheap check on an important decision

💡 Adaptation for checking important conclusions:

Instead of an automated loop — a manual version of M1. Ask the same question twice in different wordings. If the answers differ a lot, the model "doesn't know" and can't be trusted. If they match, it's a stable signal.

Question 1: What are the three biggest risks of entering the Brazilian market?

[in a new request]

Question 2: If we're planning to expand into Brazil, what could go wrong? 
Name three failure scenarios.

Compare the lists by hand. If they overlap — trust it. If they're completely different — dig deeper or give it more specific context.

Main paper: Toward Epistemic Stability: Engineering Consistent Procedures for Industrial LLM Hallucination Reduction — Brian Freeman, Adam Kicklighter, Matt Erdman, Zach Gordon. Trane Technologies, Davidson NC, USA. March 2026. [email protected]

Key works cited: - Wang et al. (2023) — Self-Consistency: majority voting across multiple reasoning paths - Wei et al. (2023) — Chain-of-Thought prompting - Madaan et al. (2023) — Self-Refine: iterative improvement of a draft - Lewis et al. (2021) — RAG (Retrieval-Augmented Generation) - Wu et al. (2023) — AutoGen: multi-agent frameworks