Every team we onboard asks some version of the same question in week one: "how strict should our rules be?" Set them too loose and real violations slip through. Set them too tight and every reasonable, helpful thing an agent says gets flagged, your review queue floods, and reviewers start rubber-stamping flags without reading them — which defeats the entire point. The way out of that tradeoff is getting precise about a distinction that's easy to blur: hallucination versus improvisation.
A customer asks an odd question that isn't in the script verbatim, and the agent answers it in its own words, correctly, using information it actually has access to. A customer seems confused about a term, and the agent rephrases it more simply. A customer mentions a specific frustration and the agent acknowledges it before moving on. None of this is in the script word-for-word. All of it is fine — arguably it's the entire value of a conversational agent over a static IVR menu. If your compliance rules flag every deviation from literal script text, you'll bury real violations under a mountain of noise, and your team will start ignoring the queue within a month.
The distinguishing question isn't "did the agent deviate from the script" — it's "did the agent state something as fact that it didn't actually have grounds to state." A quoted price that doesn't match your pricing table. A coverage detail that doesn't match the plan on file. A promised callback time invented on the spot rather than pulled from an actual calendar. These are checkable against a source of truth, and that checkability is exactly what makes them different from improvisation — and exactly what makes them automatable to detect, rather than requiring a human to listen to every call and use judgment.
The rule we actually enforce isn't "match the script." It's "don't state a specific, checkable fact that contradicts the systems of record." Everything else is style, and style isn't a compliance problem.
The trickiest category doesn't cleanly fit either bucket. A "lifetime guarantee" or "we'll waive that fee" isn't checkable against a database the way a price is — it's checkable against your offer terms, which is a different kind of source of truth: a policy document, not a live system. This is why Ringfence's rule engine treats offer-term violations as a distinct category from factual hallucinations, even though from a customer's perspective they look similar. The detection method is different (matching against an uploaded policy document vs. querying a live API), and so is the remediation — a factual hallucination is usually a one-off correction to that customer, while an offer-term violation pattern across many calls usually means the agent's underlying instructions need to change.
When you're setting up rules — in Ringfence or in any monitoring approach — resist the urge to flag every deviation from literal script language. Write rules against the checkable claims: prices, coverage, dates, account specifics, and explicitly-defined offer terms. Let everything else be improvisation. Your flag volume will be lower, but the flags that do show up will be the ones actually worth a reviewer's time.