The living spec

The living spec is RCF’s stance that every artefact in the document chain stays editable for the life of the product: the words change, the shape and the IDs hold, and change arrives through the same build cycle as new work.

Teams learn during implementation as well as before it. Stakeholders can assess a feature more concretely when they use it. Freezing scope too early can preserve the wrong behaviour; leaving it entirely open prevents completion.

RCF assumes product requirements will change and provides a repeatable process for implementing those changes.

The doc chain is a living document

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 cases in the story’s test suite. 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.

Keep the document relationships stable while allowing their content to change.

Traceability surfaces drift

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. What makes that a mechanical check rather than a matter of trust is the Code Node: the file (or symbol) is registered against the ACs it implements, so the same rcf validate that walks the spec graph now walks the code link too, and a rename, move or deletion that breaks the tie surfaces as a stale reference instead of a dead pointer nobody notices.

Requirements written once can stop describing the software after it ships. RCF makes differences between documents and code visible so the team can address them.

The gap is the next functional build specification

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.

Changes and new features use the same FBS and build cycle. This applies whether a new requirement creates the work or a refinement changes an existing feature.

Same shape for any change

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. Run the cycle to complete the change.

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. Use the same process as a new module, with a smaller scope.

Changes vary in size but follow the same workflow.

The AI’s job in the loop

An agent reads the current documents and code, identifies the required changes, writes an FBS and runs the build cycle. The document chain specifies the change, and the tests determine completion. The agent applies that specification to the codebase.

Without those inputs, an agent must decide what to change, implement it and judge whether it is complete. RCF supplies the scope and completion checks before the implementation pass.

What doesn’t change

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.

Skipping the AC update on a bug fix can leave the next regression undetected. Skipping Define can produce tests that describe existing code instead of required behaviour. The rules stay fixed while the requirements change.

The chain outlives the implementation

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 spending goes to modernisation. A Python-to-Go port or a monolith split often begins by reconstructing intended behaviour from old code. After years of team changes, this can miss deliberate behaviour that the replacement must preserve.

An RCF chain records current intent in domain language. A Python-to-Go port retains the PRD, requirements, stories, criteria and suite contracts. The test case implementations are rewritten in Go against those contracts, then the new implementation is built to pass them. A monolith split keeps the chain and rescopes FBSs to new module boundaries. The team does not need to rediscover the specification.

RCF is easiest to justify on a new project, but its largest return comes during a rewrite. Most systems are eventually rewritten. A maintained chain preserves the specification the replacement needs.

RCF keeps document relationships stable while allowing their content to change. That structure makes each change auditable.

The same structure prevents AI drift, the decline in team discipline when AI output accelerates. The chain defines each change and keeps agent output tied to the specification.