Questions worth answering up frontCopy link

No. Waterfall locks the requirements at the start, builds the entire product against the locked spec, then tests, then ships. RCF does the opposite. The PRD is a living document. Requirements get refined as the product takes shape. Acceptance criteria change when the team meets an edge case nobody saw in the abstract. The architecture bends when the build finds a constraint the early design didn’t predict. The whole chain is editable on purpose. See The living spec for the full argument.

The build sequence is iterative too. Each functional build specification is a slice you can ship, in principle, on its own. You don’t build everything and then test everything. You build a slice, test it, ship it, build the next slice. Closer to vertical-slice agile than to waterfall by a long way.

The thing RCF shares with waterfall is the insistence that decisions about what to build get written down before the building happens. That’s not waterfall’s exclusive idea. It’s just a thing the industry spent a decade rejecting because the cost of writing it down was higher than the cost of getting it wrong. With AI doing the typing now, the cost equation has flipped, which is most of what the eighty-twenty flip page is about.

The doc chain is meant to change. Edit the PRD, the story, the AC, the TAD section, whichever level the change lives at. The IDs stay stable; the content moves. Traceability then surfaces the gap between the updated docs and the existing code, because the AC text and the test suite it owns no longer match, or the test and the code no longer match. You can see exactly which suites need regenerating and which slices need rebuilding.

The gap is the next functional build specification. Open the FBS, list the in-scope ACs (the ones the change touches), declare the context, run the five-stage cycle. Define rewrites the test suites from the new AC text. Build codes the diff. Review, Test, Finalise as usual. There’s no separate workflow for “change” versus “new build.” The unit of work is the FBS regardless.

Same shape whether the change is a bug fix, a new edge case, a new module, or a whole new feature. The size of the diff varies. The shape of the work doesn’t.

No. The methodology was designed in a world with AI in it, and it’s sharpened by the kind of failures AI agents produce, but the discipline works on any kind of team. A human-only team running RCF gets the same traceability, the same forward and backward queries, the same per-feature cycle with five honest commits per slice.

What AI changes is the cost-benefit. Without AI, the cost of running the methodology is roughly the cost of the documentation discipline plus the cost of writing tests first. That’s not free. Teams have to want it. With AI in the loop, the methodology is almost a precondition for trusting agent output, because without the chain you’ve no way to check the agent’s self-report. So AI doesn’t make RCF necessary; it makes it economically obvious.

Adopting on a new project is roughly free, because you’re writing the documents you should have written anyway, just in a more structured shape. The first PRD takes longer than the team is used to. The first build sequence takes a couple of sittings to get right. After that, the cycle becomes the cycle.

Adopting on an existing project is harder. The honest answer is that you don’t retrofit RCF onto an existing codebase in one go; you adopt it forward. New work runs through the cycle. Existing code gets RCF artefacts written for it opportunistically, usually when somebody is about to change it. After six months of forward adoption, most of the active surface area of the product is in the chain. The bits nobody touches stay outside the chain, which is fine, because nobody’s running them through the cycle.

Yes, with caveats. Legacy codebases are exactly where backward traceability is most valuable, because nobody can remember why anything was decided. Even partial adoption pays back: write a PRD for the feature you’re about to change, write the AC for the behaviour you’re about to alter, run the changed slice through the build cycle. The chain you build covers what you touch.

The caveat is that you don’t go back and write ACs for every feature that was already shipped, because reverse-engineering the tests against the code is high-effort work. The exception is regression: for critical features that change often, retroactive ACs and the suites that come with them can be worth the cost, because the regression suite they produce earns its keep on every future change. For everything else, adopt forward and let the chain accumulate.

Any. The methodology is language-agnostic. The document chain is in markdown and JSON. The build cycle is a discipline, not a tool. Test suites get written in whatever your stack’s test framework is. The only requirement is that you can name an AC ID in a test’s title or metadata so traceability has something to hook on.

Acceptance criteria as Given/When/Then sentences come straight out of the BDD lineage. The one-to-one mapping from AC to test suite is the acceptance-testing discipline taken to its logical end. Writing tests before code is TDD. RCF doesn’t invent these ideas; it pins them together so that they actually stick in practice rather than getting promised in a planning meeting and skipped in the rush to ship.

The thing RCF adds that BDD and TDD don’t insist on is the document chain above the AC. BDD says “write behaviours,” and is silent on where those behaviours come from. RCF says behaviours come from acceptance criteria, which come from user stories, which come from requirements, which sit in a PRD that someone signed off. That upward chain is what the BDD-and-TDD lineage left implicit. Implicit things rot. Explicit things survive.

Yes, but it’s optional. The methodology is designed to work with plain markdown files, plain JSON, and git. You can run the whole thing with a text editor and a test runner.

I’m building tooling. The initial scope is the tedious, load-bearing parts: surgical editing of RCF documents (so you can change one AC without breaking the chain), validation (no orphaned ACs, no dangling pointers, no cycles in the build sequence), and traceability (forward and backward queries across the chain). The first set of tools is about keeping a chain clean and queryable as it grows.

Generative work, where the tool drafts new requirements, stories, ACs, or test suites with AI assistance, is a separate scope. It’s coming, but it sits behind the editing and validation layer, because you need to keep what’s there honest before you start generating more of it.

The tooling is an accelerator, not a prerequisite. It runs against the same markdown and JSON files you’d be writing anyway. When the first pieces are ready for public use, they’ll have their own page. For now, the methodology stands on its own.

It scales by product, not by org. Each product has one PRD, one TAD, one build sequence. An organisation with twenty products has twenty chains running in parallel. The chains don’t merge; that would be a catastrophe in any methodology. What they share is vocabulary and tooling, not document content.

Inside a single product, RCF scales by the build sequence. A small product might have ten FBSs. A medium one might have fifty. A large one might have several hundred. The cycle is the same per FBS. The sequencing decisions get harder as the graph grows, which is where good product thinking earns its keep, but that’s a separate problem from the methodology.

Then you don’t have a product owner, you have a stakeholder who attends meetings, and the project is going to ship something nobody signed off. That’s a recoverable situation, but it’s recoverable upstream of the methodology, not inside it. RCF can’t compensate for missing ownership; nothing can. What it can do is make the absence visible, which is sometimes enough to fix it.

On smaller projects, the operator (or the engineer-acting-as-PM) writes the ACs themselves, with sign-off from whoever’s playing the PO role. That works, as long as the writing happens before the building. ACs written after the fact are not ACs. They’re commentary on what got built, which has its own uses, but isn’t the same thing.

Yes. Anyone can adopt the methodology. Anyone can teach it. Anyone can run a project on it without asking permission. The whole point of publishing the pages on this site is that the methodology is open and adoptable without involvement from me. I use it myself, and I’m building tooling that runs it well, but the methodology itself isn’t something I own.