On this page

Related reading

← RCF

Quick tour

The whole methodology in one read

RCF links requirements to architecture, tests and code. This fifteen-minute tour explains the problem it solves, the document chain and the build cycle, with a worked example.

The problem RCF is for

AI coding agents produce the first eighty percent of a build quickly: plausible structure, fluent code and familiar patterns. Completing a real product still requires decisions about its structure and behaviour, and evidence that both match the requirements.

A demo can compile, deploy and support a walkthrough while hiding unapproved decisions about edge cases, scaling, security and schemas. Those decisions can surface weeks later as bugs, outages or stakeholder questions.

Teams have long relied on developers remembering unwritten conversations. Requirements, acceptance criteria and tests often arrive late. The connection from a business decision to deployed code remains in people’s memories. Agents cannot rely on that shared memory.

The core idea

Start with requirements. Break each requirement into user stories, each story into acceptance criteria, and each criterion into a test. Write the code to pass those tests. Record the implementing file or symbol as a Code Node in the same graph. Each node links to the decision that justifies it and the evidence that verifies it.

The remaining documents and build stages make these relationships explicit and maintain them.

The chain records why a function exists and whether a requirement such as REQ-014 has shipped. Incorrect agent output fails against a test derived from a criterion, story and requirement that a human approved. This addresses the AI trust gap by making the chain the basis for verification.

RCF coverage within the wider software lifecycle A horizontal eight-stage lifecycle band reading left to right: Discovery, Shaping, PRD and TAD agreement, Build sequence, FBS (functional build spec), Build cycle, Deploy gates, Operate and Learn. A dashed loop-back arrow runs from the digital operator at the right back to Shaping on the left. The cards sit under five treatment bands. Cards 1 and 2 (Discovery, Shaping) are muted and outlined in light grey, labelled OUTSIDE RCF: pre-methodology exploration. Card 3 (PRD and TAD agreement) is paper-filled with a burnt-orange dashed bracket, labelled UPSTREAM: the multi-role agreement work that the next RCF workstream covers. Cards 4 through 6 (Build sequence, FBS, Build cycle) are solid burnt-orange, labelled BUILD PHASE, CURRENT FOCUS: what the published methodology covers today. Card 7 (Deploy gates) is paper-filled with a burnt-orange dashed bracket, labelled DOWNSTREAM: PR, merge and deploy gating work the methodology will pick up next. Card 8 (Operate and Learn) is muted and outlined in light grey, labelled OUTSIDE RCF: the digital-operator territory where shipped product is run and learned from. The loop-back arc returns from the digital operator back to Shaping, marking how operating-time learning feeds the next product slice's shaping, a cross-methodology feedback line rather than an RCF-internal one. Outside RCF. Discovery and shaping happen before the methodology engages. Try something, decide whether it is worth pursuing, settle on the shape of the work. RCF has limited grip here today. OUTSIDE RCF Upstream. The multi-role, multi-stakeholder agreement that turns a shaped idea into a written PRD and a TAD everyone signs off on. On the RCF roadmap as the next workstream upstream of the build phase. UPSTREAM Build phase, current focus. The slice-by-slice build side: order the work, spec a slice, build the slice. Traceability runs from an agreed business decision down to the lines of code that satisfy it. BUILD PHASE · CURRENT FOCUS Downstream. PR, merge and deploy gating between a finished build cycle and a live service. On the RCF roadmap as a separate workstream downstream of the build phase. DOWNSTREAM Outside RCF. The digital-operator territory: running a live service, learning from real use, deciding what becomes the next slice. RCF feeds this loop but does not itself describe how to operate in production. OUTSIDE RCF Discovery. Is this idea worth pursuing. Outside RCF: build, learn, throw away. The methodology kicks in only if and when the exploration produces something worth productising. Discovery is it worth it Shaping. Take a vague idea and decide the shape of the work. The role mix here is broad: product, design, architecture, sometimes compliance and legal. Outside RCF today. Shaping decide the shape PRD and TAD agreement. The multi-role, multi-stakeholder negotiation that produces an agreed PRD and an agreed TAD. Upstream of the build phase. Coming next as a separate RCF workstream. PRD / TAD what to build Build sequence. Decompose the agreed PRD and TAD into an ordered set of functional build specs (FBS slices). The first piece of the in-scope methodology. Build sequence order the slices FBS. Functional build spec. The unit of work the build cycle runs against. One slice through the document chain at a time. FBS spec a slice Build cycle. Define, build, review, test, finalise. The five-stage iterative loop applied to each FBS slice. The operating loop of RCF. Build cycle build the slice Deploy gates. PR review, merge, deploy. The gating between a finished build cycle and a live service. Downstream of the build phase. Coming next as a separate RCF workstream. Deploy gates PR, merge, deploy Operate and Learn. The digital operator runs the live service, watches real use, decides what becomes the next slice. Outside RCF: the methodology feeds this loop but does not describe how to run in production. Operate / Learn digital operator Loop-back. The digital operator's learning from real use feeds back into the next product slice's shaping. Dashed and muted because it is cross-methodology feedback (operator's territory into the pre-RCF shape), not part of RCF's linear forward flow. feedback into next slice RCF coverage within the wider software lifecycle (vertical layout) A vertical top-to-bottom eight-stage stack of the wider software lifecycle: Discovery, Shaping, PRD and TAD agreement, Build sequence, FBS, Build cycle, Deploy gates, Operate and Learn. The cards sit under five treatment bands shown as a bracket column on the left. Cards 1 and 2 are muted as outside RCF, the pre-methodology exploration phase. Card 3 is outlined in burnt orange as upstream RCF scope on the roadmap, the PRD and TAD agreement work. Cards 4 through 6 are solid burnt orange, the build phase currently in scope. Card 7 is outlined in burnt orange as downstream RCF scope on the roadmap, the deploy-gates work. Card 8 is muted as outside RCF, the digital-operator territory. A loop-back stub at the bottom marks the return to shaping when operating-time learning feeds the next slice. Outside RCF. Discovery and shaping. Pre-methodology exploration, outside the current scope. OUTSIDE Upstream. The PRD and TAD agreement work upstream of the build phase. On the RCF roadmap. UPSTREAM Build phase, current focus. The slice-by-slice build side: agreed PRD and TAD through to a built slice. BUILD PHASE Downstream. PR, merge and deploy gating work downstream of the build phase. On the RCF roadmap. DOWNSTREAM Outside RCF. The digital-operator territory: running the live service and learning from real use. OUTSIDE Discovery. Is this idea worth pursuing. Outside RCF. Discovery is it worth it Shaping. Decide the shape of the work. Outside RCF today. Shaping decide the shape PRD and TAD agreement. Multi-role agreement on what to build. Upstream RCF scope, on the roadmap. PRD / TAD what to build Build sequence. Order the FBS slices. In the build phase. Build sequence order the slices FBS. Functional build spec. In the build phase. FBS spec a slice Build cycle. Define, build, review, test, finalise. In the build phase. Build cycle build the slice Deploy gates. PR review, merge, deploy. Downstream RCF scope, on the roadmap. Deploy gates PR, merge, deploy Operate and Learn. The digital operator runs the live service and learns from real use. Outside RCF. Operate / Learn digital operator Loop-back. Operating-time learning feeds the next product slice's shaping. Cross-methodology feedback, not part of RCF's linear forward flow. feedback into next slice
Discovery → Shaping → PRD/TAD → Build sequence → FBS → Build cycle → Deploy gates → Operate / Learn

The document chain

The document chain links product requirements to the code that implements them. Each artefact records a different decision.

A PRD, or product requirements document, states what the product is, who it serves, what it does and what it excludes. Scope exclusions matter as much as inclusions. The PRD holds the requirements, short statements of what the product must do, with a priority and category.

Each requirement produces user stories in the form “as a user I want X so that Y”. Each story carries one or more acceptance criteria. These Given/When/Then statements define completion. Downstream verification maps to the criteria one to one.

The technical architecture document describes the systems, components, data stores and integrations the product needs. It is one logical artefact that can include written sections, diagrams, wireframes, schema definitions and architecture decision records. It gives build specifications explicit architecture references. Its boundary is logical rather than file-based.

The build sequence is the plan for getting from nothing to shipped. It’s a directed acyclic graph of functional build specifications, one per shippable slice, with dependencies declared up front. Each functional build specification carries the scope (which stories, which ACs), the context (which PRD sections, which TAD components, which modules and schemas the worker will need), the relevant business patterns, standards, style guidelines, and instructions that govern how the slice is built, and the testable outcomes that say when the slice is done.

Each user story gets a test suite that hangs off it and lists the acceptance criteria it verifies. Inside the suite, each test case pins to exactly one criterion. That one-to-one binding at the case layer is mandatory. A criterion must have a case that proves it.

Reading top to bottom: PRD → Requirements → User Stories → Acceptance Criteria → Technical Architecture → Build Sequence → Functional Build Specification → Test Suite → Test Case. The one thing that doesn’t sit on that straight line is the code: the source implementing a criterion is anchored as a Code Node that forks off the acceptance criteria, alongside the test suites rather than after the test cases. Read in detail in The document chain.

The build cycle

Each functional build specification runs through five stages, in order. Each stage commits.

Define. Write tests for every in-scope acceptance criterion from its text, before production code exists. The tests should fail. Commit.

Build. Write the code required to pass the tests. Use the build context declared in the FBS. Commit.

Review. Read the diff. Check that the tests exercise their criteria, the changes stay in scope and the implementation matches the technical architecture. Commit any corrections.

Test. Run every suite on the project. A failure elsewhere means the slice has broken existing behaviour and is incomplete. Commit the fixes.

Finalise. CI green. Coverage report attached. FBS status flipped to complete. The slice is shippable. Commit.

Each of the five commits records a defined stage that a senior engineer can review independently. Repeat the same cycle for every slice, including work carried out by AI agents.

A worked example

A SaaS app needs a user-uploaded profile photo. Take it through the chain.

In the PRD, the requirement reads: REQ-014: Users can upload a profile photo to personalise their account. Functional, must-have, domain identity.

One user story for the happy path: US-042: As a signed-in user, I want to upload a profile photo, so that my account shows my face.

Three acceptance criteria on the story:

  • AC-042-01. Given a signed-in user, when they upload a JPG or PNG under 5 MB, then the photo is stored and shown on their profile within two seconds.
  • AC-042-02. Given a signed-in user, when they upload a file over 5 MB or in an unsupported format, then the upload is rejected with a clear reason and no partial state is persisted.
  • AC-042-03. Given a signed-in user with an existing photo, when they upload a new one, then the old photo is replaced and removed from storage within a minute.

The TAD already covers the identity service and the object store, so the architecture work here is a one-line update to the identity service’s upload-handling component.

The build sequence places a functional build specification, FBS-027: Profile photo upload, after FBS-009 (the identity service stand-up) and before FBS-031 (the public profile page). Its storyScope is { US-042: [AC-042-01, AC-042-02, AC-042-03] }. Its testableOutcomes are the three ACs, restated.

In Define, the worker writes one test suite for US-042 holding three test cases, one per AC in scope, each shaped to drive its criterion through the happy path, the named edge cases and the failure modes. The suite compiles. Its cases fail.

In Build, the worker writes the upload handler, the validation, the storage write, the old-photo cleanup. The tests go green one by one. The code that satisfies each criterion is recorded as a Code Node pointing at the file or symbol that implements it: the upload handler lands as CN-071 against AC-042-01, the cleanup as CN-073 against AC-042-03. FBS-027 won’t mark complete until every acceptance criterion in scope has one, so the code-side link is checked, not assumed.

In Review, AC-042-03 passes because the worker added a 60-second sleep to the test without verifying the cleanup time. The worker fixes the implementation so the test verifies the criterion.

In Test, all suites on the project run. Everything green. CI green. FBS-027 closes.

Six months later, a security reviewer can check how replaced photos are removed by following AC-042-03 to its test suite and CN-073, which resolves to the cleanup code. If that code has moved or been renamed, rcf validate flags the broken reference.

When the spec changes

Product owners refine requirements after seeing the software. In this example, the upload later needs to support iPhone HEIC files. AC-042-01 did not include that format. Update the criterion or add AC-042-04.

Traceability identifies the affected test suite and code when an AC changes. The suite still asserts the previous criterion and the implementation satisfies those older tests. Stable IDs make the affected links queryable.

Create the next functional build specification, FBS-061: Photo upload HEIC support, for the new or amended AC. Declare its build context and run the same five-stage cycle. New features, edge cases, bugs and new modules all use an FBS. Read the living spec for how RCF handles change.

What this doesn’t yet cover

RCF currently covers the work from intent to a slice that passes its tests. It does not yet cover PR review discipline, CI/CD gates, deployment practice or post-deploy observability against the same acceptance criteria. Traceability also needs these downstream connections to link tested code to customer use.

These downstream stages are planned extensions below the build cycle. They will use the same FBSs, ACs and IDs, with a reviewable commit at each stage. The site will be updated when that work is published.

Where to go from here

The following pages explain the individual concepts.

For the production work behind these practices, read Demo-ready versus production-ready.