brief

The brief is the authoritative root document for a project. It establishes what the project exists to do, the constraints it operates under, and the success criteria by which completion is judged. It is written by a human stakeholder and kept as a living record: the brief is the project's current state, carrying no version label and no archive directory, so every section is revised in place as the project moves (adr-5). History lives in git log; inflection-point rationale lives in the ADRs.

When to use

Use "brief" when referring to the top-level project specification document that lives at .abcd/development/brief/. A project has exactly one brief.

When NOT to use

Do not use "brief" to describe an intent (which is feature-scoped) or a spec (which is implementation-scoped). The brief is project-wide; intents and specs are narrower.

Examples

• "The brief says the target persona is Carol, not Alice."
• "This intent is out of scope: the brief's constraints rule its user moment out."

Related terms

• record families — the one page that maps the record families and how they relate
• intent — a press-release-shaped feature description within the project scope
• voyage — the operations namespace recording what abcd did to produce a lifeboat; a disembark run grounds the brief's structure section by section