What RCF inheritsCopy link

The label was new when I started using it. The discipline wasn’t. After thirty years of watching the industry argue its methodologies against each other, the thing I’d been doing through AI agents on every project finally had a name. Requirements that anchor the work. Acceptance criteria the test can’t cheat on. A chain you can walk from a business decision to a line of code. I called it RCF because I needed a label. But the label pointed back at every methodology the industry has ever taken seriously, and it was the inheritance that earned its keep, not the new badge on top.

So this page is the credit roll. Each contributor named, what it added, and where in RCF the addition lives. The point isn’t that RCF is the end of a line. It isn’t. It’s where this synthesis currently stands. The methodologies below were each rational for their moment and each gave something forward. RCF’s claim is narrow: that the pieces hold together when you pin them with traceability and run them against AI agents that otherwise won’t carry the discipline for you.

Waterfall: the document chain and the audit trailCopy link

Waterfall gets a kicking in modern writing, and most of it is unfair. When it took shape in the 1970s, the alternative wasn’t agile. The alternative was nothing. Software projects were getting bigger, contracts were getting bigger, and somebody had to put a structure on the work so the people paying for it could tell what they were paying for. Requirements, design, build, test, ship. In that order. With a signed document at each handover.

What it contributed is the document chain itself. The notion that requirements get written down, owned, and agreed before the build is the apex of RCF’s chain. Out-of-scope named as deliberately as in-scope. Decisions made by the right people at the right time. The audit trail isn’t there to satisfy compliance; it’s there because traceability is how an honest project survives contact with reality. Regulated industries still ship on waterfall variants for exactly this reason. The audit shape of the model is a feature, not a bug, and RCF inherits the feature.

What waterfall couldn’t do was let the spec move. The big-document-at-the-start design works only if your understanding of the problem doesn’t change while you build. In practice, it always does. That gap is where the next contributor comes in.

Agile: the living specCopy link

The Agile Manifesto turned twenty-five in February 2026. That’s long enough for the manifesto to be older than some of the engineers reading this page. It’s also long enough for the practice to have drifted a long way from what the seventeen people in that Utah ski lodge were trying to do.

What agile contributed is the posture that the spec keeps moving and that’s fine. Build a small thing, show it to someone, find out what was wrong, build the next small thing. Compress the feedback loop until the spec can’t go stale because it’s never frozen. The thinking borrowed heavily from lean ideas, Toyota Production System on one side, lean-startup-flavoured product thinking on the other. Both assume small batches, fast feedback, and an organisation that reorganises around what it’s learning.

RCF inherits the living-spec idea straight from this. The document chain is editable on purpose. When a build finds a constraint nobody saw coming, the spec moves, and the gap between docs and code becomes the next build cycle. Iteration is first-class work, not a deviation from the plan.

The honest postscript: somewhere in the gap between the manifesto and the consulting industry that grew up around it, “we’re agile” came to mean “we don’t write requirements down.” The sprint became the unit of accounting. The standup became the status report. The acceptance criteria, on most teams I’ve worked with, got drafted by the developer five minutes before the ticket got closed. The manifesto didn’t say that. It said working software over comprehensive documentation, with the direct caveat that there’s value in both. Twenty-five years of practice bent the preference into an excuse. The discipline didn’t come from agile; agile assumed you’d bring it. The next contributor is where the discipline got named.

XP: tests first, and the customer writes the acceptance testsCopy link

Extreme Programming, mostly Kent Beck’s framing from the late 1990s, was the methodology that took agile’s feedback claim and added the engineering discipline it assumed. Pair programming, continuous integration, refactoring as a named practice, small releases, collective ownership. And two specific moves that RCF inherits at the centre of its chain.

First, tests first. Test-driven development came out of XP, not the other way around. Write the failing test in code, write just enough implementation to make it pass, refactor. The discipline forces you to know what success looks like before you build, and it leaves a regression net behind as a side effect. RCF inherits TDD’s test-suite layer wholesale. Tests prove the contract holds, and the contract is the thing the test was written against, not a thing the developer invented while coding.

Second, and more important, XP made acceptance tests the customer’s job. Beck’s framing was direct: the customer writes the tests that decide whether the story is done. The vocabulary changed over the years. XP called them acceptance tests; agile teams later called them acceptance criteria. The move was the same. The thing the build has to satisfy doesn’t belong to the developer. It belongs to the person who knows what good looks like. RCF’s acceptance criterion as the contract is the direct descendant. The AC isn’t a developer artefact dressed up; it’s a customer commitment the developer’s code has to meet.

BDD: Given/When/Then as the AC syntaxCopy link

Behaviour-driven development grew out of TDD in the mid-2000s, mostly through Dan North, with the explicit aim of fixing the way TDD encouraged engineers to write tests in implementation language. North’s framing was that BDD is “TDD done right” because it puts the verb on observable outcomes rather than internal mechanics. The contribution was a sentence shape product owners and engineers could both read and both argue about. Given a precondition, when an event happens, then an observable thing must be true. Three clauses, one specific behaviour.

That sentence shape is RCF’s AC syntax. Literally. Every acceptance criterion in an RCF chain is a Given/When/Then. The AC-as-contract page covers what makes a good one and what makes a bad one, but the syntax is BDD’s and we keep it without apology.

BDD also gives RCF its sharpest adversary. The failure mode I’ve watched a few times now: the Gherkin scenarios get written, but they get written by the developer, after the fact, to match what the code already does. The product owner skims and signs off. The shared vocabulary becomes theatre. The tests still pass, because they were written to pass. Nobody’s wiser. The methodology didn’t fail. The discipline ran out. Tests are a brilliant contract when the thing being tested is the right thing; they’re a thorough way of being wrong when it isn’t. RCF’s structural defences against the theatre version live on the theatre-risk page: standards on what an AC must cover, AI-assisted extraction against those standards, a visible diff between what’s present and what’s required, and approval gates with commit rigour. BDD is what RCF inherits the syntax from. The defences are what RCF adds.

DDD: ubiquitous language and the domain as a first-class axisCopy link

Domain-Driven Design, Eric Evans’ 2003 book, isn’t usually thought of as a methodology in the same breath as agile or XP. It’s more often filed as a design pattern. But the central idea, that the language and the model are the design, is doing structural work in RCF, and the page would be dishonest without crediting it.

Evans’ phrase was “ubiquitous language”: the deliberate practice of using the domain vocabulary, consistently, in the code, the docs, the tests, and the conversations, with no translation at the boundary between any of them. RCF inherits that posture twice. Once in the AC ID itself, which is opaque, load-bearing, and the same string in the requirement, the test runner, and the code annotation. There’s no translation layer; the ID is the lookup key. And again in requirement attributes. Every requirement carries a domain tag alongside its functional, non-functional, or regulatory classification. Requirements partition by domain, not just by function. That’s DDD thinking applied at the methodology layer rather than the code layer.

Continuous delivery: every stage commitsCopy link

Jez Humble and Dave Farley’s 2010 book put the deployment pipeline at the centre of engineering practice. Every commit goes through the same build, test, and deploy machinery, all the way to production-readiness. The pipeline is code. The pipeline tells the truth. Most teams reading this page have a pipeline of some shape because of work that traces back here.

The piece RCF inherits is narrower than the whole CD story. It’s the claim that the commit is the unit of truth. Farley’s later work defends commit-as-honest-unit against ceremony-as-honest-unit, and RCF’s five-stage build cycle (define, build, review, test, finalise) runs on that principle. Each stage commits. Each commit is honest. Nothing rolls forward on faith. You can’t fake the review if the review has to commit before the test stage starts. The cycle works as a forcing function because the commit cadence is the same forcing function CD applied to deployment, applied one layer up the chain.

SDD: the spec as a primary artefactCopy link

Spec-driven development is the most recent contributor and the most directly comparable methodology. Any methodology piece written in 2026 has to engage with it on its own terms. Martin Fowler is publishing on it. GitHub shipped Spec Kit as a first-party toolkit. AWS shipped Kiro as an agentic IDE built around the idea. Tessl has gone the furthest, treating the spec as the source artefact and the code as a regenerable output. SDD emerged in 2025 as the explicit response to the vibe-coding failure mode, where AI agents produce plausible code that drifts from intent.

What SDD contributes is real. A written specification, treated as the primary artefact, gives AI agents a stable target. Tooling around the spec can validate, regenerate, and trace. The spec becomes where intent lives, not the chat history. RCF inherits the executable-source-of-truth idea directly. The chain is machine-readable by design, not by accident.

Where SDD leaves something for RCF to pick up is in what it means by “spec”. In a lot of the tooling, “spec” ends up looking like a YAML file or a structured prompt or a config document with placeholder hierarchies. That’s a fine artefact for an agent to consume. It is not, in itself, a description of what the business wants and why. RCF treats requirements as primary, with the spec downstream. SDD treats the spec as primary. The two aren’t opposed; they sit at different layers of the same chain. RCF inherits SDD’s spec-as-truth move and puts it under a layer that names which spec was the right spec. For the longer version, see RCF and spec-driven development.

How the pieces fit togetherCopy link

Step back. None of these contributors got everything right, and none of them is trying to do what RCF is trying to do. They’re each pointing at one piece of the problem from a particular angle. Waterfall wanted a document chain. Agile wanted the chain to keep moving. XP wanted the customer to own the acceptance test. BDD wanted that test to read as a sentence everyone agreed with. DDD wanted the vocabulary to hold across every boundary. Continuous delivery wanted the commit to be the unit of truth. SDD wanted the spec to be the primary artefact for an AI-built world.

RCF’s contribution is putting the pieces together, with one move of its own: traceability as a property of the data model itself, not a tool you bolt on. Every requirement, story, AC, FBS, test suite, and test case carries an opaque ID. Code references the AC ID it implements. The string is the lookup key. Trace forward from a business decision to every test that proves it ships. Trace backward from a function in the export handler to the requirement it serves. Each hop is mechanical, because the structure is mechanical. That’s how you stop AI agents quietly making decisions you didn’t make. The chain is the thing that catches them.

The chain isn’t the destination of a line of methodologies. It’s where this synthesis currently stands. The next thing might inherit pieces from RCF the same way RCF inherited pieces from the methodologies above. The point of the credit roll isn’t to plant a flag. It’s to name the pattern: methodologies build on each other, and the honest move is to say which pieces came from where.

Contributions at a glanceCopy link

For the structural detail, read the document chain and acceptance criteria as the contract. For what stops the chain becoming theatre, read theatre risk and the human signature. For the whole methodology end to end, start with the quick tour.