--- title: "Evals are the spec for an AI feature" description: "How to specify a feature built on a model that answers differently each run: test cases, a tolerance and who writes them, with the studio’s own figures." url: https://torn.studio/en/insights/evals-are-the-spec locale: en published: 2026-09-07 --- # Evals are the spec for an AI feature > **Short answer:** An AI feature is specified as an eval: a written set of cases the feature must handle, the cases where it must refuse, and a tolerance for how often it may miss, agreed before the first prompt. Hamel Husain’s March 2024 finding: unsuccessful AI products almost always share one root cause, no robust evaluation. The product role writes the eval. A feature built on a language model answers differently each time it is asked. That breaks the sentence every requirements document relies on: “it works”. This article is about what replaces it, who writes the replacement, and what the studio learned specifying eight AI environments in one product. ## Why does “it works” fail for an AI feature? Because there is no single output to check. A deterministic feature is accepted once; a model-backed one has to be accepted statistically, across the cases that matter, and re-accepted every time the prompt or the model changes. Hamel Husain, an AI consultant who has shipped these systems since 2023, wrote on 29 March 2024 that unsuccessful AI products “almost always share a common root cause: a failure to create robust evaluation systems”. The teams that fail are playing whack-a-mole: fix one answer, break another, and never know where they stand. ## What is an eval, in product terms? A specification in three parts, written in the reader’s language and owned by the product role. - The cases it must handle: real inputs, ideally from real users or logs, each with what a good answer contains. - The cases it must refuse: the questions outside scope, the data it may never reveal, the actions it may never claim to have taken. - The tolerance: how often it may miss on each set before the feature is pulled, stated as a number a person has signed. Husain describes three levels of testing that map onto those parts: cheap assertions that run on every change, human and model review of logged traces, and A/B tests with real users. The first two are the eval. The spec is a list of cases and a number, and the number is a product decision because it trades quality against shipping. ## Who writes it? The person who would otherwise write the acceptance criteria. An engineer can write the harness; only the product role can say which twenty cases matter, which refusals are non-negotiable, and what miss rate the business tolerates. Anthropic’s guidance on agent design, published 19 December 2024, makes the same point from the architecture side: find “the simplest solution possible, and only increasing complexity when needed”, and choose a predefined workflow over an autonomous agent wherever the steps can be known in advance. That choice is a spec decision, and it is made by whoever owns the cases. ## What did the studio learn doing it? Torn Studio held the product role in Changemkr, an AI platform for change management the studio part-owns, through June 2026. At the June boundary, eight AI environments ran on one service, each with its own model, tools and prompt versioning with rollback in one click, countable in the prompt registry. Every prompt change was a release, and every release was accepted against its cases. In June 2026 a third-party consultancy tested the planner’s AI assistant and reported it as unreliable. The studio turned the report into 27 numbered findings, grouped them by root cause before touching code, and found that 4 of the 27 were product decisions with no code fix at all: the feature was doing what it was told, and what it was told was wrong. That split, bug or decision, is what an eval makes visible before a tester does. The verification is where the honest limit sits. The fixes were run against the full stack in containers with browser tests: 11 passed, 1 skipped, and the three large generative flows were never verified end to end, because their outputs vary between runs and a test that expects the same output each time cannot carry them. The report says so per finding, which is the point: a verification that reports itself as fully green is one nobody can trust next time. ## Where does trust come in? An eval covers correctness; the cases about refusal and disclosure cover trust, and they belong in the same document. Google PAIR’s People + AI Guidebook asks teams to calibrate trust — “tell the user when a lack of data might mean they’ll need to use their own judgment” — and to show confidence as categories. The European Commission’s AI Act page says chatbots must make people aware they are interacting with a machine, with transparency rules applying from August 2026, and links to the text. How a feature earns that trust is its own article; the eval is where the cases get written down first. Where the model sits inside an existing system — the bounded job with a check around it — is covered in [AI in your existing systems](https://torn.studio/en/insights/ai-in-your-existing-systems). The cases in an eval are chosen the same way a backlog is prioritized, and that method is in [deciding what to build next](https://torn.studio/en/insights/deciding-what-to-build-next). ## How the studio specifies an AI feature Product Management at Torn Studio is priced per engagement with the price fixed before work starts, and an AI feature in scope gets its eval written before its prompt: the cases, the refusals, the tolerance, signed by the person who will read the number. The studio then builds against it, so the feature ships with the document that says what it may do and where it must refuse. **Read next** - [Product Management at Torn Studio](https://torn.studio/en/services/product-management) ## Common questions ### What is an eval for an AI feature? A written set of test cases and a tolerance: the inputs the feature must handle with what a good answer contains, the inputs it must refuse, and how often it may miss before it is pulled. It replaces “it works” as the acceptance criterion for a feature whose output varies. ### Who should write the evals, the engineers or the product manager? The product role writes the cases and the tolerance; engineering writes the harness that runs them. Only the product role can say which cases matter and what miss rate the business tolerates, and that number is a product decision. ### How many test cases does an AI feature need? Start with the failures already visible in logs and traces, which is where Husain’s March 2024 essay says the labor goes, and add cases as they appear. Twenty real cases with a signed tolerance beat two hundred generated ones nobody owns. ### Can a feature whose output varies be tested at all? Yes, statistically. The studio’s own verification in June 2026 ran 11 browser tests against a full stack with 1 skipped, and left the three large generative flows unverified end to end because their outputs vary. The report said so per finding, which is what makes the next round trustworthy. ### What happens when the prompt changes? A prompt change is a release: it runs against the eval before it ships, and it can be rolled back. In the Changemkr platform, each of eight AI environments carried its own prompt versioning with rollback in one click at the June 2026 boundary. ### How does Torn Studio handle an AI feature in a product engagement? The eval is written before the prompt, inside an engagement with a fixed price set in advance: cases, refusals and a tolerance signed by the person who will read the number. The build is accepted against it, and the feature ships with the document that says what it may do. ## Sources - [Your AI Product Needs Evals — Hamel Husain](https://hamel.dev/blog/posts/evals/) — Backs the 29 March 2024 finding on the root cause behind unsuccessful AI products, the three levels of testing, and where the labor actually goes. - [Building Effective AI Agents — Anthropic](https://www.anthropic.com/engineering/building-effective-agents) — Backs the 19 December 2024 advice to find the simplest solution and to prefer a predefined workflow where the steps can be known in advance. - [Explainability + Trust — People + AI Guidebook — Google PAIR](https://pair.withgoogle.com/chapter/explainability-trust/) — Backs the guidance on calibrating trust, saying so when data is lacking, and showing confidence as categories. - [AI Act — Shaping Europe’s digital future — European Commission](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) — Backs the point that chatbots must make people aware they are interacting with a machine, and that the transparency rules apply from August 2026.