The problem
System prompts drift. Not immediately, but reliably: a persistent user, a novel domain, a slightly ambiguous problem, and the model will occasionally leak the final answer. This is not a bug in the model. It is a fact about long-form generation.
For a product whose entire promise is “we will not give the answer,” this drift is unacceptable.
Why not just a stricter system prompt
Because prompts drift, and the promise doesn’t. The guard is defense-in-depth: even when the base prompt fails, the surface presented to the user holds.
Rates
The honest answer today is that we are still collecting them. The three layers are instrumented — which rule fired, on which turn, and whether a regenerate fixed it — and the refusal template carries a report button so false refusals come back to us as data rather than guesses.
What we will publish, once the traffic behind it is real: leak rate, false-refusal rate, and the share each layer catches. A number quoted before it has been measured is worth less than no number, and the whole point of this page is a claim you can hold us to.
The dark version of this page
The uncomfortable version of the argument here is that the guard is a product feature because we assume some users will try to jailbreak the tutor. That’s true. It’s also true of every safety-relevant product; a bank vault is a product feature because some people will try to break in. Assuming good faith doesn’t require pretending adversarial behavior doesn’t exist. It requires building the surface such that the good-faith users get the good product, and the bad-faith users hit walls.