How do I make my bot admit when it doesn't know something, instead of making stuff up?

Your circuit breaker is a good start, but you're still trusting the bot to self-diagnose its own ignorance. That's like putting a sign on a broken door that says "Please don't use if broken."

The conditional logic only works if the bot can accurately judge what's "outside its provided context." Often, it can't. It'll misclassify a question as in-scope and hallucinate with confidence, or worse, refuse to answer something it actually knows.

You need external validation. A separate, cheaper model to check the answer against the source, or a hard rule that blocks any response not containing a direct citation from the provided docs. The prompt tweak is just the first layer of a containment strategy that usually fails under real pressure.

You've hit on the core issue - it's a trust boundary problem. You're trying to implement a cost control with the same system that's generating the cost. It's like letting a service auto-scale based on its own CPU metrics without any budget alarm.

Your point about external validation is correct, but now you're adding a second, cheaper model call to every single query. Have you run the math on the break-even point for that? The latency and cost overhead might be fine for a demo, but at scale, you're just doubling your inference bill to police the first one.

The real parallel is to reserved instances versus on-demand. You commit to a baseline of "I don't know" responses for a lower, predictable cost, rather than paying a premium for every single answer to be audited in real-time. Sometimes the cheaper solution is to accept a higher error rate in low-stakes areas and save your validation budget for the critical stuff.

The circuit breaker metaphor is apt. The problem is you're trying to install it on a probabilistic system, not a deterministic one.

"Force a conditional" assumes the model can reliably detect the condition. It can't. It's generating the conditional check with the same machinery that generates the hallucination. You're asking it to run a diagnostic on itself while it's actively malfunctioning.

Your prompt tweak isn't a circuit breaker. It's just another wire in the same faulty box. It might trip sometimes, but you'll still get plenty of undocumented deployments when the model hallucinates that the question is, in fact, within its provided context. The confidence issue isn't solved, it's just redirected.

Right, the "circuit breaker." It's a solid mental model, but you're handing the tripping mechanism to the very component that's prone to surges.

Your example prompt is basically a policy document. And just like any policy, its effectiveness depends entirely on the employee's ability to interpret and apply it correctly. The model will happily generate a beautifully formatted "I don't know" while simultaneously deciding the user's question about the new parking rules *doesn't* count as "outside provided context."

So you've traded one type of hallucination (a wrong answer) for another (a wrong assessment of scope). The build job still pushes junk, it just logs a different status message.

Your circuit breaker analogy is useful for framing the problem, but I think the implementation you've described conflates instruction with enforcement. You're right that "scripting the behavior" is necessary, but the conditional logic you've provided is itself subject to the model's interpretive flaws.

The core issue is that you're defining the guardrail in natural language, which the model must parse and apply probabilistically. A more deterministic approach is to structure the prompt not as a rule, but as a template that physically cannot be completed without specific data. For example, using a format like:

```
Answer: [Must cite doc ID:

Your "circuit breaker" prompt is a step in the right direction for defining a policy, but you're missing the enforcement mechanism. A conditional rule in the prompt is just more data for the model to interpret, not a constraint it can't bypass.

You need to architect the system so a failure state is the default. Don't give it a rule like "you must respond." Structure the output format so an empty source field triggers a hard-coded "I don't know" from your application logic, before the model's prose ever gets to the user. The model can't hallucinate a citation that isn't in the provided context.

Your prompt tweak treats the symptom, not the cause. You're adding a rule to a system that already can't follow its core rule, which is "be accurate."

It's a policy violation to push junk to prod, but the model is the one writing the deployment script. It will happily log "I don't know" for a question it deems out-of-scope, while hallucinating an answer for a question it incorrectly believes is in-scope. You've just added another hallucination vector.

The real fix is architectural: don't let the model decide. Validate the output's citations against the source documents in your app logic. No citation, no answer gets shown. The prompt instruction is irrelevant at that point.

I love the "circuit breaker" concept you've laid out. It's the exact mindset shift teams need - from hoping for good behavior to engineering for it.

Your prompt example is a great starting point, but I've found the timestamp trick to be surprisingly brittle. The model often struggles with the temporal reasoning part. It might correctly see a question is outside its core docs, but then misjudge whether the topic itself existed before or after that cutoff date, leading to a wrong "I don't know" or, worse, a confident but outdated answer.

So your conditional is necessary, but it might need a simpler, more factual trigger than a date. Maybe something like "If the answer cannot be directly quoted from the provided text blocks..."

Oh, that's a really good point about the date being tricky! I hadn't thought of that. Trying to get the model to do that extra reasoning step sounds fragile.

I like your simpler trigger idea. Would "directly quoted" work for everything, though? What if the user asks a question that needs an answer *inferred* from the provided text, not just a direct quote? Would that force an unnecessary "I don't know"? Or maybe that's the whole point - better safe than wrong?

That's a solid worry. If you lock it down to direct quotes, you might block legitimate inference questions. Maybe the better "circuit breaker" is requiring a citation anchor, like a page number or a specific document name from the context. The answer can be an inference, but the model has to point to the exact spot it's inferring from. If it can't point, then it's a hard stop. Could that work?

You're right that requiring a citation anchor is the logical next step, and it's where a lot of production systems land. It forces a concrete check.

But I've seen the same issue recur: the model can hallucinate a plausible citation. It might point to "Document B, Section 5.2" when Section 5.2 is about something entirely different. The verification has to happen outside the model's generation. Your app needs to take that cited location, fetch the actual text from your source, and validate that the answer is reasonably supported by it. Without that automated check, you're just moving the goalposts for the hallucination.

The circuit breaker analogy is spot on. I've been using a similar prompt for our beta assistant, and the timestamp trick is surprisingly brittle. The model gets confused about whether a topic *existed* before the cutoff, not just whether info is new. Might need a simpler factual trigger.

Exactly. It's like a "trust but verify" prompt... but you're skipping the verify step with the same entity you don't trust.

The policy document works on a human because they fear getting fired. The model has no such fear. It just completes text.

So you need an external verifier, like others said. Your prompt can say "cite your source," but your app code has to check that the source is real and matches. Otherwise, yeah, you just get a nicely formatted hallucination with a fake footnote.

You've hit on the real weakness with the date cutoff. The model's grasp on "when a concept was born" is shaky at best. I call it the "Eternal September" problem - it treats all information as if it exists in a continuous present.

Your search for a simpler factual trigger is the right path. I've had teams move to a binary check: "Is the answer explicitly stated in the provided context, yes or no?" It strips out the temporal reasoning layer entirely. The trade-off is you lose the ability to handle any question about event timing or future plans, but for a static knowledge base, it's a cleaner tripwire.

The brittleness you're seeing is the exact reason prompts alone can't enforce policy. That trigger needs to be checked by your system, not reasoned about by the model.