How to Write AI Requirements: The Spec Owner Pattern Explained

Writing requirements for an AI system is one of those things that sounds straightforward until you try to do it. You open your usual requirements template, start filling it in, and realize that every section is wrong. "The system shall..." doesn't work when the system's output is probabilistic. Acceptance criteria can't be pass/fail when the answer is a generated response. And "user story" assumes the system does a specific thing, when the AI decides what to do.

The Specify document — and the Spec Owner pattern — is the answer. Here's how it works.

## Why traditional requirements fail for AI

A traditional functional requirement looks like this:

> *When the user clicks "Recommend," the system shall display the top 3 product recommendations based on the user's purchase history, sorted by relevance score descending.*

This works because the behavior is deterministic. You can implement it exactly. You can test it exactly.

An AI requirement can't work this way, because:

1. The AI's output varies by input in ways you can't enumerate in advance 2. "Relevance" is a judgment the model makes, not a rule you program 3. There's no single "correct" recommendation — there's a range of acceptable ones 4. The AI might be right 85% of the time and wrong 15% — but *which* 15% matters enormously

The Specify document handles this by defining constraints on the system's decision-making, rather than specifying its outputs directly.

## The Spec Owner pattern

The Spec Owner is the person who writes and owns the Specify document. In most AI projects, this is the PM or BA responsible for the feature.

The Spec Owner's job is not to understand how the AI works technically. It's to define the rules the AI must follow — what it's allowed to decide, what it must never do, when humans must be involved, and how good it needs to be before it ships.

Think of it like a constitution for your AI. Engineering implements it. QA tests whether it's been followed. The Spec Owner wrote it and signs off when it's been met.

## The five-field Specify document

The Specify document has five required fields:

---

### 1. Obligations

**What it is**: Everything the AI *must* do on every response.

**Why it matters**: These are your non-negotiable baseline behaviors. If the AI doesn't do these, something is wrong.

**Example** (customer service AI): - Always acknowledge the customer's issue in the first sentence - Always surface a case number if one exists in the system - Always include a clear next action ("Your refund will process in 3–5 business days") - Always state explicitly when the AI doesn't know something

**How to write it**: Start with "Always..." or "Must..." for each obligation. Be specific enough that an engineer can implement it and a QA engineer can test it.

---

### 2. Prohibitions

**What it is**: Things the AI must *never* do, regardless of what the user asks.

**Why it matters**: This is your guardrail list. These aren't "try to avoid" — they're hard constraints. Violating a prohibition is a system failure.

**Example** (customer service AI): - Never speculate about a customer's account status without accessing the live account system - Never promise a refund that exceeds $500 without human approval - Never reference competitor products by name - Never continue a conversation if the customer has expressed suicidal ideation — route to a human immediately with a documented protocol

**How to write it**: Start with "Never..." or "Must not..." Use concrete thresholds where possible (the $500 example). Include edge cases that your team has debated.

---

### 3. Handoff triggers

**What it is**: The specific conditions under which the AI must hand the conversation or decision to a human.

**Why it matters**: Every AI system needs a defined escalation path. If you don't define it in the Spec, the AI will either escalate everything (useless) or escalate nothing (dangerous).

**Example** (customer service AI): - Handoff trigger: Customer expresses anger for two or more consecutive turns - Handoff trigger: Request involves a refund over $500 - Handoff trigger: Customer mentions legal action or regulatory complaint - Handoff trigger: AI confidence falls below 70% on a factual claim about account status - Handoff trigger: Customer asks for something the AI explicitly cannot do

**How to write it**: Be specific about the trigger condition. "When the customer is upset" is not specific enough. "When the customer uses profanity in two consecutive messages" is.

---

### 4. Fallback behavior

**What it is**: What the AI does when it genuinely cannot answer — not when it's wrong, but when it's out of scope or uncertain.

**Why it matters**: An AI that says "I don't know" clearly is dramatically better than one that hallucates a confident-sounding wrong answer. The fallback behavior defines what "I don't know" looks like.

**Example** (customer service AI): - When the query is outside scope: "I'm set up to help with [X, Y, Z]. For [out-of-scope topic], please contact [department] at [contact]. Is there something else I can help with?" - When confidence is low on a factual claim: "I want to make sure I give you accurate information. Let me connect you with someone who can confirm this directly." - When the session times out: "I haven't heard from you in a while. Your case number is [X] — you can reference this when you reconnect."

**How to write it**: Write the actual response text for each fallback scenario, or at minimum the constraints on what it must contain.

---

### 5. Eval threshold

**What it is**: The specific pass rate the AI must achieve before it ships.

**Why it matters**: If you don't define this before the build, you'll negotiate it under launch pressure. Setting it at Framing makes it a real standard.

**Example** (customer service AI): - Accuracy on golden set: ≥ 90% (defined as: the correct information is conveyed, regardless of phrasing) - Safety on prohibition scenarios: 100% (any prohibition violation is a NO-GO) - Handoff trigger activation: ≥ 95% (the AI must correctly identify handoff conditions) - Tone appropriateness: ≥ 85% (human reviewer panel of 3, scored blind)

**How to write it**: Define each dimension separately. Specify the threshold number and who evaluates it. Make safety-critical items absolute (100%), not percentage-based.

---

## A real Specify document looks like this

Here's a condensed example for a hypothetical AI feature that recommends courses to a student:

---

**System**: Course Recommendation AI **Spec Owner**: [Your name] **Version**: 1.0 **Date**: 2026-06-28

**Obligations** - Must return at least one recommendation on every query - Must explain why each recommendation is relevant to the student's stated goal - Must surface the time commitment (hours/week) for each recommended course - Must display confidence level ("Strong match" / "Good match" / "Possible match")

**Prohibitions** - Must never recommend a course the student has already completed - Must never recommend a course that requires a prerequisite the student hasn't met, without disclosing the prerequisite gap - Must never claim a course leads to a specific salary outcome - Must never recommend more than 3 courses in a single response

**Handoff triggers** - If student mentions they're in financial hardship, surface scholarship options and flag for human advisor follow-up - If student asks for personalized career counseling beyond course selection, route to human advisor - If student indicates they're on a performance improvement plan, flag for advisor (confidential handling required)

**Fallback behavior** - If no matching courses: "I don't have courses that match exactly what you're looking for right now. Here's what's closest — [options] — and here's what's coming in next quarter that might be a better fit — [pipeline items]." - If student query is ambiguous: Ask one clarifying question, then recommend.

**Eval threshold** - Recommendation relevance: ≥ 85% (student panel of 20, blind scored) - Prohibition compliance: 100% - Prerequisite accuracy: 100% - Fallback appropriateness: ≥ 90%

---

## What to do with the Specify document

Once written, the Specify document: - Gates the Architecture phase (don't start architecture until it exists) - Is the primary reference during Build when edge cases require decisions - Forms the basis of the QA golden set - Is reviewed against eval results before the go/no-go call - Lives in the incident playbook for Production

It's not a one-time artifact. It evolves — but every change requires a decision log entry and re-approval by the Spec Owner.

[Learn how to write a Specify document in the Forward Deployed Studio →](https://forwarddeployed.app/seminars)