For agents
Document model
The specification your agent uses to author the document chain, including each type's fields and relationships. The text is reproduced verbatim from the shipped pack.
Source: rcf-lite@0.36.1, file
guidance/document-model.md. Also served to a connected
agent as the rcf://docs/document-model MCP resource.
This is the specification your agent uses to author documents. The chain explains the relationships, and document types provides a one-line summary of each type.
One page per document type, the reference rule that keeps the tree drift-proof, and where the files live. Field-level detail is in the per-schema reference pages shipped with the @stravica-ai/rcf-schemas package (its docs/ directory).
The types
PRD (Product Requirements Document). The root statement of product intent. It requires a problemStatement and objectives. The targetUsers and outOfScope fields are optional. One per project. Everything else in the requirements chain descends from it.
REQ (Requirement). One testable capability the product must have. It requires a category and a priority, and supports an optional rationale. Each REQ references its PRD. A REQ that cannot be verified by tests is a symptom of a REQ that needs splitting or sharpening.
US (User story). A story under a requirement: asA / iWant / soThat, plus the acceptance criteria that define done. Each US references its REQ, and may reference the TACs it touches.
AC (Acceptance criterion). A statement of done carried inline in its user story's acceptanceCriteria array. Authors should make each AC observable and testable. The schema requires the testable boolean but permits false. The optional given, when and then fields support Gherkin-style ACs. ACs are the currency of the whole framework: work is scoped to ACs, coverage is measured per AC, and tests point at ACs.
TAC (Technical architecture component). A lasting component of the system: its purpose, responsibilities, interfaces and dependencies. Each TAC references the TAD.
ADR (Architecture decision record). One consequential decision: the context, the decision and the consequences. The optional alternativesConsidered array records alternatives. Each entry requires a name and summary, and may include reasonNotChosen. Each ADR references the TAD.
TAD (Technical Architecture Document). The architecture root: a shell for cross-cutting sections, with TACs and ADRs as its children. One per project.
BS (Build Sequence). The planning root. Its optional buildPhilosophy and generationStrategy fields describe the philosophy and ordering strategy. Each FBS supplies its place in the sequence through buildOrder. One per project.
FBS (Functional Build Specification). One work item: a coherent slice of delivery scoped to a set of AC ids, with a build order, dependencies on other FBS items and an execution status. The optional estimatedSize and estimatedHours fields provide sizing. The FBS queue is what rcf build drives.
TS (Test Suite). The specification of what test cases exist for one or more acceptance criteria on a single user story, at a named test level.
TC (Test Case). One test: which AC it verifies and its status. Its testPointer is required when the status is passing or failing, and optional when the status is pending or skipped.
CN (Code Node). The spec-to-code bridge: a working-tree source path, optionally #symbol-suffixed, that implements one or more acceptance criteria (implementsAcIds, which may be empty - an orphan CN is a legitimate state for utilities and glue code). rcf define validate checks every CN's path/symbol against the working tree, so a rename or deletion that leaves the pointer dangling is caught the same way a broken spec-side reference is. Author CNs during Stage 2 of the build cycle (see below), not after: rcf build mark <fbs-id> complete refuses when an in-scope acceptance criterion has none unless the FBS already sets noCodeNodes or the command passes --no-code-nodes for genuinely no-code work. Full detail, including the honest limits, is docs/code-nodes.md in the rcf-lite repo.
Edges live on the child
Hierarchy edges live on standalone children: a REQ carries its prdId, a US its reqId, a TAC its tadId, an FBS its bsId, and a TS its usId. Other references are cross-links rather than parent edges, including US.tacIds, FBS.acIds, TS.acIds, CN acceptance-criterion and dependency edges, and EVAL.acIds. That last hierarchy edge catches people out: a test suite hangs off the user story, not off the FBS that happens to schedule the work, even though the FBS is what you were looking at when you decided the suite was needed. A CN has no parent at all, because its identity is its path rather than a position in the tree. Parents never hold lists of their children. The walker computes the downward maps at load time by inverting the child references. Creating or reparenting a standalone hierarchy document changes one file. Deletion is different. It can refuse while dependents exist, or a requested cascade can delete or mutate dependent files.
Files on disk
The tree lives under rcf/ in the project root. rcf/manifest.json declares the three root documents (PRD, TAD, BS). Every JSON file in each known collection directory is loaded, then topology is derived from its references. Roots are single files (prd.json, tad.json, build-sequence.json); collections are directories (requirements/, user-stories/, tacs/, adrs/, fbs/, test-suites/). ACs live inside their US file; TCs live inside their TS file.
Field-level reference
This page is the shape of the model, not the schema. For required fields, enums and id patterns, read the per-schema pages in @stravica-ai/rcf-schemas. There is one page per top-level schema, with AC documented in user-story.md and TC in test-suite.md. id-conventions.md covers cross-cutting ID rules. file-layout.md gives recommended layout guidance rather than a schema-enforced contract. rcf-lite tooling uses fixed conventional paths for the RCF tree.
Canonical reference: /rcf-methodology/document-types/