# AI Feature PRD: [Feature name]

> Product requirements document for a feature powered by a machine
> learning model or large language model. Beyond a normal PRD it covers
> why AI is the right approach, how the experience handles wrong or
> uncertain outputs, model options, data needs, product and model metrics,
> an evaluation plan with acceptance thresholds, responsible AI review,
> human oversight, cost per request, latency, experimentation, monitoring
> and legal review. Based on common industry practice. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write sections 1 to 3 first and get agreement on the problem before
  anyone picks a model. "Use AI" is not a requirement.
- Design the failure states (section 4.3) with the same care as the happy
  path. Every model is wrong some of the time; the PRD must say what the
  user sees then.
- Set acceptance thresholds (section 8) before the first evaluation run,
  so results cannot move the goalposts.
- Hand detail to companion documents: [LLM evaluation plan], [Prompt
  specification], [ML system design], [AI risk assessment], [DPIA].
-->

## Document control

<!-- Guidance: Identify the version, owner and the people who must sign off before build and before launch. -->

| Field | Value |
|---|---|
| Document ID | [PRD-AI-001] |
| Feature | [Feature name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved for build / Approved for launch] |
| Product owner | [@pm] |
| Engineering lead | [@eng-lead] |
| ML / AI lead | [@ml-lead] |
| Design lead | [@designer] |
| Last updated | YYYY-MM-DD |
| Target launch | YYYY-MM-DD |

### Approvals

| Role | Name | Gate | Decision | Date |
|---|---|---|---|---|
| Product owner | [@name] | Build | [Approve / Reject] | YYYY-MM-DD |
| Engineering lead | [@name] | Build | [Decision] | YYYY-MM-DD |
| Responsible AI reviewer | [@name] | Launch | [Decision] | YYYY-MM-DD |
| Privacy / legal | [@name] | Launch | [Decision] | YYYY-MM-DD |
| Security | [@name] | Launch | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Note especially changes to scope, thresholds or model choice. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added confidence display after usability test |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for build |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Problem and users](#1-problem-and-users)
2. [Goals and non-goals](#2-goals-and-non-goals)
3. [Why AI](#3-why-ai)
4. [User experience](#4-user-experience)
5. [Requirements](#5-requirements)
6. [Model and approach options](#6-model-and-approach-options)
7. [Data needs](#7-data-needs)
8. [Success metrics and evaluation](#8-success-metrics-and-evaluation)
9. [Responsible AI and human oversight](#9-responsible-ai-and-human-oversight)
10. [Cost and latency](#10-cost-and-latency)
11. [Rollout and experimentation](#11-rollout-and-experimentation)
12. [Monitoring](#12-monitoring)
13. [Legal, privacy and security](#13-legal-privacy-and-security)
14. [Launch checklist](#14-launch-checklist)
15. [Open questions and appendix](#15-open-questions-and-appendix)

## 1. Problem and users

<!-- Guidance: Describe the user problem with evidence: research, support data, usage data. Name the users and the moment the problem occurs. -->

### 1.1 Problem statement

[Who has what problem, when, and what it costs them.] *Example:* Small
business owners using our invoicing app spend a median of 11 minutes per
week categorising expenses by hand; 34% of expenses stay uncategorised at
month end, which breaks their tax reports.

### 1.2 Evidence

| Source | Finding |
|---|---|
| *Example:* Usage analytics (90 days) | 2.1 million expenses created; 34% uncategorised after 30 days |
| *Example:* 12 user interviews | 9 of 12 named categorisation as the most tedious task |
| *Example:* Support tickets | 6% of tickets about wrong tax totals trace back to missing categories |

### 1.3 Users and personas

| Persona | Context | Need |
|---|---|---|
| *Example:* Sole trader | Uploads receipts from phone | Fast, mostly correct categories without thinking |
| *Example:* Bookkeeper | Manages 20 client accounts | Bulk review, control and an audit trail |

## 2. Goals and non-goals

<!-- Guidance: Goals are outcomes, not features. Non-goals stop scope creep. -->

| Goals | Non-goals |
|---|---|
| *Example:* Cut uncategorised expenses at month end from 34% to under 10% | Giving tax advice |
| *Example:* Keep users in control: every suggestion is visible and reversible | Auto-filing tax returns |
| *Example:* Work on mobile and web | Supporting scanned paper ledgers in v1 |

## 3. Why AI

<!-- Guidance: Show that simpler approaches were considered. AI adds cost, uncertainty and review burden; justify it. -->

| Approach | Coverage | Accuracy | Effort | Verdict |
|---|---|---|---|---|
| *Example:* Rules on merchant name | 48% of expenses | 97% on covered | Low | Keep as first layer |
| *Example:* User-defined rules | 15% more | High | Users rarely create rules | Keep as override |
| *Example:* Classification model on merchant, amount, memo | 95% | 88% top-1 estimated | Medium | Selected for the rest |

[Summarise why AI is needed and what happens if it underperforms.]
*Example:* Rules cover half of expenses; the long tail of merchants needs a
learned model. If accuracy falls below threshold, the feature falls back to
rules only.

## 4. User experience

<!-- Guidance: Show the main flow, then every non-ideal state. Specify how uncertainty is shown and how users correct the AI. -->

### 4.1 Main flow

1. User adds an expense (photo, bank import or manual).
2. System suggests a category within [1] second and marks it as suggested.
3. User accepts with one tap, picks another category, or ignores.
4. Corrections are stored and used to personalise future suggestions.

```mermaid
flowchart LR
  A["Expense added"] --> B{"Rule match?"}
  B -- yes --> C["Category set (rule)"]
  B -- no --> D["Model suggestion"]
  D --> E{"Confidence >= 0.80?"}
  E -- yes --> F["Show as suggested"]
  E -- no --> G["Show top 3 choices"]
  F --> H["User accepts or edits"]
  G --> H
  H --> I["Store feedback"]
```

### 4.2 Uncertainty display

| Confidence | Display | Behaviour |
|---|---|---|
| *Example:* >= 0.80 | Category with "Suggested" label | One-tap accept |
| *Example:* 0.50 to 0.79 | Top 3 categories as chips | User must choose |
| *Example:* < 0.50 | "Choose a category" | No suggestion shown |

### 4.3 Failure and edge states

| State | What the user sees | Notes |
|---|---|---|
| Wrong suggestion accepted | Edit at any time; change history shows "suggested by AI" | Bulk undo for bookkeepers |
| Model unavailable | Rules still work; others show "Choose a category" | No error dialog |
| Slow response | Suggestion appears when ready; never blocks saving | Timeout [2] s |
| Sensitive category (for example medical) | No auto-suggestion | Privacy rule |
| New user, no history | Generic model only | Personalisation after [20] corrections |

### 4.4 Transparency and control

[*Example:* An info icon explains "Categories are suggested by an
automated model based on merchant and amount. Check them before filing."
Settings let users turn suggestions off.]

## 5. Requirements

<!-- Guidance: Number requirements so they can be traced to tests. Include non-functional requirements specific to AI. -->

| ID | Requirement | Priority | Verification |
|---|---|---|---|
| FR-01 | The system shall suggest a category for each new expense not matched by a rule | Must | Functional test |
| FR-02 | The system shall show suggestions as visibly distinct from user-set values | Must | UI review |
| FR-03 | Users shall be able to accept, change or dismiss a suggestion in one action | Must | Usability test |
| FR-04 | Bookkeepers shall be able to review all AI-set categories in a filtered list | Should | Functional test |
| NFR-01 | p95 suggestion latency shall be at most 800 ms | Must | Load test |
| NFR-02 | Top-1 accuracy on the held-out set shall be at least 0.88 | Must | Offline evaluation |
| NFR-03 | No customer data shall be used to train shared models without opt-in | Must | Privacy review |

## 6. Model and approach options

<!-- Guidance: Compare at least two options on quality, cost, latency, privacy and maintainability. Record the decision and what would change it. -->

| Option | Quality (est.) | Cost / 1k requests | p95 latency | Privacy | Verdict |
|---|---|---|---|---|---|
| *Example:* Gradient-boosted classifier, self-hosted | 0.86 top-1 | $0.02 | 40 ms | Data stays in region | Fallback |
| *Example:* Fine-tuned small transformer, self-hosted | 0.90 | $0.10 | 120 ms | Data stays in region | **Selected** |
| *Example:* Hosted LLM, zero-shot with category list | 0.84 | $1.80 | 1,400 ms | Data sent to vendor | Rejected: cost and latency |

Decision: [*Example:* fine-tuned small transformer. Revisit if top-1 drops
below 0.86 or if multilingual support is required.]

## 7. Data needs

<!-- Guidance: List the data for training, evaluation and runtime, with its source, legal basis and quality issues. -->

| Data | Purpose | Source | Volume | Legal basis / consent | Issues |
|---|---|---|---|---|---|
| *Example:* Historical categorised expenses | Training | Product database | 3.4 M rows | Contract + opt-in for shared model | Label noise from bulk edits |
| *Example:* Held-out set, re-labelled | Evaluation | Sample of 5,000 | 5,000 | Same | Two annotators, kappa >= 0.8 |
| *Example:* Merchant, amount, memo | Runtime features | Live expense | Per request | Contract | Memos may contain personal data |

See [Datasheet for the training dataset] for full documentation.

## 8. Success metrics and evaluation

<!-- Guidance: Separate product metrics (user outcome), model metrics (offline quality) and guardrail metrics (things that must not get worse). -->

### 8.1 Metrics

| ID | Metric | Type | Baseline | Target |
|---|---|---|---|---|
| M-01 | *Example:* Uncategorised expenses at month end | Product | 34% | < 10% |
| M-02 | *Example:* Suggestion acceptance rate | Product | n/a | >= 75% |
| M-03 | *Example:* Top-1 accuracy (held-out) | Model | n/a | >= 0.88 |
| M-04 | *Example:* Accuracy gap between smallest and largest business segment | Fairness | n/a | <= 5 points |
| G-01 | *Example:* Support tickets about wrong categories | Guardrail | 6% | Not higher |

### 8.2 Evaluation plan and acceptance thresholds

| Stage | Method | Pass threshold | Owner |
|---|---|---|---|
| Offline | Held-out set, stratified by segment and language | M-03 and M-04 met | @ml-lead |
| Dogfood | Internal accounts for 2 weeks | No severity-1 issues | @pm |
| A/B test | 10% of new expenses | M-02 >= 75%; G-01 not worse at 95% confidence | @data-scientist |

The minimum sample per arm to detect a change of $\delta$ in a proportion
$p$ with significance $\alpha$ and power $1-\beta$ is approximately

$$
n \approx \frac{2\,(z_{1-\alpha/2} + z_{1-\beta})^{2}\, p(1-p)}{\delta^{2}}
$$

*Example:* $p = 0.06$, $\delta = 0.01$, $\alpha = 0.05$, $1-\beta = 0.8$
gives $n \approx 2 \times 7.85 \times 0.0564 / 0.0001 \approx 8{,}860$ per arm.

## 9. Responsible AI and human oversight

<!-- Guidance: Record who could be harmed and how, which checks were done, and where humans stay in control. Link to the AI risk assessment for the full register. -->

| Topic | Assessment | Mitigation |
|---|---|---|
| Harm from errors | *Example:* Wrong categories can lead to incorrect tax filings | Suggestions labelled; review list; never auto-file |
| Fairness | *Example:* Lower accuracy for non-English memos | Segment metrics; threshold M-04 |
| Transparency | *Example:* Users must know a suggestion is automated | Label and info text (4.4) |
| Over-reliance | *Example:* Users accept without checking | Monthly "review AI categories" prompt |
| Human oversight | *Example:* Users and bookkeepers can override every suggestion; disable switch per account | Settings toggle |
| Regulatory classification | *Example:* Not a high-risk use under the EU AI Act per legal review | Re-check if scope changes |

## 10. Cost and latency

<!-- Guidance: Compute the cost per request and per month at expected volume, and the latency budget per step. -->

For a self-hosted model, cost per request is driven by GPU time. With
instance cost $c_h$ per hour and sustained throughput $r$ requests per
second per instance at target utilisation $u$:

$$
C_{\text{req}} = \frac{c_h}{3600 \cdot r \cdot u}
$$

*Example:* $c_h = \text{\textdollar}1.20$, $r = 150$, $u = 0.6$ gives
$C_{\text{req}} \approx \text{\textdollar}0.0000037$, about $\text{\textdollar}0.004$ per thousand
requests; at 2.5 million requests per month, about $\text{\textdollar}9$ plus a fixed
minimum of two instances ($\approx \text{\textdollar}1{,}730$ per month).

| Step | p95 budget |
|---|---|
| Rule engine | 20 ms |
| Feature lookup | 60 ms |
| Model inference | 150 ms |
| Network and rendering | 300 ms |
| **Total** | **<= 800 ms** |

## 11. Rollout and experimentation

<!-- Guidance: Plan stages, audiences, guardrails and the rollback switch. -->

| Stage | Audience | Duration | Go criteria |
|---|---|---|---|
| Internal | Staff accounts | 2 weeks | No severity-1 bugs |
| A/B | 10% of new expenses | 3 weeks | Thresholds in 8.2 |
| Ramp | 50%, then 100% | 2 weeks | Guardrails stable |

Rollback: [*Example:* feature flag `expense_ai_suggest` off returns to
rules only within one minute; stored suggestions stay labelled].

## 12. Monitoring

<!-- Guidance: Watch model quality, drift, product metrics and cost after launch, with owners and thresholds. -->

| Signal | Threshold | Action | Owner |
|---|---|---|---|
| Acceptance rate (7-day) | *Example:* < 70% | Investigate drift | @ml-lead |
| Input drift (merchant mix) | *Example:* PSI > 0.2 | Retrain review | @ml-lead |
| p95 latency | > 800 ms for 30 min | Page on-call | @eng-lead |
| Segment accuracy gap | > 5 points | Fairness review | @responsible-ai |
| Cost per month | > 120% of budget | Review capacity | @eng-lead |

## 13. Legal, privacy and security

<!-- Guidance: Summarise the reviews and their outcomes; link the full documents. -->

| Review | Outcome | Link |
|---|---|---|
| Privacy (DPIA screening) | *Example:* DPIA not required; memos minimised before inference | [Link] |
| Data use terms | *Example:* Opt-in for shared training added to settings | [Link] |
| Security | *Example:* Model endpoint internal only; inputs validated | [Link] |
| Vendor review | *Example:* Not applicable (self-hosted) | [Link] |
| User-facing disclosures | *Example:* Help article and in-product label approved | [Link] |

## 14. Launch checklist

<!-- Guidance: Every item needs evidence before launch approval. -->

| Item | Evidence | Done |
|---|---|---|
| Offline thresholds met | [Evaluation report] | [ ] |
| Failure states implemented and tested | [Test run] | [ ] |
| A/B results reviewed | [Analysis] | [ ] |
| Responsible AI review signed off | [Link] | [ ] |
| Privacy and legal sign-off | [Link] | [ ] |
| Monitoring dashboards and alerts live | [Dashboard] | [ ] |
| Support team briefed; help article published | [Link] | [ ] |
| Rollback tested | [Record] | [ ] |

## 15. Open questions and appendix

<!-- Guidance: Track unresolved questions with owners and dates; add glossary and links. -->

| ID | Question | Owner | Due |
|---|---|---|---|
| Q-01 | [Should bookkeepers be able to train client-specific models?] | [@name] | YYYY-MM-DD |
| Q-02 | [Which languages for v2?] | [@name] | YYYY-MM-DD |

| Term | Meaning |
|---|---|
| Top-1 accuracy | Share of cases where the highest-scored category is correct |
| Acceptance rate | Share of shown suggestions the user keeps |
| PSI | Population stability index, a measure of distribution shift |
| Guardrail metric | A metric that must not get worse when the feature launches |

## Standard and licence note

Based on common industry practice for product requirements of AI-powered
features, including standard sample-size estimation for A/B tests.
Original text written for this collection; example numbers and prices are
illustrative. Template licence: MIT.