The document chainCopy link

Most software documentation is shaped wrong. There’s usually too much of it, organised by who wrote it rather than by what it’s for, and the connections between documents are stored in people’s heads instead of on the page. By the time you need to ask “why does this function exist,” half the relevant documents have rotted past usefulness and the other half are describing a version of the product that was deprecated six months ago.

RCF’s document chain is the smallest set of artefacts that closes that gap, with the relationships between them made explicit. Nine layers. PRD, requirements, user stories, acceptance criteria, technical architecture, build sequence, functional build specification, test suite, test case. Each one earns its place. Each one points up and down.

PRD: the productCopy link

The product requirements document sits at the top. It says what the product is, who it’s for, what it does, and, critically, what it doesn’t do. Out-of-scope is as load-bearing as in-scope. Half the failures I’ve watched on corporate projects were scope drifts that a sharper PRD would have caught before any code was written.

Inside the PRD lives the requirements list. Each requirement is a short statement of what the product must do, with a category (functional, non-functional, regulatory), a priority (must, should, could), and a domain (auth, billing, search, whatever the product is made of). Requirements aren’t where you describe how something works. They’re where you commit to what works.

User stories: the human shape of a requirementCopy link

A requirement on its own is hard to build against. It’s a statement of intent, not a description of behaviour. So each requirement breaks down into user stories, the familiar “as a [role] I want [action] so that [outcome]” shape.

The story’s job is to give the requirement a human shape. A requirement that says “the product supports OAuth sign-in” might break into stories about first-time signup, returning sign-in, account linking, and sign-out, each with its own actor and outcome. The stories are what a product owner thinks in. The requirement is what they commit to.

Acceptance criteria: the contractCopy link

Each story carries one or more acceptance criteria. The AC is where things get specific. A criterion is a Given/When/Then sentence: given a precondition, when an event happens, then an observable thing must be true. AC text is what tests are built from, one to one.

ACs are the central primitive of the methodology, and they get their own page: Acceptance criteria as the contract. The short version is that AC is the layer at which intent becomes machine-checkable. If you can’t write a test for it, it isn’t a real AC.

Technical architecture: the system the requirements needCopy link

Off to one side of the chain, the technical architecture document 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 isn’t in the main chain because it doesn’t get one-to-one mappings to requirements. It’s a shared resource that requirements draw on.

The TAD’s job is to make sure that when somebody builds a slice, they build it against a system that exists. Architectural decisions live here as inline notes, dated and signed, so when a future engineer asks “why does the identity service own the session token,” there’s an answer in the same document that defines the identity service.

Build sequence: the planCopy link

The build sequence is the directed acyclic graph that gets you from nothing to shipped. Each node on the graph is a functional build specification, a slice of the product you can build, test, and ship in one go. Each edge is a dependency: this FBS can’t start until that one is done.

Sequencing matters more than people think. A well-shaped build sequence ships vertical slices that prove the product works end to end as soon as possible. A badly-shaped one ships horizontal layers that look like progress on a status report but produce no shippable behaviour for weeks. The build sequence is where that gets decided.

Functional build specification: the unit of workCopy link

A functional build specification is the brief the worker actually executes against. It pulls together everything needed for one slice: which stories and ACs are in scope, which PRD sections and TAD components the worker needs to read, which modules and schemas the work will touch, which dependencies must be done first, and the relevant business patterns, standards, style guidelines, and instructions that constrain how the work is done. It carries a list of testable outcomes, which is the restatement of the in-scope ACs in the worker’s terms.

The FBS is also where the build context lives: the curated set of references that a worker (human or agent) needs to do the slice without grepping for orientation. That context isn’t a generic dump of the codebase. It’s the specific PRD sections, TAD components, code modules, and external docs that the slice depends on. Getting this right is most of why AI agents do good work on RCF projects when they’d otherwise produce nonsense.

Test suite and test case: where intent becomes behaviourCopy link

Each acceptance criterion gets one test suite. One to one, no exceptions. The suite implements the criterion in code. The suite is made up of test cases, the individual scenarios that, together, prove the criterion is met: the happy path, the named edge cases, the failure modes.

The one-to-one rule between AC and suite is what makes traceability possible. Run a single command and you can ask “is AC-042-03 passing” or “which tests would I need to look at if requirement REQ-014 changed.” The answers are mechanical because the structure is mechanical.

Reading the chain top to bottomCopy link

Start with a business decision. The product needs to support exporting user data. That decision becomes REQ-019 in the PRD, functional, should-have, domain: privacy. REQ-019 generates US-088: as a user I want to download my data so that I can take it elsewhere. US-088 carries three acceptance criteria, AC-088-01 through AC-088-03, covering the happy path, the size cap, and the format. The TAD says exports route through a background job service. The build sequence places FBS-051 for the export feature, after FBS-016 (which stood up the job service). FBS-051’s storyScope is { US-088: [AC-088-01, AC-088-02, AC-088-03] }. When a worker picks it up, they write three test suites, then they write the code, then everything goes green, then FBS-051 closes. REQ-019 is now satisfied, and the satisfaction is provable from the chain.

Reading the chain bottom up works just as well. Pick a function in the export handler. Find the suite that covers it. Find the AC that suite implements. Find the story that holds the AC. Find the requirement the story serves. Find the business decision the requirement encodes. Each step is one hop, and each hop is mechanical.

Why nine layers and not fewerCopy link

The obvious objection is that nine layers is a lot. It is. The shorter version, requirement → test → code, would be cleaner. But each layer I’ve added is there because the layer above and below can’t do its job otherwise.

Requirements need stories because a requirement is too abstract to test. Stories need ACs because a story is too vague to test directly. ACs need test suites because behaviour needs implementing in code, not in prose. The build sequence and FBS layer exist because somebody has to decide what gets built when, and with what dependencies, or the work fragments. The TAD exists because cross-cutting decisions don’t live in any single requirement.

Each layer is a place where one specific kind of decision gets made and pinned down. Compress the layers and decisions either get made in the wrong place, or stop getting made at all, or get made silently by the worker on the spot. None of those are decisions you want.

The chain is also context engineering at the team scale. Each layer is the context the next layer needs. The agent gets the right slice of intent at the right point in the build, instead of a generic dump of the codebase or a crammed prompt that hopes for the best. That’s the methodology earning its keep on the agent’s behalf as well as the team’s.

Vocabulary, ID schemes, and what to look up nextCopy link

Every document type has an ID. PRD-001. REQ-014. US-042. AC-042-03. TAD-001. FBS-027. TS-088-01. The IDs are opaque strings, never renumbered, never reused. They’re how traceability happens at the system level: code references an AC ID, a test suite ID matches an AC ID, a work item ID points at an FBS ID. The string is the lookup key.

Full vocabulary is in the glossary. ID schemes per document type are catalogued on the document types page. For the next concept in the reading order, see Acceptance criteria as the contract.