Reference
Document typesCopy link
One page covering every artefact RCF defines. Purpose, ID scheme, and where each one sits. Look up what you need; the rest stays where it is.
RCF’s document types aren’t separate templates you pick from; they’re positions on a chain, each carrying a specific decision and a specific kind of reference. The chain is a Y-shape with two upstream arms meeting at the build chain:
- Intent arm: PRD → Requirements → User Stories → Acceptance Criteria.
- Architecture arm: Technical Architecture Document → ADRs.
- Build chain (both arms meet at the FBS): Build Sequence → Functional Build Specification → Test Suite → Test Case.
Listed below in the order they appear in the chain. See the document chain page for the structural argument; this page is the reference card for each artefact.
Every artefact carries an opaque string ID. IDs never get renumbered and never get reused. They’re the keys traceability runs on; see the traceability page for why. The conventions below are recommended; the load-bearing rule is that whatever scheme you pick stays stable.
PRD: Product Requirements DocumentCopy link
Product Requirements Document PRD-NNN
The top of the chain. One per product. States what the product is, who it’s for, what it does, and (load-bearing) what it deliberately doesn’t do. Holds the requirements list as its main payload. Out-of-scope sections matter as much as in-scope. Lives as a single document; section headings handle internal structure.
References: none upward. Referenced by every Requirement.
REQ: RequirementCopy link
Requirement REQ-NNN
A short statement of something the product must do. Carries a category (functional, non-functional, regulatory), a priority (must, should, could), and a domain (auth, billing, search, whatever the product is made of). Requirements describe what, never how. Lives inside the PRD’s requirements list.
References: belongs to one PRD. Generates one or more User Stories.
US: User StoryCopy link
User Story US-NNN
The human shape of a requirement. The familiar “as a [role] I want [action] so that [outcome]” structure. Stories give a requirement a concrete actor and a stated outcome, which is what acceptance criteria can then test against. A requirement usually generates a small handful of stories, not dozens.
References: belongs to one Requirement. Carries one or more Acceptance Criteria. Belongs to one Functional Build Specification via its fbsId field, with the FBS’s storyScope as the canonical mapping.
AC: Acceptance CriterionCopy link
Acceptance Criterion AC-NNN-NN
The central primitive of the methodology. A Given/When/Then sentence that names a precondition, an event, and an observable expectation. ACs are scoped to the story they sit on; the second-segment number is the criterion’s position within that story. AC text must be testable as written. If it isn’t, it isn’t a real AC.
References: belongs to one User Story. Has exactly one Test Suite, one to one. See Acceptance criteria as the contract.
TAD: Technical Architecture DocumentCopy link
Technical Architecture Document TAD-NNN
One per product, top of the architecture arm and sibling to the PRD. Describes the systems and components the product needs: services, data stores, external integrations, the cross-cutting decisions about how data flows and where state lives. The TAD is a single logical artefact, but under the hood it bundles whatever it needs to land the architecture: written sections, diagrams, wireframes, schema definitions, and a decisions section that lists the ADRs. Logical boundary, not file-based.
References: top of the architecture arm. Contains the list of ADRs. Referenced by Functional Build Specifications via the buildContext.tadSections field.
ADR: Architectural Decision RecordCopy link
Architectural Decision Record ADR-NNN
One consequential architectural choice, captured tightly: context, decision, alternatives considered, consequences, status. ADRs sit on the architecture arm under the TAD. They survive the conversation that produced them and let later engineers ask “why was this decided that way” with a real answer. Superseded ADRs aren’t edited; a new ADR records the change and links back. See Architectural decisions and ADRs.
References: belongs to one TAD. Referenced by Functional Build Specifications via the buildContext.adrs field. May supersede a prior ADR.
BS: Build SequenceCopy link
Build Sequence BS-NNN
The plan for getting from nothing to shipped. A directed acyclic graph: each node is a Functional Build Specification, each edge is a dependency between them. One per product. The sequence decides what gets built when. Vertical-slice sequencing (ship working behaviour as early as possible) is the usual target; foundation-first sequencing (stand up shared infrastructure before slices) is the common alternative when there’s real shared work to do.
References: contains all the Functional Build Specifications for the product. Each FBS declares its dependencies on others.
FBS: Functional Build SpecificationCopy link
Functional Build Specification FBS-NNN
The unit of work. One slice of the product, sized so it can be built, tested, and shipped in one go. Carries the slice’s scope (which stories, which ACs), its dependencies (other FBSs that must finish first), its declared build context (PRD sections, TAD components, code modules, schemas, external docs the worker will need), its testable outcomes (the in-scope ACs restated), and its status. The FBS is also what the build cycle (Define → Build → Review → Test → Finalise) runs against.
References: belongs to one Build Sequence. Has zero or more dependency FBSs. Has a storyScope mapping it to specific user stories and ACs.
TS: Test SuiteCopy link
Test Suite TS-NNN-NN
The implementation of one acceptance criterion in test code. Each suite belongs to exactly one AC; each AC has exactly one suite. The suite ID mirrors the AC ID by convention (TS-088-02 implements AC-088-02), which makes it greppable. A suite is made up of Test Cases.
References: implements one Acceptance Criterion, one to one. Contains one or more Test Cases.
TC: Test CaseCopy link
Test Case TC-NNN-NN-NN
The individual scenario inside a suite. Happy path, named edge cases, failure modes. Each case is one assertion-bearing path through the behaviour the suite is testing. Cases are how you cover the AC’s intent thoroughly, not how you cover separate ACs.
References: belongs to one Test Suite.
ID scheme summaryCopy link
The full set of conventions, in one table.
- PRD-NNN. One per product. Usually three-digit, zero-padded.
- REQ-NNN. Sequential within a PRD. Width is fixed per project. Mix three- and four-digit at your peril.
- US-NNN. Sequential within a PRD. Stories are not scoped to requirements at the ID level; the relationship is by pointer (reqId), not by ID structure.
- AC-NNN-NN. Scoped to the story. The first segment is the story number, the second is the criterion’s position within that story. ACs are opaque strings; don’t rely on the numeric structure for sorting or queries beyond “is this AC on that story.”
- TAD-NNN. One per product. Usually paired with the PRD (PRD-001 and TAD-001).
- ADR-NNN. Sequential within a TAD. Width is fixed per project. Never renumbered; superseded ADRs stay as frozen snapshots and a new ADR records the change.
- BS-NNN. One per product. Usually paired with the PRD.
- FBS-NNN. Sequential within a Build Sequence. Width is fixed per project.
- TS-NNN-NN. Mirrors the AC ID. TS-042-03 implements AC-042-03.
- TC-NNN-NN-NN. Mirrors the suite plus a case index. TC-042-03-01 is the first case of the suite that implements AC-042-03.
None of the numeric structure is queried directly. Pointer fields do the work. The mirror conventions (TS to AC, TC to TS) are for human readability and for grep, not for the data model.
What’s deliberately not hereCopy link
Some artefacts you might expect to see don’t appear because they don’t earn their keep at this level of the methodology. There’s no Bug document; bugs are work items in the project’s work tracker, and the fix is run through the normal build cycle against the AC the bug exposed. There’s no separate Release document; the build sequence and FBS statuses together describe what’s shippable, and the deployment record lives in whatever your release infrastructure already produces.
Keeping the document set small is deliberate. Every additional document type is another vocabulary the team has to maintain and another place where the chain can fall apart. The set above is the minimum needed to make the methodology hold together. Adding more is optional and usually a sign that something else is wrong upstream.