Design records¶
Design records capture lightweight, dated project decisions that need durable public context but do not require a full RFC. They record a decision and its provenance; they do not replace the RFC process or silently redefine an RFC, issue, or release plan.
Govern a material changeBrowse RFCsUse the RFC process for language, compiler, tooling, and architecture proposals.
Preserve contextStart a design recordRecord a scoped decision, constraint, or deferral with explicit provenance.
Choose an artifactProject records overviewSee how RFCs, design records, whitepapers, roadmaps, and release notes differ.
Status vocabulary¶
Draft: The decision is under discussion.Accepted: The decision is approved. An accepted decision may defer or exclude implementation.Rejected: The proposal was considered and not adopted.Superseded: A later design record or RFC replaced the decision.Withdrawn: The record was removed before acceptance.
Authority and provenance¶
- Every design record must cite the RFCs, issues, pull requests, discussions, or release-planning notes from which it derives.
- A design record does not supersede one of those authorities unless it says so explicitly.
- Release targets in
review_targetare review points, not delivery commitments. - Once a record is accepted, change the decision through a new or superseding record rather than rewriting its history.
ID sequence¶
IDs are stable and sequential: DD-0001, DD-0002, and so on. File names use NNNN_short_slug.md; the id field in the record metadata is canonical.
Start from the design-record template when proposing a new decision.
Records¶
| ID | Decision | Status | Review point |
|---|---|---|---|
| DD-0001 | Defer GPU target capability and graphics contracts | Accepted | v0.8 planning |