What RCF inherits

RCF names practices the author developed across AI-assisted projects after thirty years in software. Requirements govern the work, acceptance criteria define verification, and traceability connects business decisions to code. Those practices come from earlier methodologies.

Each section identifies a contributor, its practice and its place in RCF. The framework combines these practices with explicit traceability for work carried out by agents. It remains an evolving synthesis.

Waterfall: the document chain and the audit trail

Waterfall introduced structure as software projects and contracts grew in the 1970s. Requirements, design, build, test and shipping followed in sequence, with a signed document at each handover.

RCF inherits waterfall’s written, owned and approved requirements, explicit scope exclusions and audit trail. These record decisions by the accountable people before implementation. Regulated industries still use waterfall variants for this structure and auditability.

Waterfall established written and approved documents. It did not guarantee checked links between those documents and implemented features. Requirements-driven development made those links explicit.

Requirements-driven development: traceability as a discipline

Requirements-driven development makes requirements drive the build. Artefacts link back to their requirements and forward to verification. A requirements traceability matrix records these connections and makes end-to-end coverage checkable.

RCF inherits most directly from RDD’s use in aerospace, automotive and medical software. DO-178C, ISO 26262 and IEC 62304 expect traceability from code to requirements and tests, with auditable coverage. The full RDD lifecycle includes elicitation, specification and verification, with a matrix maintaining the links. These practices have supported regulated software for decades.

RCF inherits the stance that requirements drive everything and traceability is a first-class, auditable discipline rather than a nicety. Where waterfall contributed the documents, RDD contributed the rigorous traceability across them and the idea that end-to-end coverage is something you prove, not something you assert. In RCF that lives in traceability as a property of the data model, with requirements sitting at the apex of the chain and driving what gets built below. What RCF does with the inheritance is take it out of the heavyweight ALM tooling the regulated world relies on and put it in the repository, enforced by the build cycle instead of a separate requirements database. For the fuller treatment, including where classical RDD is still the better choice, see RCF and requirements-driven development.

Waterfall and classical RDD assumed a stable specification. Requirements could be written, traced, verified and shipped against that target. Agile contributed a process for changing the specification while building.

Agile: the living spec

The Agile Manifesto turned twenty-five in February 2026. Practice has changed considerably since its seventeen authors met in Utah.

Agile contributed short feedback cycles: build a small increment, show it to users, learn and revise. It drew on lean ideas, including the Toyota Production System and lean startup practices. Small batches and fast feedback let organisations adapt to what they learn.

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.

Some teams have used agile to justify leaving requirements unwritten, treating sprints as accounting periods and adding criteria when tickets close. The manifesto values both working software and documentation, while giving the former priority. It assumes engineering discipline; XP made those practices explicit.

Extreme programming: tests first, and the customer writes the acceptance tests

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.

XP made acceptance tests the customer’s responsibility. The customer defines when a story is complete. Later agile terminology used acceptance criteria for this commitment. RCF’s acceptance criterion as the contract preserves that ownership: the developer implements behaviour the customer has agreed.

Behaviour-driven development: Given/When/Then as the AC syntax

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.

RCF uses Given/When/Then for every acceptance criterion. The AC-as-contract page explains how to write verifiable criteria using that syntax.

BDD exposes a failure mode: developers can write Gherkin scenarios after implementation to match existing code, then obtain superficial approval. The tests pass without establishing the intended behaviour. RCF’s theatre-risk page describes four safeguards: content standards, AI-assisted extraction, recorded gaps and approval commits. RCF inherits BDD’s syntax and adds these checks.

Domain-driven design: domain language as a first-class axis

Eric Evans’ 2003 book Domain-Driven Design defines ubiquitous language: consistent domain vocabulary in code, documents, tests and conversations. RCF adopts this connection between language and the model.

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 commits

Jez Humble and Dave Farley’s 2010 book established the deployment pipeline as an engineering practice. Every commit passes through the same build, test and deployment process toward production readiness. The pipeline itself is code and provides repeatable evidence.

RCF inherits the commit as a verifiable unit of work. Farley’s later work reinforces this principle. RCF’s five-stage build cycle requires a commit at Define, Build, Review, Test and Finalise. Each stage is recorded before the next starts, applying continuous delivery’s commit discipline to the build process.

Spec-driven development: the spec as a primary artefact

SDD is the most recent contributor. Martin Fowler’s site covers it. GitHub publishes Spec Kit, AWS provides Kiro and Tessl treats specifications as source artefacts with regenerable code. SDD emerged in 2025 to address AI-generated code that diverges from intent.

SDD gives agents a written specification as a stable target. Tooling can validate, regenerate and trace from it. RCF inherits this use of machine-readable intent.

An SDD specification may be YAML, a structured prompt or a configuration document. These provide agent inputs but do not by themselves state the business need and its reasons. RCF derives specifications from requirements. The two approaches operate at adjacent layers. Read RCF and spec-driven development for the comparison.

How the pieces fit together

Each approach contributes a distinct practice. Waterfall supplies documents, RDD supplies traceability, agile allows change, XP gives customers ownership of acceptance tests, BDD supplies their readable syntax, DDD keeps vocabulary consistent, continuous delivery makes commits verifiable and SDD gives agents a specification to build from.

RCF combines these practices with traceability in the data model. Requirements, stories, ACs, FBSs, suites and cases have opaque IDs. Code Nodes name implementing files or symbols and link them to ACs. Validation catches broken source references. Forward tracing connects business decisions to tests; backward tracing connects code to requirements. These checked relationships expose agent decisions that lack an agreed basis.

RCF is one current combination of these practices. Later methodologies may inherit from it. The purpose of this record is to identify where each practice originated.

Contributions at a glance

Where to go next

• The document chain The structure linking intent, architecture, tests and code. →
• Acceptance criteria as the contract The criterion and its one-to-one test-case mapping. →
• Theatre risk and the human signature The safeguards against approval without verification. →
• Quick tour The full method with a worked example. →