Grounding as a leash, not a library

The default mental model for retrieval is a library: you fetch facts so the model knows more and answers better. That is the right model most of the time. It is exactly the wrong model when your problem is not ignorance but the opposite, a base model that already knows too much and will confidently say something it must never say.

I ran into this building a voice AI that interviews people inside large organizations. The work is white-labeled and confidential: it must never name the real client, never name a competitor's product, never claim a capability that does not exist. And the base voice model, left to itself, will happily do all three, in a fluent, authoritative sentence, mid-conversation. The threat here is not accuracy. It is reputational and legal. A wrong fact is embarrassing; a leaked name is a breach.

So I stopped thinking of grounding as a library and started thinking of it as a leash.

Retrieve to suppress, not (only) to inform

In the library model, retrieval's job is positive: bring in knowledge the model lacks. In the leash model, retrieval's primary job is negative: keep the model authoritative on the domain while making it structurally unable to wander into what it must not say. Same machinery, inverted motive. You are not filling a gap in what it knows. You are fencing in what it is allowed to express.

That inversion changes three design choices.

1. Ground proactively, before the model improvises

The naive setup retrieves only when the user asks something. That leaves a huge gap: the rest of the time, the model is improvising from its own training prior, which is precisely where it reaches for a real product name or a half-remembered "fact" about the client. In my build this was the actual root cause of the model going off-script. It was a wiring gap, not a knowledge gap: the deep, safe context existed, it just only reached the model when someone happened to ask.

The fix is to push a short expert briefing into the model's context before it speaks on a topic, and to refresh it when the conversation moves. Proactive grounding over on-ask retrieval. Get the safe framing in front of the model so it has no reason to invent one.

2. Supersede the context, never accumulate it

Here is a hygiene lesson I earned the hard way. When the conversation hops topics, it is tempting to keep pinning new briefings on top of old ones. Don't. Stacking briefings does two bad things at once: it bloats your token budget, and, worse, it dilutes the hard guardrails sitting in the same context. The rules that keep the model safe get buried under fat, half-relevant clippings.

The discipline is supersede, not accumulate: delete the previous briefing before pinning the next one. Exactly one is live at a time. Your guardrails stay concentrated instead of drowning in stale context. Context is not a scratchpad you append to forever; it is a small, deliberately curated working set.

3. Put a deterministic guard at the last possible moment

Proactive grounding lowers the odds the model says the wrong thing. It does not make it impossible, and "unlikely" is not a guarantee you can sell to a legal team. So the final layer is not a smarter prompt and not a second LLM checking the first. It is plain, deterministic code at the last mile.

Two guards do the work in my build:

• A render-time scrubber. Right before any text is spoken, every forbidden term is rewritten out of it, mechanically. This runs on everything: the model's instructions, the briefings, the grounded context. You cannot trust a probabilistic model to reliably not say a name, so the guarantee is made by a string operation, not by hope.
• A verbatim guard on reformatting. A small model tidies each spoken turn into clean text, and because it receives a question, it could quietly "answer" it or flip a negation, turning "it isn't working" into "working." So a deterministic word-level diff rejects the reformat if it adds too many words (fabrication) or drops a negation word (meaning change), while letting harmless glue like "and" or "then" fall away. A diff, not another model judging a model.

The principle underneath both: probabilistic generation, deterministic containment. Let the model be creative; let plain code be the thing that cannot be argued with.

When NOT to use the leash

• The model doesn't know anything dangerous. If your domain is genuinely novel to the base model and there are no names, brands, or confidentiality lines to protect, you have a library problem, not a leash problem. Retrieve to inform and move on.
• Mistakes are cheap and visible. Internal prototyping, a tool used by experts who will catch a slip, low-stakes drafting. The deterministic last-mile guard is real engineering; spend it where a single wrong word is a genuine liability, not everywhere.
• You can simply not give the model the secret. The strongest containment is never putting the forbidden thing in reach at all. The leash is for the harder case, where the model already knows the dangerous thing from pre-training and you cannot un-teach it.

Adopting it: a short checklist

1. Decide your real risk. Is it that the model knows too little (library) or that it knows something it must not say (leash)? They lead to opposite designs.
2. Push grounding proactively, before the model speaks on a topic, rather than only when asked.
3. Keep exactly one briefing live: supersede, don't accumulate, so your guardrails never get diluted.
4. Add a deterministic render-time scrubber for forbidden terms. Run it on instructions and context too, not just output.
5. If a second model reformats your output, guard it with a deterministic diff (added words, dropped negations), not with another LLM.

The one-line version

When the danger is what the model already knows, retrieval is a leash, not a library: ground it proactively, keep one briefing live so guardrails stay sharp, and make the no-say guarantee with deterministic code at the last mile, because you cannot trust a probabilistic model to reliably not say a name.