There’s a version of retrieval-augmented generation that demos beautifully and fails quietly. You point a language model at your documents, it retrieves some relevant chunks, and it writes a fluent answer. In a boardroom that looks like magic. In production, on data where a wrong number changes a decision, it’s a liability — because the model is still free to compute, infer, and smooth over gaps in ways nobody can see.
For high-stakes data — clinical, financial, program-outcome — you need something more disciplined. The pattern worth knowing is supervised RAG: retrieval-augmented generation where the model’s job is to understand and route, not to calculate. The actual numbers come from verified data sets, predefined indicators, and known formulas. The model orchestrates; verified services do the arithmetic.
This isn’t theoretical. There’s a public, well-documented example worth studying.
A real system: glAIser at EGPAF
The Elizabeth Glaser Pediatric AIDS Foundation works to end pediatric HIV across a dozen high-burden countries, drawing on data from more than 18 million patients served. In a Microsoft-published customer story, the foundation — working with Microsoft and partner Squadra Digital — describes an AI assistant called glAIser, built to let staff query that data in plain language.
The architecture is the interesting part, and it’s a clean illustration of supervised RAG. According to the published account, the language model interprets a user’s prompt and translates it into a structure it can use to match against the correct data sets, global-health indicators, and the formulas used to calculate specific measurements. It then routes to one of a suite of agents to query the aggregated data, chosen by the intent and context of the question — with grounding guardrails in place to prevent hallucination before a response is generated.
Read that again with the design principle in mind. The model is not asked “what is the HIV testing rate?” and left to produce a number. It is asked to recognize that the question maps to a specific indicator, with a specific formula, computed over a specific verified data set — and to route there. The measurement is a lookup and a calculation performed by trusted code, not a generation. That single distinction is what separates a system you can put in front of a clinician from one you can only put in front of a demo audience.
Why “route, don’t compute” is the whole game
Ordinary RAG fails on high-stakes data in three predictable ways, and supervised routing addresses each.
The model answers from the wrong context. Generic retrieval returns plausible-but-irrelevant chunks, and the model confidently synthesizes from them. Supervised RAG narrows the problem: instead of retrieving free text and hoping, the model maps the question to a known indicator. Either the question resolves to a defined measurement or it doesn’t — and “it doesn’t” is a far safer failure than a fluent wrong answer.
The model does math it shouldn’t. Language models are pattern generators, not calculators; asking one to compute a rate across disaggregated records is asking for a number that looks right and occasionally isn’t. Supervised RAG removes the temptation entirely — the formula is predefined and executed by code, and the model never touches the arithmetic. In the glAIser example, the formulas used to calculate measurements are part of what the prompt is matched against, not something the model improvises.
Every answer looks equally authoritative. When output is pure generation, a solid figure and a hallucinated one arrive in the same confident tone. When answers are grounded in a specific indicator computed over a specific data set, the provenance is structural — you can point at where the number came from, which is exactly what a decision-maker needs before acting on it.
What this costs (the honest part)
Supervised RAG is not free magic, and pretending otherwise sets up the same disappointment as over-promising on plain RAG. The cost is curation. Someone has to define the indicators, encode the formulas, map the data sets, and decide what a valid question even is. The intelligence that makes the system trustworthy lives in that upfront library of verified measurements — not in the model.
That’s a feature, not a bug, for the kind of organization that should be using this pattern. If your indicators are already defined — as they are in most health programs, donor-reporting frameworks, and financial systems — you’re not inventing them, you’re encoding what already governs your reporting. The model becomes a natural-language interface onto measurements you already trust, rather than a new and unaccountable source of numbers.
The takeaway
The instinct to let a capable model “just answer” is strong, and for low-stakes questions it’s fine. But when the answer feeds a clinical intervention, a resource allocation, or a figure in a board pack, the design question isn’t “how do we get the model to answer?” — it’s “how do we make sure the model never answers something it shouldn’t compute?” Supervised RAG is one well-proven answer: let the language model do what it’s good at — understanding intent and routing — and let verified services do what they’re good at, which is producing the number correctly, every time.
If you want the failure-mode view of this — the three ways RAG systems break and how to design against them — see What makes retrieval-augmented AI actually work. And if your team is weighing a grounded AI layer over data where accuracy isn’t optional, start a conversation.