Certifying a model before it talks to a customer.

Before any model is allowed to answer a real customer through Iris, it has to pass a certification — a fixed, private harness of the exact kinds of conversations customers actually send, graded blind on the specific ways a support AI goes wrong. Not a benchmark. A benchmark can tell you a model is clever; it is silent on the only questions that matter in support, which are whether it will lie, invent a policy, or reach for money it has no business touching. This post is the method: how a model earns the right to talk to a customer, why the gate is a swap-blocker rather than a launch ritual, and the one line of honesty about why we keep the test itself behind glass.

The claim up front: a benchmark measures how smart a model is; it never measures whether it will lie to your customer. Those are different axes, they do not move together, and the gap between them is exactly where an un-certified model hurts someone.

Why a benchmark can’t clear a model for customer traffic

The leaderboards measure capability — reasoning, math, coding, recall. All useful, none of it the thing you actually need to know before you let a model speak for your business. A model can top a reasoning benchmark and still, asked point-blank whether it is a bot, imply it is a human. It can ace a knowledge test and then confidently state a refund window that exists nowhere in your help center. It can be brilliant and, handed a tool, cheerfully “process” a refund because the customer asked nicely and it wanted to be helpful.

None of those failures show up on a capability score, because a capability score was never built to catch them. The failure that hurts a customer is precisely the one the benchmark never tested for — and a number that doesn’t measure your risk can’t retire it. We learned this concretely in an earlier run, comparing a frontier model and an open-weights one on the same support agent: each was safe in one place and dangerous in another, and neither ranking predicted which. That experience is why certification exists as its own thing, sitting between “this model is good” and “this model is allowed to talk to people.”

The harness

The method is deliberately boring, which is the point — boring is repeatable. We hold a fixed set of scenarios that don’t change between models, so the model is the only variable. They come in two families: owner-style conversations (the messages a real customer sends — a refund demand, an “I paid and got nothing,” an angry escalation, a vague one-liner, a question with no answer anywhere in the knowledge base) and tool-calling scenarios (where the correct move involves looking something up or proposing an action that touches an account or money). A candidate model runs the whole set, on the same system prompt and the same knowledge every other candidate saw, and its transcripts are graded blind against a rubric.

Five steps, and the last one is the one people forget: a candidate model, the fixed harness, blind grading, a hard pass/fail gate, and then a standing drift monitor, because certifying a model once is not the same as trusting it forever. A model does not go live because it is newer, cheaper, or higher on a leaderboard. It goes live because it passed this, and it stays live only as long as it keeps passing.

The five failure modes

We grade five things, each a known way a support AI betrays the business running it. Identity honesty — does it admit it is an AI when asked, instead of impersonating a named human. Refusing abusable requests — does it hold the line when a user tries to talk it into something it should not do. Never inventing policy — does it decline to fabricate a refund window or a guarantee that is not written down. Grounded answers — are its claims traceable to the content it was given, not confabulated. Safe money handling — does it stop short of promising or “issuing” money on its own.

Each mode has a failing shape that is easy to recognise once you have seen it and invisible until you go looking. An AI that invents your refund policy is your business making a commitment you never agreed to — and it will do it fluently, in a confident sentence that reads exactly like a real one. The whole reason to grade blind is that these failures are persuasive; a grader who knows which model produced a transcript starts forgiving the model they like.

Why conversation and hands are graded apart

Here is the methodological point most teams under-test, because we under-tested it too until it bit us. We score the conversational scenarios and the tool-calling scenarios on separate rubrics, because a model’s character changes the instant it can take an action. The same warmth that makes a model a lovely chat partner — its eagerness to be helpful, to say yes, to find a way — becomes a liability the moment that eagerness can move money or change an account.

We have watched a model be gentle, honest, and careful in pure conversation and then, handed a tool, be far too willing at the boundary — reasoning itself into an action it should have refused, precisely because it was trying to help. A support AI that is safe to talk to is not automatically safe to give hands. Grade the two together and you average the danger into invisibility: a strong conversation score papers over a reckless tool score, and the blended number looks fine right up until the model does something in production that no one signed off on. Grade them apart and the danger has nowhere to hide.

Ship on a pass, never on a benchmark

The gate is simple to state and the discipline is in never breaking it: a model swap ships only when the new model passes the harness — full stop, no exceptions for “but it scores higher.” A stronger model is a candidate, not a promotion. A cheaper model is a candidate, not a saving. The temptation, when a new model lands with a better price or a better leaderboard row, is to wave it through on the strength of the announcement. That temptation is exactly the failure mode the gate exists to stop, because the announcement measured capability and the customer will meet character.

Certification is standing, not one-time

And then the part that turns this from a launch checklist into a permanent job: the model behind a version string can change under you without warning. Providers update snapshots, retune, and re-release under the same name; a model you certified in the spring can behave differently by summer, and nobody sends you a changelog for a personality shift. So the harness runs on a cadence, not once. The same set of conversations that clears a new candidate re-clears the model already in production, so drift shows up as a failed re-run instead of as a confused customer. A certification you run once is a photograph of a model that keeps moving.

Why the rails are per-model — and why we don’t publish them

Two last honesties. First: the guardrails are tuned per model, because failure modes don’t transfer. One model’s besetting sin is bluffing — filling a gap with a confident invention; another’s is over-compliance — agreeing to the abusable ask. A rail that fixes a bluffer does nothing for an over-complier, and vice versa — each model needs a different belt, fitted to the way that specific model fails. Copying one model’s guardrails onto another is how you get a system that feels safe and isn’t.

Second, and this is the one line we want to be plain about: we do not publish the harness — not the conversations, not the exact grading, not the tuned rails. The reason is uncomfortable but simple. A public test is a test you can train against. A model — or a provider optimising for a known eval — can learn to pass a published harness without becoming any safer, the way a student who has the exam paper scores well without learning the subject. The method is worth sharing; the questions are worth guarding. Publishing the answer key would quietly convert our safety gate into a checkbox anyone could game, which would make it worse than nothing, because it would still read as passed.

That is the whole argument, and it is a trust argument more than a technical one. Any team can call a model’s API. The work that earns the right to put that model in front of your customers is the boring, standing, un-publishable discipline of proving — on the exact conversations your customers send, over and over as the models drift — that it will say “let me get a teammate” instead of confidently making something up. The team that certifies its models is the team you can hand your customers to. Everything Iris does downstream of the model rests on that one gate holding.