Concept
The living specCopy link
Product owners often don’t know what they want until they see it. That isn’t a flaw in product ownership. It’s how product ownership works. RCF was designed around it.
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.
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.