Turn Vague AI Requirements Into Testable Rules

“The assistant should be accurate, fast, secure, and easy to use.”

That sentence could appear in almost any AI project brief. It sounds sensible. It may even receive immediate agreement from product, engineering, security, and leadership. Yet a team cannot build or release against it because none of its important words tells the team what to observe.

How accurate, on which tasks, using whose answer as the reference? How fast, at which percentile, under what load? What does secure mean for this workflow and its data? Which users must find it easy, and what must they be able to complete?

These are not requests for pedantic detail. They are missing decisions.

Ambiguous language is unavoidable early in discovery. People use broad words because they are still learning what they need. The failure begins when those words survive unchanged into a delivery commitment. By then, different people may have privately assigned different meanings to the same requirement. The prototype can appear successful while every stakeholder is imagining a different finished product.

The useful response is not to demand perfect specifications. It is to turn each important adjective into a small contract connecting a user situation, observable behavior, evidence, and a decision. That contract gives a team something it can test and gives leaders an honest way to accept tradeoffs.

Start with the word-to-test contract

Use this table before debating models, agent frameworks, or launch dates. The examples are starting points, not universal targets.

The most important column is the last one. A metric without a consequence is merely a number on a dashboard. If nobody knows what happens when the p95 latency is too high or the critical-case evaluation fails, the requirement still has no operational force.

Google’s guidance on implementing service-level objectives makes the same point for conventional service reliability: objectives become valuable when stakeholders accept them and use them to prioritize work. AI quality needs that connection too. A score should change a release, rollout, rollback, or review decision.

One adjective usually hides several requirements

Consider “accurate.” For a document assistant, it might refer to at least five different behaviors:

• retrieving the relevant and current source;
• representing the source without inventing support;
• following the organization’s definitions and calculation rules;
• admitting when the available evidence is insufficient;
• presenting the result in a form the user can interpret correctly.

A single accuracy percentage can hide all five. The assistant could answer 90 percent of easy questions well and still fail every rare question that carries legal or financial consequences. It could retrieve the correct policy and then state a conclusion the policy does not support. It could produce a numerically correct answer from an obsolete dataset. It could pass a benchmark while confusing the people who use it.

The requirement therefore needs both a population and a failure taxonomy. Define the users, tasks, languages, data conditions, and operating boundaries represented in the evaluation. Then distinguish failure types that demand different responses. A harmless formatting error should not be treated like disclosure of restricted data. A missing citation is not identical to a fabricated one. An appropriate refusal is not a failed answer.

NIST’s AI Risk Management Framework says accuracy measurements should be tied to clearly defined, realistic test sets and documented methods. Its measurement guidance also calls for testing in conditions similar to deployment, recording uncertainty, monitoring production behavior, and using repeatable evaluation processes. That is a stronger standard than asking whether a handful of demo answers look good.

The goal is not measurement theater. It is knowing what the number means.

Rewrite the requirement as observable behavior

A useful requirement describes what happens at the boundary between the system and its world. It does not prescribe implementation unless the implementation itself is a constraint.

“Use a large language model to answer employee questions” is a solution. “Employees can find the current approved travel policy and see the source used for the answer” is behavior. The second statement leaves room to discover that better search, a structured form, deterministic rules, or a smaller AI component solves the problem more reliably.

A compact behavioral requirement can use this pattern:

When a named user encounters a named situation, the system must produce or prevent an observable outcome, within a stated boundary, as demonstrated by specific evidence.

For example:

When a support agent asks about an active refund policy, the assistant must answer from an approved, current source and display that source. If no approved source supports the answer, it must say so rather than infer a policy. This behavior will be tested against a versioned set of current, expired, conflicting, and missing-policy cases.

That paragraph creates design work. The team now needs source ownership, effective dates, access controls, expected refusal behavior, and test cases. This is good news. The work existed already; precise language merely made it visible before production.

This approach is narrower than surfacing every project belief. When AI Projects Break, Look for Hidden Assumptions examines assumptions across data, models, costs, and governance. A behavioral requirement takes one important assumption and makes it enforceable at a system boundary.

Define the evidence before building the demo

Teams often postpone acceptance criteria because they expect the prototype to reveal what is possible. Some exploration is necessary, especially when model behavior or data quality is uncertain. But postponing all evaluation lets the demo define success after the fact.

Before implementation, create a small evaluation charter:

1. Decision: What choice will the evaluation inform—continue discovery, begin a limited pilot, expand access, or release broadly?
2. Population: Which users, tasks, languages, documents, and edge conditions must the evidence represent?
3. Failure classes: Which errors are annoying, costly, reversible, or unacceptable?
4. Measures: What will be checked automatically, by domain reviewers, through user behavior, and in production?
5. Thresholds: What is the minimum acceptable result for each protected behavior?
6. Owner: Who can accept residual risk, and who can stop the release?
7. Refresh rule: What event forces reevaluation—a model change, prompt revision, new data source, policy update, or tool integration?

An evaluation set is not a permanent truth. It is a sampled representation of intended use. Keep its origin and version visible. Include ordinary cases, boundary cases, missing-information cases, and cases where the correct behavior is refusal or escalation. Protect a holdout set when repeated tuning would otherwise teach the team to optimize for familiar examples.

Also separate components where possible. For retrieval-augmented generation, measure whether retrieval found an authoritative source before judging the generated answer. For an agent, distinguish tool selection, argument construction, permission enforcement, task completion, and unnecessary steps. One end-to-end score can tell you that the system is weak; component evidence helps you decide what to change.

“Safe” requires a threat and an authority boundary

Safe is among the broadest words in technology. It can refer to harmful content, privacy, security, bias, physical consequences, financial loss, or the system’s authority to act. A team cannot implement all possible meanings equally. It has to identify the credible harms for the actual context.

For an internal summarizer that reads approved documents, the central risks may be access control, unsupported claims, and retention of sensitive inputs. For an agent that can issue refunds, change records, or send messages, action authority becomes central. The requirement should name what the system may read, propose, and execute; which identity it uses; and which actions require another person’s approval.

OWASP’s guidance on excessive agency in LLM applications recommends minimizing permissions and requiring human approval for high-impact actions. “Keep a human in the loop” is still too vague, however. The contract must state which human, shown what information, before which action, with what ability to reject or modify it.

An approval click after an action is effectively irreversible is not a control. Nor is review by a person who cannot see the source, tool arguments, or consequence. Safety criteria must describe the point at which authority changes hands.

“Done” is a release decision, not the absence of known work

AI systems are probabilistic, data changes, providers update models, and users discover cases that were absent from testing. No serious team can prove that every future output will be correct or that the last defect has been removed. “Keep testing until it is perfect” creates an infinite task disguised as a quality standard.

Done should instead mean that a named release state has met its evidence requirements. A limited internal pilot can be done while still being unsuitable for customer-facing automation. A read-only assistant can be done while action-taking remains prohibited. A feature can meet its quality floor while carrying documented limitations and a plan to collect better evidence.

A defensible release record answers:

• What version of the model, prompt, retrieval index, tools, and policy was tested?
• Which user population and operating conditions does the evidence cover?
• Which thresholds passed, failed, or remain uncertain?
• Which failures trigger fallback, human review, rollback, or suspension?
• Who owns production monitoring and incident response?
• Which residual risks did the decision owner accept?
• What change requires the evaluation to run again?

This is not a demand for a large approval committee. A small team can keep the record on one page. The value comes from binding evidence to authority. The related reliability problem—protecting evaluation, maintenance, and recovery capacity while delivery pressure grows—is covered in Protect Reliability While Shipping AI Faster.

When the evidence is expensive, scale it to consequence

Not every requirement deserves the same evaluation budget. A low-impact writing suggestion and an autonomous payment action should not pass through identical controls.

Use consequence to scale rigor. Ask how much harm a failure could cause, whether the action is reversible, how quickly the failure can be detected, how many people could be affected, and whether a human has a meaningful opportunity to intervene. Higher consequence should usually mean more representative tests, independent review, narrower permissions, stronger production monitoring, and slower expansion.

This prevents two common errors. The first is overengineering a harmless experiment until nobody can learn from it. The second is treating a polished high-risk demo as evidence that broad automation is ready.

A staged rollout is itself a requirement. Define the initial user group, permitted tasks, observation period, expansion evidence, and stop conditions. Do not write “start small” and assume everyone imagines the same boundary. A pilot without an exit rule can quietly become production through continued use.

Protocols help preserve these choices after the project leaves the meeting room. AI Reliability Requires Protocols, Not Blind Trust explains how evaluation, observability, escalation, approval, and rehearsal work together when safeguards must operate repeatedly.

Review the nouns as carefully as the adjectives

Ambiguity also hides inside apparently concrete nouns: customer, document, incident, current, authorized user, sensitive data, completed task, and business value.

If two departments use “customer” differently, an evaluation sample may exclude the people whose workflow carries the greatest risk. If “current document” means the newest file to engineering but the latest approved policy to compliance, retrieval can be technically fresh and operationally wrong. If “completed task” means the agent produced an output rather than the user achieved an outcome, a completion dashboard can reward extra correction work.

Create a small glossary only for terms that change implementation or acceptance. Give each one an owner and an example. When disagreement appears, do not solve it by choosing a softer phrase. Identify who has authority to define the term and which evidence could challenge that definition.

The same rule applies to business value. “Save time” needs a baseline, a population, and a view of displaced work. An assistant may reduce drafting time while adding review, correction, support, and audit work elsewhere. Measure the workflow, not only the model interaction.

Clarity is a maintained engineering asset

Requirements do not become clear once and remain clear forever. New users arrive. Source data changes. A tool gains write access. A vendor changes model behavior. An incident reveals an untested condition. The contract must evolve with the system.

That does not make early definition pointless. It makes versioning important. Record what changed, why it changed, which tests were added, and which decision must be revisited. Separate a discovery update—new evidence improved understanding—from a commitment change that affects scope, risk, budget, or dates.

Broad language has a legitimate place at the start of a conversation. “We need a trustworthy assistant” can express a valuable direction. It simply cannot be the final instruction to the people who must build, test, approve, operate, and depend on the system.

For each consequential word, name the user situation. Describe observable behavior. Choose representative evidence. Set a threshold. Assign a decision owner. Define what happens when the threshold is missed.

Then the team no longer has to argue about whether the system feels accurate, safe, fast, or finished. It can examine what happened, decide what the evidence permits, and state honestly what remains uncertain. That is what makes a requirement useful: not perfect prediction, but a shared rule for the next real decision.