The chain

The chain consists of plain JSON documents in your repository. Each holds one kind of statement. Parent-child edges for standalone, non-root documents are stored on the child; roots have no parent, and Code Nodes link directly to the acceptance criteria they implement instead. Your agent authors and maintains the documents; you review them in the tree viewer. The structure is:

PRD    what you asked for
 └─ REQ    one capability the product must have
     └─ US + AC    a story of using it, with checks that define done
         ├─ TS + TC    the tests that prove the checks
         └─ EVAL       a graded set of cases, on checks that cannot be tested deterministically (optional)

CN --implements--> AC    source files linked directly to the checks they implement

TAD + TAC + ADR    the architecture and its decisions
BS + FBS           the ordered queue of build work

The requirements spine

The product statement (PRD). The root: the problem, who has it, what changes when it is solved, and what is out of scope. Without it, product intent remains in prompt history rather than a maintained specification. One per project; everything descends from it.

Requirements (REQ). One testable capability each, with a priority and a rationale. A requirement such as "search should be good" must be split or made precise enough to verify with tests. This resolves ambiguity before implementation.

Stories and their checks (US and AC). A story is one person using one capability: who they are, what they want, why. Under each story sit its acceptance criteria: observable statements of done, each one a sentence someone could check. These checks define the scope and evidence for the method. Work is scoped to them, coverage is measured against them, tests point at them. When you push back at the review, this is the layer you are really editing.

Tests (TS and TC). Suites and cases, each case naming the check it verifies. Passing or failing cases must point at the executable test that does the verifying; pending or skipped cases may omit that pointer. The pointer matters: a claim of "tested" that points at nothing is exactly the failure this layer exists to close, and the tooling refuses to count it.

The bridge to code (CN). Code Nodes tie source files, down to individual functions, to the checks they implement. Renaming or deleting a file that the chain depends on is caught the same way a broken reference between documents is. This lets the tooling identify which code serves a requirement.

Evaluations for the non-deterministic checks (EVAL). Where a check is on an output that cannot be judged mechanically, an LLM answer, a ranked result set, a generated summary, marking the acceptance criterion as nonDeterministic at define time lets you attach a peer document to it: a graded set of cases with pass criteria, a judge (a rubric, a spawned CLI under your subscription, or a scripted metric), and a pass threshold. It sits alongside TS and TC on the same acceptance criterion; neither replaces the other. Coverage of non-deterministic ACs is audited by rcf audit eval coverage, and the finalise gate refuses to ship while an EVAL is missing or below threshold, with an explicit opt-out that records its reason on the manifest. A chain that carries no non-deterministic ACs is untouched by any of this.

The technical side

Architecture (TAD, TAC, ADR). The architecture document is the root; under it, components describe the lasting parts of the system, and decision records hold each consequential choice: the context, the decision, the consequences, and the alternatives with the reason each was not chosen. The decision record is where a deferral lives too. When you tell your agent "I have not decided where this will be hosted", that answer is recorded here for later review.

The work queue (BS and FBS). The build sequence orders the work, and each item in it is a build specification: one coherent slice of delivery, scoped to a named set of checks, with dependencies and a status. The queue is what your agent drives, item by item, through the build cycle.

Why it stays consistent

One structural rule keeps the chain consistent: each parent-child relationship has one stored owner. A standalone child document stores its parent reference; a US stores its inline ACs, and a TS stores its inline TCs. Cross-links are stored on the document that declares them, including links from stories to TACs, TACs to dependencies, FBS items to ACs and other FBS items, test suites and cases to ACs, ADRs to related ADRs, EVALs to ACs, and Code Nodes to ACs or other Code Nodes. Creating or re-parenting one standalone non-root document changes that document's file. Cascade deletion can delete or rewrite several dependent files. Because a parent-child relationship has one stored owner, parent and child files cannot disagree about that edge. The downward view you see in the viewer is computed fresh from the stored references every time.

The document-model overview ships inside the package and is published verbatim at the document model; the same material in reference form is at document types. For field-level authoring details, use the per-schema pages in the @stravica-ai/rcf-schemas package's docs/ directory.