Reference
Document types reference
Look up each document type and its role in the chain. The chain page explains the relationships; the document model provides the shipped model overview. For the concept-level entry, see the methodology page on document types.
The table summarises each document type. The chain explains their relationships; the document model publishes the shipped model overview.
| Type | Name | Is |
|---|---|---|
| PRD | Product Requirements Document | The root statement of product intent: the problem, who has it, what changes when it is solved, what is out of scope. One per project. |
| REQ | Requirement | One testable capability the product must have, with category, priority and rationale. References its PRD. |
| US | User story | One story under a requirement: as-a / I-want / so-that, carrying its acceptance criteria. References its REQ. |
| AC | Acceptance criterion | An observable, testable statement of done in given / when / then form, carried inline in its user story. The currency of the whole framework. Carries an optional determinism marker (deterministic by default; nonDeterministic opts into EVAL coverage alongside TS/TC). |
| TAD | Technical Architecture Document | The architecture root: a shell for cross-cutting sections, with TACs and ADRs as children. One per project. |
| TAC | Technical architecture component | A lasting component of the system: purpose, responsibilities, interfaces, dependencies. References the TAD. |
| ADR | Architecture decision record | One consequential decision: context, decision, consequences, and the alternatives with reasons. References the TAD. |
| BS | Build Sequence | The planning root: how work is ordered and under what strategy. One per project. |
| FBS | Functional Build Specification | One work item: a coherent slice of delivery scoped to a set of AC ids, with build order, dependencies, sizing and execution status. |
| TS | Test Suite | What test cases exist for one or more acceptance criteria on a single user story, at a named test level. Hangs off the user story. |
| TC | Test Case | One test: the AC it verifies, the pointer to the executable test, and its status. Carried inline in its test suite. |
| EVAL | Evaluation | A graded example set for one or more acceptance criteria on a single user story, for ACs whose output is non-deterministic. Carries cases, criteria, a judge (rubric, LLM under subscription, or scripted metric), a pass threshold and an append-only run record. Peer of TS on the same acceptance criterion; neither replaces the other. |
| CN | Code Node | The spec-to-code bridge: a source path, optionally symbol-suffixed. Its required implementsAcIds array records the acceptance criteria it implements and may be empty for orphan CNs such as utilities, glue, and wiring. No parent; its identity is its path. |
| MANIFEST | Manifest | rcf/manifest.json: declares the three root documents (PRD, TAD, BS). rcf-lite enumerates each document directory, validates every file, then derives topology by inverting child-owned parent ids. |
Two structural rules worth carrying into any reading of the tree: standalone parent-child topology edges point upward from child to parent, and standalone parent documents do not list their children. A US embeds its AC children, and a TS embeds its TC children. Cross-links and peer dependency references can point elsewhere. The downward view is computed. Field-level detail, required fields, enums, id patterns and the file layout, ships with the @stravica-ai/rcf-schemas package, one page per schema file in its docs/ directory. AC is documented inside user-story.md, and TC is documented inside test-suite.md.