The living specCopy link

Discovery is part of the build, not a thing that happens before the build. The first time anyone has any real opinion about whether a feature works correctly is when they’re holding it. Lock the spec too early and you build the wrong thing. Refuse to lock it ever and you build forever. Every project on earth lives somewhere on that line.

Methodologies that pretend otherwise are the reason people still call this sort of structure “waterfall.” Real product work is a moving target. RCF starts from that assumption and builds the discipline outward from there.

The doc chain is a living documentCopy link

Every artefact in the chain is editable. The PRD changes as the product takes shape. Requirements get refined when user stories reveal something the PRD didn’t see coming. Acceptance criteria change when the team meets an edge case nobody thought of in the abstract. The technical architecture document changes when the build finds a constraint the early design didn’t predict.

What stays stable is the shape of the chain, not the contents inside it. REQ-014 still belongs to one PRD. It still generates user stories. Those still carry acceptance criteria, one-to-one with test suites. The relationships hold even as the words inside the documents move. IDs hold especially: REQ-014 means the same thing today and in six months, even if its text has been rewritten three times. The traceability runs on the IDs, not on the prose.

This is the trick the common arguments about agile-vs-waterfall keep missing. The thing worth holding rigid is the structure. The thing worth holding loose is the content that flows through it.

Traceability surfaces driftCopy link

When the docs change, the code doesn’t automatically follow. A gap opens up. The acceptance criterion now says one thing; the test suite still asserts the older thing; the implementation does whatever the older test drove it to do. None of that is wrong on its own. It just isn’t aligned anymore.

Traceability makes the gap visible. Forward tracing from a changed AC names exactly which test suites need to be regenerated. Forward tracing from a changed requirement names which stories are affected, which ACs sit under those stories, and which test suites sit under those ACs. Backward tracing from a piece of code says, of any line: this exists because of these ACs. If those ACs have moved on, the code is out of date.

This is the bit most methodologies don’t do. They write requirements once, ship, and quietly pretend the requirements are still authoritative six months later. They aren’t. They’ve drifted, and the drift is invisible because nothing in the system makes it visible. The docs and the code stop being two views of the same thing, and become two parallel stories that happen to share some words. RCF’s job is to refuse to let that happen quietly.

The gap is the next functional build specificationCopy link

Once the drift is visible, the response is mechanical. Open a functional build specification. List the in-scope acceptance criteria (the ones the gap touches). Declare the build context (which PRD sections, which TAD components, which modules and schemas). Run the five-stage build cycle. Define generates fresh test suites from the new AC text, or amends the existing ones. Build codes the diff against those tests. Review, Test, Finalise as usual.

No separate workflow for “change” versus “new build.” The unit of work is the FBS regardless. The cycle doesn’t care whether it’s closing a brand-new gap (because the PRD just grew) or an old gap (because a long-shipped requirement has been refined). It treats them identically.

Same shape for any changeCopy link

A bug fix. A production failure surfaces an acceptance criterion that was missing, or wrong, or weakly stated. Edit the AC (or add a new one). Traceability flags the affected test suite. Open an FBS scoped to that test suite. The cycle runs. The fix ships with the regression test that proves the AC, which is also the test that explains why the bug existed in the first place.

A new edge case. The PO realises the photo upload needs to handle users who already have a photo. Add a new AC under the existing user story. Traceability flags that the FBS that originally built the upload now has a story with a criterion that isn’t covered. Open a follow-up FBS scoped to the new AC, or amend the live FBS if it hasn’t finalised yet. Cycle runs. Done.

A new module. Billing gets added to the product. New requirements join the PRD. They generate stories, ACs, and a new TAD section. The gaps form a batch of FBSs and a sub-sequence inside the build sequence. The cycle runs against each FBS in dependency order. The chain grows; the methodology doesn’t.

A whole new feature. Same as a new module. Smaller scope. Same shape.

The size of the diff changes between these cases. The shape of the work doesn’t. That is the property worth paying for.

The AI’s job in the loopCopy link

This is where AI-assisted building actually pays for itself. With the methodology in place, an AI agent’s job becomes well-defined: read the current state of the docs, read the current state of the code, identify the diff, write the FBS that closes it, then run the cycle. The agent isn’t inventing what to change. The doc chain says what changed. The agent isn’t deciding when it’s done. The tests say. The agent is doing the thing it’s good at: applying a clear specification to a codebase, fast.

Compare that to the alternative most teams are running today. The agent is asked to figure out what to change, AND change it, AND know when it’s done. Three jobs, only one of which it’s reliably good at. The first and the third are exactly where AI agents quietly fail. With RCF, the methodology does those two jobs before the agent is invited in.

What doesn’t changeCopy link

The build cycle. The discipline. The one-AC-one-test-suite rule. The requirement that every change runs through the chain rather than around it. These are what make change cheap.

Loosen any of them and change gets expensive again. Skip the AC update on a bug fix and the test suite never catches the regression next time. Skip the Define stage on a small change and the test ends up describing whatever the code did, not whatever the spec demanded. The methodology earns its keep precisely because the rules don’t move when the content does.

The chain outlives the implementationCopy link

Everything in the chain above the test cases is written in domain language. PRD, requirements, user stories, acceptance criteria, test suites. None of it depends on the language the code is written in, the framework it runs on, or the cloud it’s deployed to. Only the test case implementations, the actual code that exercises the system, are bound to the runtime. Everything above them is portable.

Most enterprise IT spend doesn’t go on greenfield. It goes on modernisation. The Python codebase a team has been porting to Go for nine months because nobody can hire for the original stack. The monolith finally being broken into services, years overdue. Each of those starts with the same joyless ritual. A team sits down with old code and tries to reverse-engineer what the system was supposed to do, hoping the original intent survived fifteen years and four engineering teams. That archaeology is where most rewrites quietly fail. The replacement looks like the original until someone notices a behaviour the old code did on purpose that nobody remembered to preserve.

An RCF chain skips the archaeology. The chain is the intent, in domain language, kept current with the live system because the build cycle won’t close a gap without updating it. On the Python-to-Go port, the PRD, requirements, stories, acceptance criteria and test suites come across unchanged. Only the test case implementations get rewritten, in Go this time, against the same TS contracts. The new code is built to pass them. The monolith split is the same move at a different scope. The chain doesn’t move; the FBSs do, rescoped to the new module boundaries. The work shifts. The spec doesn’t need to be rediscovered.

Greenfield is where RCF is easiest to justify and where it pays back least. The real return is the first rewrite, and most systems get rewritten eventually. When the rewrite comes, the team that built with RCF still has the spec. The team that didn’t is reading old code.

Short version: RCF didn’t make the spec immutable. It made the shape of the spec immutable, while letting the content breathe. The shape is what makes the content auditable as it changes. That is the thing the methodology is for.

It’s also what structurally prevents AI drift, the team-level discipline decay that comes from skipping methodology in AI-accelerated work. When the agent is asked to figure out what to change, it drifts; small, plausible-looking divergences accumulate until the code and the intent part company. With the chain holding the shape, the agent isn’t free to drift. The structure keeps the work anchored to the spec, change by change.