---
title: PRD template
route: /resources/prd-template
lang: en
part_of: Onirion
version: "4.0"
date: 2026-09-22
author: Alexis Boyer
license: CC BY 4.0
one_line: The one template the method fills. Every gate after the second one reads it.
kind: template
gate: 2
layers:
  summary: /resources/prd-template
  complete_text: /complete.md
  markdown: /resources/prd-template.md
---

<!-- source: public-kit/templates/prd.md -->

# Product requirements document — the template

**A method by Alexis Boyer · version 4.0 · September 22, 2026**

Gate 2 fills this template; the filled PRD lives in the project folder beside the project memory and the project journal and moves into `docs/` with them when the code starts, and it is what the coding agent reads at every gate after this one.

## 1. Strategic framing

*In a few lines, say what the product is going to be: what is wanted, what is not wanted, the boundary it holds and the business loop it serves.*

- What this product is going to be:
- What is wanted from it:
- What is explicitly not wanted:
- The business loop it serves:
- The constraints that shape it:
- What the sections below detail:

## 2. Product boundary

*Draw the line around the product: who it serves, what belongs elsewhere, and what it must never expose.*

- Who the product is for:
- Who it is not for:
- Workflows that belong in another product:
- What the product must never expose:
- Shared core or backend objects assumed:
- Non-goals:
- How an out-of-scope workflow is represented here instead (safe status, handoff, request state):

## 3. Roles and permissions

*Write out every role, including two roles that differ by a single screen.*

| Role | What they do | What they can see | What they must not see | What they can do |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |
|  |  |  |  |  |

- Where role differences change navigation, actions, disabled states or empty states:
- How a role is granted, changed and removed:

## 4. Core workflows

*List each workflow the product exists to carry, from its entry point to its final state.*

- Workflow:
- Who runs it:
- Entry point:
- Steps:
- Branches:
- Failures and how they end:
- Confirmations:
- Final state:

## 5. Product states and data visibility

*Name the states each object moves through, what moves it, and what is visible in each state to each role.*

- Object:
- Its states, in order:
- What moves it from one state to the next:
- Terminal states, and what reopens them:
- What each role sees in each state:
- What is hidden in each state, and from whom:

## 6. Privacy and ethics rules

*Say which data is sensitive and how it must be handled; this controls the interface, the data model, search, exports, backend read models and QA.*

- Sensitive data held or displayed here:
- How each kind must be handled:
- What must never be shown, and to whom:
- Rules for search, filters and exports:
- Rules for what may reach the browser at all:
- Controlled exceptions, with the fields each one is allowed:
- The intake path for a request to see sensitive data:
- Retention and deletion expectations:

## 7. Which source wins when sources disagree

*Write the order down, most authoritative first, so an agent does not overfit to an outdated document.*

1. 
2. 
3. 
4. 
5. 
6. 

- What must be checked before an old backlog ticket is used:
- Who records a change to this order, and where:

## 8. Design baseline and acceptable drift

*Name the design reference this product follows and the drift that is acceptable; the design itself arrives at Gate 3, so state here what is assumed and what must be requested.*

Assumed now:

- The design reference this product follows (design system, or a named reference product standing in for one):
- Its version or location, as known today:
- What counts as non-negotiable in it:
- What counts as acceptable drift from it:
- Where the prototype and the front end must draw on the same reference:

To request from Design Ops:

- The components and their states:
- The tokens and the rules for using them:
- What may be extended and what may not:
- Who maintains the system:
- An agent-readable form of the above:
- The named owner of each request, and the date the answer is needed:
- What is being followed in the meantime, and with whose agreement:

## 9. Functional depth

*Say which flows must really work in the front-only prototype and which may stay placeholders.*

- Flows that must work end to end in the front-only prototype:
- Flows that may stay placeholders, scoped on purpose:
- What each clickable surface does, where a user can click it:
- Simulated states deliberately allowed, and their limits:
- States required everywhere: empty, loading, validation error, permission-denied, confirmation, success and failure:

## 10. Backlog taxonomy

*Keep these categories apart, so an undecided question is not coded around as if it were a defect.*

| Category | What belongs in it here | Where it is tracked | Who owns it |
| --- | --- | --- | --- |
| Product decisions |  |  |  |
| Implementation tasks |  |  |  |
| Design parity issues |  |  |  |
| Privacy and legal guardrails |  |  |  |
| QA findings |  |  |  |
| Backend integration work |  |  |  |
| Future nice-to-haves |  |  |  |

## 11. Backend and API assumptions

*Separate what this product assumes the backend already does from what has to be requested, since the contracts are obtained at Gate 4 and the connection is made at Gate 5.*

Assumed now:

- Backend objects, state machines and workflow contracts assumed:
- Authentication and permission rules assumed:
- The business meaning of key fields and status values, as understood here:
- APIs believed to exist and used by these flows:
- The shape the front end's mock services will follow until the real contracts arrive:

To request from Backend and API Ops:

- The API catalog with real examples:
- Request and response shapes, errors and versioning, for each API used here:
- Confirmation of the business meaning of key fields and status values:
- Reference patterns for authentication, migrations and tests:
- A test environment with test identities and safe data:
- Read-only access to logs, errors and health, and who to reach when something breaks:
- APIs that do not exist yet, raised through the written request route:
- The named owner of each request, and the date the answer is needed:

To request from Frontend Ops, where these flows depend on it:

- The approved starter repository, its current version, its owner and how to start it:
- The API client pattern, authentication, error handling and loading states:
- The checks required on a deployable branch, and the preview or environment path:
- The named owner of each request, and the date the answer is needed:

## 12. Acceptance criteria

*Per flow, say what has to be true before it counts as done.*

- Flow:
- Works end to end, against the mock services and then against the real backend:
- Empty, loading, error and permission-denied states handled:
- Matches the design reference where that reference is non-negotiable, within the drift accepted in section 8:
- No privacy regression:
- Tests added or updated:
- Checks to run before finishing (typecheck, lint, tests, build, walk the flow in a browser):
- Memory and journal updated when product behaviour, architecture, a stakeholder decision or future reasoning changed:

## 13. The QA contract

*Say how this product gets checked, so the check is not invented at the end.*

- Personas to test:
- Role-based privacy checks:
- Requirements derived from transcripts:
- Regression flows:
- Validation commands:
- Expected report format:
- Severity meanings in use, and when defects start being tracked rather than fixed as they appear:

## 14. Open decisions

*One row per decision: its alignment question states what one source says, what the other says and the product risk of choosing wrong; who decides is a person, not a team.*

| Decision | Alignment question behind it | Default proposed | Who decides | By when |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |

Text licensed CC BY 4.0. Code MIT.