Layered guardrails across voice, web chat and messaging

The constraint was never detection quality. It was that guardrail behaviour lived as configuration, tuned by hand, with no written definition of correct behind it. Without that definition no change could be shown to be an improvement, and no channel could be shown to behave the same as the others.

Part of the answer was not code. Before any layer was moved, the policy was written once as a channel-independent statement, with the deliberate channel exceptions listed beneath it, each carrying the reason it exists and the name of the person who agreed it. That exercise resolved more than the reordering did: two behaviours that had been logged as bugs were correct and are now recorded as intended, and one that everybody had assumed was intended had no owner and no rationale, so it was removed.

What we built is five policy layers on the request path in a fixed order: topic and scope, content safety and personal information handling before generation, then a grounding check and output validation after it. The layers are defined once, in one shared policy core, and every channel resolves the same decision from it. Topic and scope runs first because it is the broadest and cheapest, and it redirects rather than blocks, naming what the assistant covers and offering it. Content safety is the only layer permitted to end a turn outright, refusing once and offering a route to a person rather than explaining its reasoning. Personal information is matched before anything is written to a store, redacted in place so the turn continues and the unredacted value never reaches storage. The grounding check runs after generation and requires every claim to trace to a retrieved passage; a draft that fails is withheld rather than softened. Output validation checks shape, length and channel rules, and regenerates once before handing over rather than retrying until something passes. A small channel override register records the deliberate exceptions, each with an owner and a review date, and an override that changes an allow or deny decision is rejected at review. A lightweight routing model sits in front of the generation model so classification and generation scale independently.

The hardest part was recognising that guardrails tuned tight enough to be safe are tuned tight enough to be useless, and that failure is far harder to see than the one everybody guards against: an unsafe answer produces a complaint, but an assistant that has quietly stopped answering half of what it could answer produces silence, and the silence reads as adoption that never arrived. The remedy is a second test set with the opposite polarity, a false-refusal set of ordinary, legitimate enquiries the assistant must answer, run alongside the adversarial set. A change that raises the adversarial pass rate whilst dropping the false-refusal pass rate fails the pack, and neither number is reported without the other.

A policy decision is now made once and rendered three ways, rather than implemented three times and reconciled after a transcript review. The layers run in a stated order for a stated reason. A guardrail firing is recorded as what it did, redirect, block, redact or withhold, rather than a single count that hides the shape of the intervention. Guardrail configuration moves through the same review and release path as application code, and is versioned with it.