Methodology

The Requirements Confidence FrameworkCopy link

A working method for closing the gap between “the AI built something” and “the AI built the thing you actually asked for.”

What RCF isCopy link

RCF is a methodology for the build-side of the software lifecycle. As it stands today, that means everything between an agreed PRD and TAD at one end, and a feature shipped with traceability from a business decision to the line of code that satisfies it at the other. Upstream and downstream of that are deliberately out of frame today; both are on the roadmap.

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 chain is a Y-shape with two arms that meet at the build. Intent comes down one arm (PRD, requirements, user stories, acceptance criteria) and architecture down the other (TAD, components, ADRs). Both arms feed into the build sequence, then into the five-stage build cycle, and the code arrives last with one job: to make the tests pass. Done well, you end up with an unbroken trace from a business decision to a line of code, and a way to ask of any line: why does this exist? The answer is always upstream.

RCF runs on plain markdown, JSON manifests, and git. A team can adopt it without anybody’s permission and without buying anything. The methodology stands on its own. The scoping page walks the current frame in detail, including what’s on the roadmap for the bookends.

What RCF is forCopy link

Three things, named the way the rest of the industry names them.

RCF is the answer to AI drift, the team-level discipline decay AI-generated code exposes when the engineering practice around it hasn’t kept up. Drift is the price of taking the speed and skipping the methodology. The chain, the cycle and the one-AC-one-suite rule are what keep the speed without paying it. The demo-ready versus production-ready page is where the gap AI opened up is spelled out.

RCF is the answer to the AI trust gap, the gulf between “the agent wrote some code” and “the code does what was asked.” The trust doesn’t sit with the agent. It sits with the contract the agent had to satisfy. The acceptance criteria as the contract page is where the mechanism is laid out, and the theatre risk and the human signature page is where the structural defence against the contract becoming ceremony is described. The two pages together are how RCF keeps the trust anchored to a real human commitment.

RCF is what an AI SDLC looks like when you take requirements seriously. Same five stages every cycle, agent or human in the loop, each stage a commit that a senior reviewer can read on its own. The build cycle page is the working version of that claim.

How to startCopy link

The methodology is easiest to apply on something concrete. Pick a feature you’re about to build, or one you just built; legacy works too.

  1. Write a one-page PRD for it, then the requirements, then the user stories with acceptance criteria.
  2. For each acceptance criterion, write the test suite first. One criterion, one suite.
  3. Build the code to make the tests pass. Spec-driven development fits naturally inside this stage. Commit at each of the five build-cycle stages.
  4. Repeat per slice. The chain accumulates as you touch the codebase.

Open-source tooling to streamline the discipline is on the way; more on that soon. The methodology doesn’t depend on it. The tooling is how you make the discipline tractable at speed.

The pagesCopy link

  1. Quick tour

    The whole methodology in one read. The problem, the core idea, the document chain, the build cycle, and a worked example.

  2. CTO pitch (slideshow)

    The 45-minute pitch for engineering CTOs on shipping AI-assisted code at enterprise grade. Hand-rolled slide deck, present from the browser.

  3. Methodology lineage

    The elements RCF synthesises from across the industry’s methodology history. A credit roll for the pieces that contributed to where the methodology currently stands.

  4. What RCF covers, and what it doesn’t

    The methodology, as published today, scopes the build-side of the lifecycle, downstream of the PRD and TAD being agreed. What that means and what’s coming next.

  5. Theatre risk and the human signature

    No methodology is theatre-proof. The four-part defence (standards, AI-assisted extraction, the visible gap, the approval gate) and how it applies at every layer of the chain.

  6. Requirements as the source of truth

    Why requirements anchor the work, not code, not tests, not documentation. The cost of forgetting this.

  7. The document chain

    A Y-shape. Intent comes down one arm (PRD, requirements, user stories, ACs), architecture down the other (TAD, components, ADRs), and both meet at the build (sequence, FBS, test suite, test case). Each layer earns its keep.

  8. Architectural decisions and ADRs

    The layer on the architecture arm where the consequential choices get pinned down. Context, decision, alternatives, consequences.

  9. Acceptance criteria as the contract

    The central primitive. One acceptance criterion, one test suite, no negotiation.

  10. Traceability, forward and backward

    Trace a line of code back to a business decision. Trace a business decision forward to every test that proves it ships.

  11. The build cycle

    Per spec: Define, Build, Review, Test, Finalise. Each stage commits. Each commit is honest.

  12. The living spec

    The doc chain is editable on purpose. When the spec moves, traceability surfaces the gap, and the gap becomes the next build cycle. Iteration as first-class work.

  13. Demo-ready versus production-ready

    AI gets you to demo-ready fast. Production-ready is a different problem and the same problem it always was. The gap between them is where the methodology earns its keep.

  14. Document types

    A single reference page covering every document RCF defines: purpose, ID scheme, and where each one sits in the chain.

  15. FAQ

    Is this waterfall? Do I need AI? Does it work on legacy code? Short answers, plainly stated.

  16. Glossary

    Every term RCF uses, defined once, with links to the page where each one cashes out.