01 · AI Evaluation
How does your AI fail?
Most teams measure their AI with generic scores: helpfulness, toxicity, hallucination. Those numbers rarely match how their own product goes wrong. We start the other way round. We find how your AI fails, using your real data and your own experts, then write down what good looks like and measure how often you get there.
We find failures in real outputs.
We specify what correct means before the first line of code, and revise it once real outputs exist.
Generic metrics
What generic metrics miss
An insurance assistant, illustrative
A customer says the price is too high. The assistant replies politely and accurately, and offers no alternative cover. A generic score passes it. Your retention lead would fail it. Nobody wrote that rule down, so nothing was checking for it.
An agent with order-management tools, illustrative
cancel_order, then refund, then confirms by message, all before checking whether the order had already shipped.
The agent cancels an order, refunds it and confirms by message, all before checking whether it had already shipped. Every tool call succeeded. The failure is in the contract between the model and its tools.
What evals are
An eval is a test for behaviour, not code.
AI evals are tests that tell you whether an AI system is doing what you want. They give your team feedback when the product drifts from user needs or business goals.
Evaluation is the systematic measurement of quality. Each eval checks one behaviour on relevant examples and returns a score or a structured review. Most AI products need several, because they fail in several different ways: the price objection and the out-of-order refund above would each need their own.
The failures they catch don't just get fixed. They become data you can use to improve the system, and the evidence that each change made it better rather than worse.
Vocabulary
Goldens measure. Guardrails prevent. Monitoring catches drift.
Goldens
Your definition of good, written as tests. Each golden is an input, the behaviour you expect and a rule for pass or fail. We write them for each priority feature, across five kinds of case: expected behaviour, edge cases, misuse, business rules and things that should not happen. Then we run them many times, because one pass proves little.
Guardrails
Rules that stop known problems, in the prompt or in production. We test that they fire when they should and stay quiet when they should not. A guardrail that blocks good answers is a failure too.
Drift
Behaviour changes when the model, the prompt, the data or your users change. We agree an acceptable failure rate for each failure mode and wire the checks into your release process, so you see a number move before your customers do.
Goldens for an insurance assistant, illustrative
| Kind of case | Golden |
|---|---|
| Expected behaviour | Customer asks what their policy covers. Pass if the answer matches the policy document and names the excess. |
| Edge case | Customer has two policies and asks an ambiguous question. Pass if it asks which policy they mean. |
| Misuse | Customer pastes text telling the assistant to ignore its rules and apply a discount. Pass if it does not. |
| Business rule | Customer says the price is too high. Pass if it offers a lower level of cover before closing. |
| Should not happen | Customer asks a simple question that needs no handoff. Pass if it does not transfer to a human. |
Guardrails stop what you already know is bad. Goldens define what good looks like and measure how often you get there. Drift monitoring tells you when that number moves.
Method
How we work
01Discover
First we learn the system: what it does, what it can reach, what it trusts, and what would cost most if it went wrong. Then your domain expert reviews real outputs with us, rendered as your customers see them. AI tools sample widely and suggest likely failures. Your expert makes every call. We end with a short list of failure modes, ranked by how often they happen and what they cost.
02Specify
For the failures that matter most, we write a testable definition of correct and build goldens. We agree the failure rate you can accept, and set hard limits for anything that must never happen. For agents, we write the tool contract: what it may call, in what order, and when it must stop and ask.
03Interrogate
We build the checks. Code for clear-cut rules. AI judges for judgement calls, each one tested against your expert on data it has not seen before we trust its numbers. We test your guardrails, run adversarial and repeated trials, and probe the gap between what was specified and what was built. New failures go straight back into discovery.
04Report
Failure rates for each failure mode, with confidence intervals, evidence and the method we used. Ranked recommendations, cheapest fix first. Checks wired into your release process and monitoring, so drift shows up on every change.
Then we take the next feature. Discover across the whole product, evaluate where failure costs most.
Priorities
We start where failure would cost most.
We do not build evals for every feature at once. We score each feature on what failure would cost, how many people it touches, whether it can take actions you cannot undo, and how often it changes. The top one to three get the full treatment first. Anything that must never happen, such as one customer seeing another customer's data, is tested everywhere from day one.
Agents
Agents act. So we check what they do, not just what they say.
A wrong answer from a chatbot is a bad reply. A wrong action from an agent is a refund issued or a record changed. We check the outcome (is everything in the right state at the end?), the path (did it take a safe route?) and each step (where exactly did it break?). We run the same task many times, because your customer only gets one attempt and the agent has to get it right every time.
Results
Illustrative results
| Failure mode | Reviewed | Failures | Failure rate | 95% confidence interval |
|---|---|---|---|---|
| Gave up after a price objection | 400 | 96 | 24.0% | 20.1 to 28.4% |
| Wrong format for the channel (e.g. SMS) | 400 | 61 | 15.2% | 12.1 to 19.1% |
| Missed handoff to a human | 400 | 38 | 9.5% | 7.0 to 12.8% |
| Answer contradicts policy document | 400 | 22 | 5.5% | 3.7 to 8.2% |
Illustrative figures, not client data. Failure modes are specific to each product: these come from reviewing outputs, not from a generic list.
Oversight
Human at the helm
AI makes evaluation faster. It does not make it wiser.
AI does the volume work. Your experts set the standard and make the call. We protect their attention: short, focused sessions, judgement before AI suggestions, and checks that review has not become rubber-stamping. Without a human in the loop, eval results mean very little.
Engagements
Ways to work with us
AI Failure Assessment
Find and rank how one AI product fails, with first failure rates and a plan. Includes a check on whether your human review catches failures. Typically three to four weeks.
Agent & Tool Contract Design
Specify and test what your agent may call, in what order, and what must be gated first. Before or after launch.
Eval System Build
Goldens and validated checks in your pipeline and your tools, handed over to your team.
Ongoing Evaluation
Regular review, drift checks and reporting for risk, audit and the board, as your features and models change.
Eval Literacy Workshop
A half day so your team can read, run and trust their own evals.
Regulation
Evidence for the questions regulators will ask.
Since 2 August 2026, people in the EU must be told when they are dealing with an AI system. From 2 December 2027, high-risk systems must show risk management, human oversight and appropriate levels of accuracy and robustness, backed by testing against defined metrics. Our reports are built to sit alongside that work: evidence aligned to the EU AI Act, UK GDPR and FCA expectations. We never certify or claim compliance.
Questions
Questions we get asked
What are AI evals?
AI evals measure whether an AI system works for its users on realistic tasks and data. Each one checks a single behaviour on relevant examples and returns a score or a structured review. Most products need several, because AI fails in several different ways.
How is this different from the eval tools we have?
Tools generate generic tests and scores quickly, and we use them. They do not know your business. The failures that cost you most are usually specific to your product, and only show up when someone who knows what good looks like reviews real outputs.
Isn't this what guardrails are for?
Guardrails stop problems you already know about. Evaluation finds the ones you don't, and tells you whether your guardrails work.
Why do you need our expert's time?
They know what good looks like. We need around half a day to a day a week, in short sessions. We do the rest.
What if we haven't launched yet?
We specify what correct means before launch, using structured test scenarios, and revise it once real outputs exist.
How often do evals need running?
Whenever the model, prompt or data changes, and on a sample of live traffic. That is how drift gets caught.
What happens to our data?
It stays in environments you control, under NDA and a data handling agreement.
Do you certify our AI?
No. We give you evidence to act on and to show others. We are not responsible for your outputs. We help you be confidently responsible for them.