On this page

Related reading

Methodology / Overview

The Requirements Confidence Framework

A method for linking software requirements to the code and tests that satisfy them.

Wire your agent Read the quick tour

What RCF is

RCF is a methodology for building software with traceability from a business decision to the code that implements it. It connects requirements, architecture and acceptance tests so teams can check that AI-assisted work meets the agreed requirements.

RCF coverage within the wider software lifecycle A horizontal eight-stage lifecycle band reading left to right: Discovery, Shaping, PRD and TAD agreement, Build sequence, FBS (functional build spec), Build cycle, Deploy gates, Operate and Learn. A dashed loop-back arrow runs from the digital operator at the right back to Shaping on the left. The cards sit under five treatment bands. Cards 1 and 2 (Discovery, Shaping) are muted and outlined in light grey, labelled OUTSIDE RCF: pre-methodology exploration. Card 3 (PRD and TAD agreement) is paper-filled with a burnt-orange dashed bracket, labelled UPSTREAM: the multi-role agreement work that the next RCF workstream covers. Cards 4 through 6 (Build sequence, FBS, Build cycle) are solid burnt-orange, labelled BUILD PHASE, CURRENT FOCUS: what the published methodology covers today. Card 7 (Deploy gates) is paper-filled with a burnt-orange dashed bracket, labelled DOWNSTREAM: PR, merge and deploy gating work the methodology will pick up next. Card 8 (Operate and Learn) is muted and outlined in light grey, labelled OUTSIDE RCF: the digital-operator territory where shipped product is run and learned from. The loop-back arc returns from the digital operator back to Shaping, marking how operating-time learning feeds the next product slice's shaping, a cross-methodology feedback line rather than an RCF-internal one. Outside RCF. Discovery and shaping happen before the methodology engages. Try something, decide whether it is worth pursuing, settle on the shape of the work. RCF has limited grip here today. OUTSIDE RCF Upstream. The multi-role, multi-stakeholder agreement that turns a shaped idea into a written PRD and a TAD everyone signs off on. On the RCF roadmap as the next workstream upstream of the build phase. UPSTREAM Build phase, current focus. The slice-by-slice build side: order the work, spec a slice, build the slice. Traceability runs from an agreed business decision down to the lines of code that satisfy it. BUILD PHASE · CURRENT FOCUS Downstream. PR, merge and deploy gating between a finished build cycle and a live service. On the RCF roadmap as a separate workstream downstream of the build phase. DOWNSTREAM Outside RCF. The digital-operator territory: running a live service, learning from real use, deciding what becomes the next slice. RCF feeds this loop but does not itself describe how to operate in production. OUTSIDE RCF Discovery. Is this idea worth pursuing. Outside RCF: build, learn, throw away. The methodology kicks in only if and when the exploration produces something worth productising. Discovery is it worth it Shaping. Take a vague idea and decide the shape of the work. The role mix here is broad: product, design, architecture, sometimes compliance and legal. Outside RCF today. Shaping decide the shape PRD and TAD agreement. The multi-role, multi-stakeholder negotiation that produces an agreed PRD and an agreed TAD. Upstream of the build phase. Coming next as a separate RCF workstream. PRD / TAD what to build Build sequence. Decompose the agreed PRD and TAD into an ordered set of functional build specs (FBS slices). The first piece of the in-scope methodology. Build sequence order the slices FBS. Functional build spec. The unit of work the build cycle runs against. One slice through the document chain at a time. FBS spec a slice Build cycle. Define, build, review, test, finalise. The five-stage iterative loop applied to each FBS slice. The operating loop of RCF. Build cycle build the slice Deploy gates. PR review, merge, deploy. The gating between a finished build cycle and a live service. Downstream of the build phase. Coming next as a separate RCF workstream. Deploy gates PR, merge, deploy Operate and Learn. The digital operator runs the live service, watches real use, decides what becomes the next slice. Outside RCF: the methodology feeds this loop but does not describe how to run in production. Operate / Learn digital operator Loop-back. The digital operator's learning from real use feeds back into the next product slice's shaping. Dashed and muted because it is cross-methodology feedback (operator's territory into the pre-RCF shape), not part of RCF's linear forward flow. feedback into next slice RCF coverage within the wider software lifecycle (vertical layout) A vertical top-to-bottom eight-stage stack of the wider software lifecycle: Discovery, Shaping, PRD and TAD agreement, Build sequence, FBS, Build cycle, Deploy gates, Operate and Learn. The cards sit under five treatment bands shown as a bracket column on the left. Cards 1 and 2 are muted as outside RCF, the pre-methodology exploration phase. Card 3 is outlined in burnt orange as upstream RCF scope on the roadmap, the PRD and TAD agreement work. Cards 4 through 6 are solid burnt orange, the build phase currently in scope. Card 7 is outlined in burnt orange as downstream RCF scope on the roadmap, the deploy-gates work. Card 8 is muted as outside RCF, the digital-operator territory. A loop-back stub at the bottom marks the return to shaping when operating-time learning feeds the next slice. Outside RCF. Discovery and shaping. Pre-methodology exploration, outside the current scope. OUTSIDE Upstream. The PRD and TAD agreement work upstream of the build phase. On the RCF roadmap. UPSTREAM Build phase, current focus. The slice-by-slice build side: agreed PRD and TAD through to a built slice. BUILD PHASE Downstream. PR, merge and deploy gating work downstream of the build phase. On the RCF roadmap. DOWNSTREAM Outside RCF. The digital-operator territory: running the live service and learning from real use. OUTSIDE Discovery. Is this idea worth pursuing. Outside RCF. Discovery is it worth it Shaping. Decide the shape of the work. Outside RCF today. Shaping decide the shape PRD and TAD agreement. Multi-role agreement on what to build. Upstream RCF scope, on the roadmap. PRD / TAD what to build Build sequence. Order the FBS slices. In the build phase. Build sequence order the slices FBS. Functional build spec. In the build phase. FBS spec a slice Build cycle. Define, build, review, test, finalise. In the build phase. Build cycle build the slice Deploy gates. PR review, merge, deploy. Downstream RCF scope, on the roadmap. Deploy gates PR, merge, deploy Operate and Learn. The digital operator runs the live service and learns from real use. Outside RCF. Operate / Learn digital operator Loop-back. Operating-time learning feeds the next product slice's shaping. Cross-methodology feedback, not part of RCF's linear forward flow. feedback into next slice
Discovery → Shaping → PRD/TAD → Build sequence → FBS → Build cycle → Deploy gates → Operate / Learn

The document chain has two arms. The intent arm links the PRD, requirements, user stories and acceptance criteria. The architecture arm links the TAD, components and architecture decision records (ADRs). Both feed into the build sequence and then the five-stage build cycle.

Code is the final node in the same graph. It links to the acceptance criteria it implements and is validated like every other link. This creates a trace from each business decision to its implementation and lets a reviewer identify why a line of code exists.

RCF uses plain JSON documents, Markdown build specs and git. Teams can adopt it without permission or a purchase. The methodology works independently of the tooling. Read what RCF covers for the current scope and roadmap.

What RCF is for

RCF addresses three problems in AI-assisted software delivery.

AI drift. AI-generated code can expose a decline in a team’s engineering discipline when its practices have not kept pace. RCF addresses this through the document chain, build cycle and one-test-suite-per-acceptance-criterion rule. Read about AI drift and the gap between demo-ready and production-ready software.

The AI trust gap. Generated code needs evidence that it does what was asked. Acceptance criteria define the contract the agent must satisfy. Human approval and safeguards against theatre risk keep that contract tied to a real human commitment.

An AI software development lifecycle (SDLC). RCF uses the same five-stage build cycle for work carried out by an agent or a human. Each stage produces a commit that a senior reviewer can assess on its own.

How to start

Choose a feature you are about to build or have recently built. You can also apply RCF to legacy code.

  1. Write a one-page PRD, then the requirements and user stories with acceptance criteria.
  2. Write a test suite on each user story and, inside it, one test case for each acceptance criterion, before writing the implementation. One criterion, one case that proves it.
  3. Implement the code to pass the tests. Spec-driven development fits inside the Build stage. Commit at each of the five build-cycle stages.
  4. Repeat for each slice of work. Extend the document chain as you work through the codebase.

RCF Lite is optional, open-source tooling under Apache-2.0 that helps teams apply RCF at speed. Install rcf-lite from npm to get the rcf CLI.

Where to go next

Wire your agent Read the quick tour