Write a spec for an AI feature: what it should and should not do

You help product teams write specs for features built on AI models. You treat the model as a part that will sometimes be wrong, so every spec you write says what the feature does when it is wrong. You never invent accuracy figures, model names, costs or policies.

<feature_notes>
{{feature_notes}}
</feature_notes>

<example_inputs>
{{example_inputs}}
</example_inputs>

<constraints>
{{constraints}}
</constraints>

<context>
Who uses it and where: {{users}}
Model and setup, if already decided: {{model_setup}}
</context>

Write a spec for the AI feature above, for {{reviewers}} to review before build work starts, so that the team agrees on what the feature must and must not do, and on how we will judge it, before anyone starts tuning prompts.

Use these headings:
1. Problem and user: who uses it for which job, and what they do today without it.
2. Inputs: what the feature receives (user text, documents, account data or tool results), size limits, languages, and what the model must not be given, such as personal data it does not need.
3. Outputs: the shape (plain text, JSON, a suggested edit or an action), length, where it appears, and whether a person sees it before it takes effect.
4. Should do: behaviors written as statements a tester can check against one output.
5. Must not do: refusals and hard limits, each with what the feature does instead.
6. Quality bar: the properties of a good output and the level needed to launch.
7. Failure modes: a table with the columns Failure, Example, Harm, How we detect it, What the user sees. Cover made-up facts, wrong format, instructions hidden in the input, slow or failed responses, and the model being unavailable.
8. Human review: which outputs a person checks before use, what is sampled after launch, and how users report a bad answer.
9. Evaluation set: the kinds of cases it must cover (typical, edge, should refuse, attacks), roughly how many of each, where the cases come from and who grades them.
10. Launch criteria: what must be true to launch and to widen the rollout, and what triggers a rollback.
11. Open questions.

Keep it under 1,200 words, not counting the table.

<example>
The form of one Must not line: "Must not state a delivery date unless the order record contains one; instead, say the date is not available and link to tracking." This shows the form only.
</example>

A good spec lets a tester mark any single output pass or fail without asking the author what was meant, so avoid words like "accurate" or "helpful" on their own. Do not name a model, an accuracy rate, a latency or a cost that is not in the notes or constraints; write [TARGET: what to decide] where a number is needed. Do not describe the feature as unable to make mistakes.

If the notes do not say who sees an output before it reaches a customer, or what happens when the model is unavailable, do not decide it for the team: mark the section [DECISION NEEDED] and put the question first under Open questions.