Who Should Complete This Template
This template is designed to be completed by a product manager or founder in collaboration with a technical lead. Section 1 (Purpose and Scope) can be completed by non-technical stakeholders. Sections 3-5 (Model Selection, Prompt Architecture, Data Requirements) require input from someone with AI/ML experience - either your internal team or your development partner. Section 6 (Evaluation Criteria) is the most important section and is often skipped. Do not skip it. Without defined evaluation criteria, you cannot objectively assess whether your AI feature is working. Section 7 (GDPR and Compliance) should be reviewed by a legal or compliance professional if your product handles personal data.
How to Use This Template
Step 1: Complete Sections 1 and 2 (Purpose, User Stories) before involving technical stakeholders. Step 2: Hold a technical spike session with your development team to complete Sections 3-5. A spike is a short (1-2 day) investigation to test feasibility before committing to full development. Step 3: Define evaluation criteria in Section 6 before writing any prompts. What does 'good' look like? What does 'unacceptable' look like? Step 4: Complete Section 7 with your DPO or legal counsel if personal data is involved. Step 5: Share the completed spec with all engineers working on the feature and get written sign-off. Step 6: Review and update the spec after each major iteration or model change.
The AI Product Spec Template (Blank Version)
--- AI PRODUCT SPEC --- Document version: [v1.0] Date: [DD/MM/YYYY] Feature name: [Name of the AI feature] Product: [Product or application this feature sits within] Prepared by: [Name, Role] Technical reviewer: [Name, Role] SECTION 1: PURPOSE AND SCOPE 1.1 Feature description (2-3 sentences) What does this AI feature do, and what problem does it solve for the user? [Write here] 1.2 Primary use case Describe the main scenario in which a user will interact with this feature. [Write here] 1.3 Secondary use cases (optional) - [Secondary use case 1] - [Secondary use case 2] 1.4 Out of scope What will this AI feature explicitly NOT do? - [Out of scope item] - [Out of scope item] SECTION 2: USER STORIES Format: As a [user type], I want to [action], so that [benefit]. Primary user story: As a [user type], I want to [action], so that [benefit]. Acceptance criteria: - Given [context], when [action], then [expected AI output or behaviour] - Given [context], when [action], then [expected AI output or behaviour] - Given [edge case], when [action], then [fallback behaviour] SECTION 3: MODEL AND ARCHITECTURE 3.1 Recommended AI approach [ ] Large Language Model (LLM) - text generation/analysis [ ] Retrieval-Augmented Generation (RAG) - LLM + knowledge base [ ] Fine-tuned model - custom training on domain data [ ] Classification model - categorisation or labelling [ ] Multi-modal model - text + image/audio/video [ ] Agentic / multi-step reasoning 3.2 Recommended model (primary) Model: [e.g. GPT-4o, Claude 3.5 Sonnet, Mistral 7B fine-tuned] Provider: [OpenAI / Anthropic / self-hosted] Rationale: [Why this model for this use case?] 3.3 Fallback model (if primary unavailable) Model: [e.g. GPT-4o-mini] Trigger for fallback: [e.g. primary model rate limit, latency > 10s] 3.4 Architecture pattern [ ] Direct API call (simple prompt-response) [ ] RAG pipeline (embed, retrieve, generate) [ ] Agent loop (tool use, multi-step reasoning) [ ] Batch processing (async, no real-time requirement) Additional architecture notes: [Write here] 3.5 Latency requirements Acceptable response time for user-facing output: [e.g. < 5 seconds] Acceptable response time for background processing: [e.g. < 60 seconds] SECTION 4: PROMPT ARCHITECTURE 4.1 System prompt (draft) Write the initial system prompt that defines the AI's role, constraints, and behaviour. [Draft system prompt here. Include: role definition, output format requirements, constraints, tone, and any safety rules.] 4.2 User message structure Describe how user input will be formatted before sending to the model. Fixed prefix: [Any text prepended to every user message] User input: [Description of what the user provides] Fixed suffix: [Any text appended to every user message] Injected context: [Dynamic data injected into the prompt, e.g. user profile, document content] 4.3 Output format specification Expected output format: [ ] Free text [ ] JSON [ ] Markdown [ ] Structured list [ ] Other: [specify] If JSON: provide the expected schema: { "field_name": "description of field and data type", "field_name": "description of field and data type" } Maximum output tokens: [e.g. 1000 tokens] Handling of refusals: [What should happen if the model declines to answer?] 4.4 Prompt variables (dynamic injection points) | Variable | Source | Example value | |----------|--------|---------------| | {user_name} | User profile | Sarah Chen | | {document_content} | Uploaded file | [Contract text] | | {company_name} | Account settings | FieldPulse Ltd | SECTION 5: DATA REQUIREMENTS 5.1 Input data Data type: [e.g. user-uploaded PDF, form submission, database record] Format: [e.g. plain text extracted from PDF, JSON object] Maximum size: [e.g. 100,000 tokens per request] Pre-processing required: [e.g. PDF-to-text conversion, PII redaction, chunking strategy] 5.2 Knowledge base (if RAG) Data sources: [List of documents, databases, or APIs that will be embedded] Embedding model: [e.g. text-embedding-3-small] Vector database: [e.g. Pinecone, pgvector on Supabase] Refresh frequency: [How often is the knowledge base updated?] Chunk size: [e.g. 500 tokens with 50-token overlap] 5.3 Data that must NOT be sent to the model - [e.g. NHS numbers, financial account numbers] - [e.g. passwords or authentication tokens] - [e.g. third-party confidential data without consent] 5.4 Data retention Logs of model inputs retained for: [e.g. 30 days, never] Logs of model outputs retained for: [e.g. 30 days, 1 year for audit] User data used for model training: [ ] Yes [ ] No [ ] Only with explicit opt-in SECTION 6: EVALUATION CRITERIA 6.1 Primary quality metric Metric name: [e.g. Accuracy, F1 score, User satisfaction score, Task completion rate] Measurement method: [How will you measure this? Manual review? Automated test suite? User survey?] Target threshold (acceptable): [e.g. > 80%] Target threshold (excellent): [e.g. > 95%] 6.2 Secondary quality metrics | Metric | Method | Acceptable | Excellent | |--------|--------|------------|-----------| | [Metric] | [Method] | [Value] | [Value] | | [Metric] | [Method] | [Value] | [Value] | 6.3 Failure modes to test List specific scenarios where the AI is expected to fail, behave unexpectedly, or require special handling. - [Failure mode 1]: Expected behaviour: [What should happen?] - [Failure mode 2]: Expected behaviour: [What should happen?] - [Hallucination scenario]: Expected behaviour: [How does the system detect and handle this?] - [Out-of-scope query]: Expected behaviour: [Graceful refusal message?] 6.4 Human-in-the-loop requirements Is human review required before AI output is shown to the end user? [ ] Always [ ] For high-stakes outputs only [ ] Never If yes, who reviews? [Role name] What is the review SLA? [e.g. within 4 hours] SECTION 7: GDPR AND COMPLIANCE 7.1 Does this feature process personal data? [ ] Yes [ ] No [ ] Uncertain (requires legal review) 7.2 Lawful basis for processing (if yes) [ ] Consent [ ] Contract performance [ ] Legitimate interest [ ] Legal obligation 7.3 Data subjects affected [List categories of people whose data may be processed, e.g. end users, third parties named in documents] 7.4 Third-party model provider as data processor Provider: [e.g. OpenAI, Anthropic] DPA in place: [ ] Yes [ ] No [ ] In progress Data residency: [e.g. EU only, US with SCCs, UK GDPR compliant] Data used for training by provider: [ ] Yes [ ] No (specify contractual basis) 7.5 EU AI Act risk classification (if applicable) [ ] Unacceptable risk (prohibited) [ ] High risk [ ] Limited risk [ ] Minimal risk Risk classification rationale: [Brief justification] SECTION 8: MONITORING AND ALERTS 8.1 Metrics to monitor in production - Latency: Alert if p95 response time > [threshold] - Error rate: Alert if model API errors > [X%] of requests - Cost: Alert if daily API spend > GBP [amount] - Quality drift: Alert if [metric] falls below [threshold] in weekly review 8.2 Rollback plan If the feature degrades in production, what is the rollback plan? [e.g. Disable AI feature and show manual fallback UI within 30 minutes of alert] --- END OF TEMPLATE ---
Filled Example: ContractCheck AI (B2B Legal SaaS Feature)
SECTION 1: PURPOSE AND SCOPE 1.1 Feature description ContractCheck is an AI-powered contract review feature embedded in a B2B legal SaaS platform. It analyses uploaded contract PDFs, identifies standard and non-standard clauses, flags potentially unfavourable terms, and produces a plain-English risk summary for non-lawyer business users. 1.2 Primary use case A startup founder uploads a supplier contract (NDA, SaaS agreement, or service contract) and receives a structured risk report within 60 seconds, without needing to engage a solicitor for initial review. SECTION 3: MODEL AND ARCHITECTURE 3.2 Recommended model Model: Claude 3.5 Sonnet (claude-3-5-sonnet-20241022) Provider: Anthropic Rationale: Superior instruction-following for structured JSON output, strong legal domain performance in benchmarks, 200k context window handles full contracts without chunking, GDPR-compliant EU data processing available via Anthropic's enterprise API. 3.4 Architecture pattern: RAG pipeline Full contracts are chunked at 800 tokens with 100-token overlap, embedded using text-embedding-3-small, stored in pgvector (Supabase). Retrieval surfaces the 10 most relevant clauses. The LLM then analyses the retrieved clauses against a system prompt containing standard clause definitions. 4.1 System prompt (draft) You are a legal contract analysis assistant for UK business contracts. Your role is to review contract clauses provided to you and identify: (1) clauses that deviate significantly from market-standard terms, (2) clauses that create unusual or disproportionate obligations for the user's business, and (3) missing standard protections. You must not provide legal advice. Always state that the user should consult a qualified solicitor before signing. Output your analysis as a JSON object following the schema provided. If you are uncertain about a clause, flag it for human review rather than guessing. 6.1 Primary quality metric Metric: Clause identification accuracy Measurement: Manual review of 50 contracts per month by a qualified solicitor, scoring AI findings against ground truth Acceptable: > 80% of material risk clauses identified Excellent: > 95% of material risk clauses identified with < 10% false positive rate 6.3 Failure modes - Highly technical industry-specific clauses (e.g. IP assignments in biotech): Flag for solicitor review, do not attempt to categorise - Contracts in languages other than English: Decline with message directing user to translation service - Hallucinated legal references: System prompt instructs model to never cite specific case law unless it is explicitly present in the uploaded document
Variations for Different AI Feature Types
For AI Chatbots and Copilots: Focus Section 4 (Prompt Architecture) on conversation memory design, context window management, and multi-turn handling. Add a conversation flow diagram. For Classification and Labelling Features: Section 6 (Evaluation Criteria) becomes the central document. Define your label taxonomy before writing any prompts. Establish ground truth datasets of at least 100 labelled examples before development begins. For RAG-based Knowledge Assistants: Section 5.2 (Knowledge Base) is critical. Define your chunking strategy, embedding model, and retrieval scoring threshold. For Agentic / Multi-Step Features: Add a Section 9 covering tool definitions, tool call sequences, error handling between steps, and human approval gates for irreversible actions (e.g. sending emails, processing payments). For EU AI Act High-Risk Systems: Section 7.5 triggers the full EU AI Act Risk Assessment Template (linked below). High-risk systems require a conformity assessment before deployment.