Reference
ReferenceNormative
Standards adopted
Every naming and structuring scheme in force here, with where it comes from — so it can be looked up rather than taught.
Nothing on this list was invented here. Each entry was found by looking up what the discipline already does, and each is recorded with its provenance so a reader can go to the source rather than trust this site.
In force
| Standard | Where it comes from | What it settles here |
|---|---|---|
| WBS — work breakdown structure | Project management, decades old | Work codes <epic>.<story>.<task>, zero-padded. Work register |
| WBS dictionary | Same | The index that says what each code is — the one place |
| ADR / MADR | adr.github.io | The shape of a decision record, and decision drivers as the name for the forces in a situation |
| Diátaxis | diataxis.fr | How documentation is divided by reader need — the frame this site is organised on |
| Domain Storytelling | Hofer & Schwentner | How a domain is discovered: actor → activity → work object |
| EventStorming | Alberto Brandolini | Ordering a complex lifecycle after the stories exist |
| Use case, user-goal level | Alistair Cockburn | The body written beside each mutation: actor, goal, trigger, precondition, result, scenario, extensions |
| Aggregate reference by identity | Vaughn Vernon, Implementing DDD | demandeurId: ID!, never an embedded aggregate |
| Ubiquitous language / lexicon | Eric Evans, Domain-Driven Design | One business term, one identifier, normative |
| GraphQL SDL | GraphQL specification | The domain-model notation — cardinality and obligation become syntax |
| Tracer bullet | Hunt & Thomas, The Pragmatic Programmer | How a story is sized |
| Expand → migrate → contract | Database refactoring literature | How a wide refactor is sliced while the build stays green |
| Definition of done | Scrum | The conditions every story must satisfy, kept distinct from per-story acceptance criteria. Plan delivery |
| Enabler story | SAFe | The other home for a cross-cutting rule |
| Requirements traceability, both directions | CMMI REQM | Every story cites requirements; every requirement is cited |
| EARS — Easy Approach to Requirements Syntax | Mavin et al., IEEE RE 2009 | One-line event-driven acceptance criteria: When …, the <module> shall … |
| Hexagonal architecture (ports and adapters) | Alistair Cockburn | The standing architecture default |
| Semantic versioning | semver.org | What a version number promises |
| Mermaid | mermaid.js.org | Diagram notation, verified by parsing before it ships |
Considered, and where they would apply
| Standard | Would settle | Status |
|---|---|---|
| RFC 2119 | must / should / may in a normative sentence | Not adopted — the specification uses the present indicative and no conditional, which is stronger |
| Gherkin | Executable scenario notation | Used only where a real acceptance runner consumes it; work-register criteria use EARS and cite requirement IDs |
| arc42, C4 | How an architecture is described and drawn | Available; adopt when a project needs an architecture document beyond the decision records |
| Volere | Requirement shell | Not adopted — the four-line requirement shape covers it with less ceremony |
| MoSCoW | Priority | Not adopted — release selection and sequence belong to delivery planning, not the normative module reference |
| RACI | Who decides | Partially — each open question carries who decides, which is the load-bearing responsibility |
The rule this list exists to enforce
Adopt the standard word even when it is less pretty. Recognition beats elegance: a word someone can look up is worth more than one they have to be taught.
Departing from one requires a stated reason — a real collision, or the standard genuinely not fitting. "I prefer mine" is not a reason.