AI Product Requirements Document: How to Write One

You've approved a short brief, an agent has built the feature, and the demo looks fine. Then a reviewer asks a simple question. What counts as a good answer, who checked the data, and what happens when the model gets it wrong?

If nobody can answer from the document, the problem isn't the model. Your AI product requirements document wasn't ready to build from. A good one turns each requirement into a test, a threshold, a named reviewer, and a release gate that stays active after launch.

AI PRD Template and Writing Order

Write your AI product requirements document in order. Each part gives the next part something solid to check. If you write tests before you define the job, you'll test the wrong thing. If you name owners last, nobody owns the gaps.

Copy this table into your document as headings. Fill in each row before design starts.

Write It in This Order

1. Intended use: Write the one job the feature does, plus two or three things it must never do. Excluded uses stop scope creep before it starts.
2. Users and context: List each role by name, where people use it, what inputs they send, and which languages you support. Don't write "the user" if two roles act differently.
3. Functional behavior: Give three sample inputs with the expected output for each. Add one fallback reply for unclear requests, so the system doesn't guess.
4. Acceptance criteria: Turn each behavior into a pass or fail check. Vague words like "accurate" don't count here.
5. Data rules: Name each source, flag any personal data, set the retention period, and explain how deletion works. If a source isn't listed, the build can't use it.
6. Trustworthiness: Set safety limits, the human override path, and a clear cannot answer, must escalate rule. Add latency and cost budgets for generative features.
7. Owners and gates: Name one reviewer per requirement and the evidence that person must check. No evidence, no approval.
8. Monitoring: Pick the metrics, alert levels, and the rollback trigger now, not after the first incident.

This order matches NIST's AI RMF Playbook guidance, which calls for alignment between technical requirements, system goals, metrics, constraints, ethical considerations, and compliance obligations, with risks and mitigations tracked across the lifecycle.

The cost of skipping this is real. A 2017 empirical study of 49 waterfall projects found that resolving change requests from new requirements increased development effort and defects, and incorrect requirements led to more new requirements and defects.

Completion check: A second reviewer should be able to write the tests and controls from the PRD alone, without asking you what you meant.

Keep the document where reviewers can act on it. When you ask an agent for a plan, it calls the document_create tool, Loupe stores the plan as a document in your project, and the tool returns a review URL.

One Filled Requirement

Say your feature drafts replies to billing questions for support agents. Here's that one feature run through the full template, so you can copy the pattern.

Intended use: Draft replies for questions covered by the billing FAQ only. Excluded uses are refunds, legal claims, and account deletion. That one line does a lot of work. It tells the agent what to build and, just as much, what to refuse.

Functional behavior: A customer asks, "Why was I charged twice?" The draft cites the matching FAQ entry. If no entry matches, it offers to route the case to a human agent instead of inventing an answer.

The Checks Behind It

• Acceptance criteria: At least 90% of 200 approved questions match the reference answer, and 100% of 30 refund prompts get escalated instead of answered.
• Data rules: The FAQ is the only source. No customer records are stored in prompts.
• Trustworthiness: A draft is never sent without a human click. Any reply that quotes a price must be checked by a person first.
• Owner and gate: The support lead approves the release. If any refund prompt gets an answer, the release is blocked. Full stop on that gate, no partial pass.
• Monitoring: Track the weekly escalation rate and complaints about wrong answers. If complaints rise above the agreed level, roll back.

Notice what each line gives a reviewer. There's a source to check, a count to verify, a person who clicks, and a condition that stops the release. Nothing depends on someone remembering a chat thread.

The numbers here are examples, not targets for your product. Set your own from a baseline run on real questions before you freeze the thresholds. A threshold copied from another team tells you nothing about your data, your users, or your risk.

Acceptance Criteria That Test Model Behavior

"Feature complete" doesn't work for AI. Normal software gives the same output every time, so a test can check one exact result. A model varies. The same input can produce a good answer, a weak one, or a confident wrong one, and none of those throw an error.

So each criterion needs three things: a test set, a threshold, and a scoring method. Without all three, an agent can claim success and a reviewer has no way to disagree.

Tests Generative Features Need

Add three sets a normal feature test wouldn't include. Adversarial prompts try to break your rules on purpose, such as asking the system to ignore its limits. Boundary cases cover off-topic, unclear, or unsafe requests. An escalation set lists cases the system must hand to a person instead of answering.

Set budgets for latency and cost per request too. A correct answer that takes too long or costs too much is still a failed requirement. Then write what happens when a limit is missed: block the release, roll back, or send it to a named reviewer. Don't leave that choice to whoever sees the failure first.

Keep the test set in version control next to the PRD. Every change to the feature then runs the same checks, and you can see exactly which version of the tests a release passed.

If an agent can pass the tests without a human guessing what you meant, the criteria are ready.

Review the PRD for Ambiguity Before Build

Most requirement errors surface late, after code exists, when fixes cost the most. A systematic review in IEEE reports that in a study of 26 large financial systems, 44% of analyzed requirements contained errors, subjective language accounted for 34.6% of the reported problem pattern, and inconsistency appeared in 5.9% of cases.

Run this check by hand on your own draft. It takes less time than one rebuild.

The Ambiguity Pass

• Subjective words: Flag "good," "fast," "helpful," and similar terms. Replace each one with a number or a named reviewer.
• Undefined actors: Flag "the user" when two roles exist. Name the role that acts.
• Absolutes and vague amounts: Flag "never," "always," "many," and "large," plus pronouns where the referent isn't clear.

Then rewrite each requirement as condition, action, observable result. "When a refund is requested, the system escalates, and no draft reply is created" can be tested. "Handles refunds well" can't.

Next, check for conflicts across the product, technical, safety, and compliance sections. A latency target in one place can contradict a cost ceiling in another. Add examples and counterexamples for model behavior so a reviewer sees what "correct" looks like and what falls outside it. Then run a scenario review with product, engineering, security, and legal people, using a structured product design review process so each role checks the same draft: product checks intent, engineering checks feasibility, security checks data exposure, and legal checks wording that creates obligations.

Automated tools can triage flagged terms and shorten the list a reviewer reads, but they still miss cases, so expert review stays. Treat tool output as a first pass, not a verdict.

Freeze the version only when every requirement has a test and a named risk owner. Track five metrics: ambiguity rate, clarification cycles, rejected requirements, escaped defects, and PRD-to-build change rate.

Decision Gates for Agent and Human Work

An agent shouldn't have to guess where its authority ends. Write the line down. Some work is safe to proceed alone, and some decisions change risk in ways only a person should accept.

Build three things around this table. First, a responsibility matrix naming one owner each for product, design, engineering, security, and model decisions. Second, the evidence each gate needs, such as test results before release or a data source log before a new source is added. Third, an audit record linking each decision to a PRD version, data source, model, and code change.

One trap is worth naming. A clean tech design can approve itself for every card type, including bug, tooling, and documentation cards. That doesn't mean it should. Your team decides which card types still need a person, and writes that into the gate rules.

This structure has a solid base. The NIST AI Risk Management Framework, released January 26, 2023, organizes risk work into Govern, Map, Measure, and Manage. Map those to your PRD: accountable roles under Govern, users and harms under Map, metrics and thresholds under Measure, and mitigations, monitoring, and rollback under Manage.

Designing these checkpoints well is a workflow problem, not a slogan, which is why a clear human-in-the-loop model for AI agents matters more than a generic promise of oversight. Keep gate rules inside the PRD, not in chat. When a rule changes, log it as a new PRD version and tell the reviewers.

Keep the PRD Alive After Launch

Many teams treat launch as the end of the PRD. For AI, that's when the risk starts moving. The visible feature can stay identical while behavior drifts, because the model, the data, or user inputs changed underneath it.

Research on requirements engineering for AI identifies requirements specification, explainability, and the disconnect between technical teams and end users as leading challenges, and notes that conventional practices fit probabilistic, adaptive systems poorly. Templates that stop at launch leave that gap wide open.

Your living PRD should define five controls:

• Evaluation dataset: The fixed set you re-run, plus new cases from real incidents.
• Pass and fail thresholds: The same numbers from your acceptance criteria, now checked on a schedule.
• Abstention rules: When the system must refuse or escalate instead of answering.
• Monitoring triggers: The metric levels that page a person, tied to solid AI agent observability.
• Rollback conditions: The point where you revert first and debate later.

When the model, data, or policy changes, re-run the full test set before release and log the change in the PRD version history. When an agent changes code without changing the feature description, require a review against the approved requirement anyway. Silent changes are where drift hides.

Review the PRD monthly. Track drift and incident counts, and record residual risk with a named owner. The PRD is a control spec you update, not an archive you file.

Confirm Your PRD Before Your Next Build

Don't rewrite every document you own. Pick one AI feature already in progress and rebuild its PRD with the eight sections.

Run the ambiguity pass on every requirement. Flag subjective words, undefined roles, absolutes, unclear pronouns, and vague numbers. Rewrite each one as condition, action, observable result.

Add one measurable test per behavior, with a test set, threshold, and score. Name a reviewer and a gate for every decision that changes scope, data, or the model. Store the PRD and its test set in version control next to the code.

Review the draft with product, engineering, and security. Freeze it only when every requirement has a test and a named risk owner.

Loupe supports this flow directly. In the product design stage, an agent drafts the product document and a clickable prototype, a second agent reviews the draft first, and you review it before any code. Its MCP endpoint lets AI coding agents create documents and hand back a review URL, and its agent review checks every design and every pull request against the approved design, sending work back for fixes before you see it. Any shared document tool with version history also works.

The final test is simple. If a new team member can read the PRD and know what to build, what to test, and when to stop, it's ready.

---

If your next AI feature needs requirements that survive contact with real agent work, Loupe connects your product document, technical design, implementation, and review in one board with human checkpoints at the gates you define. Start with one feature, turn each requirement into a test, threshold, reviewer, and release gate, and keep the whole chain traceable from first draft to merged pull request.