Design record
A description of what the solution does and how it is built today. It changes only when work that changes it is Done.
What it is
Where a requirement says what should change, a design record says what is true now. There are five kinds: BDR (business: processes and rules), FDR (functional: capabilities and screen flows), NFDR (qualities, grouped by ISO 25010, and compliance), TDR (technical, per component: modules, interfaces, data, integrations, infrastructure) and ADR (architecture decisions and their reasons).
Why it matters
Requirements describe changes; after a few years nobody can read the current system out of them. Design records keep one up-to-date description, with every version and the work, requirement and initiative that brought it.
Because the description changes only when work is Done, it never claims the system does something it does not do yet.
What goes wrong without it
- The only description of the system is the code, or a pile of old specs that each describe a different moment.
- Two changes quietly edit the same rule, and nobody notices until both ship.
- Nobody can say when a behaviour arrived or which request brought it.
What it gives an AI agent
An agent needs two things: what the solution is today, which it must respect, and what it has been asked to change. Design records are the first; the initiative's requirements and the story's design change are the second. The agent also sees other open work that changes the same records.
Example: Clinic Booking
| Weak | Strong |
|---|---|
| Rescheduling rule: see the old spec. | FDR — Move an appointment: a patient can move an appointment to a free slot up to 4 hours before it starts. Version 2, from the story "Four-hour notice" in the initiative of the same name. |
How it relates to the rest
- Belongs to the solution; a TDR also belongs to a component.
- Changed only by the design changes (add, change, retire) that epics, stories, tasks and defects carry, applied when the work is Done. If two pieces of work change the same record, the first Done wins and the other must be looked at again.
- Its acceptance lines are criteria (FDR-1A2B3C/AC2) that tests prove.
In Corpole
- The Design page (/app/design) lists records by kind; each record shows its versions and pending changes.
- Onboarding an existing codebase produces design drafts of the repository's component; a person confirms them as the design, turns wrong behaviour into a defect, or rejects them.
- Agents read with
list_design_recordsandget_design_record, and propose changes withpropose_design_delta.