Solution design
The design records describe the solution as it is today: business design (BDR), functional (FDR), non-functional (NFDR), technical per component (TDR) and architecture decisions (ADR). Requirements belong to initiatives and say what should change; the design belongs to the solution and changes only when the work that carries a change is Done.
For: Product owner, Project lead, Team developer, Solo builder
Kinds
- BDR: processes and business rules.
- FDR: capabilities and screen flows.
- NFDR: quality characteristics in the ISO 25010 set (performance, security, reliability, usability …) and compliance.
- TDR: per component — modules, interfaces, data, integrations, infrastructure.
- ADR: architecture decisions and their reasons.
How a design record changes
An epic, story, task or defect carries design changes: add a record, change one or retire one (on the work page, under Design changes; agents use propose_design_delta). When the work is Done each change becomes a new version, with the work, the requirements it implemented and its initiative as the reason. If two open items change the same record, the first to be Done wins and the other's change is marked to be looked at again.
Drafts come from delivered requirements and from findings in code, documents or tests; a person with the authorize permission confirms each after checking it describes the solution as it is.