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
Thirty years in this trade tells me the same thing on every project. Most teams aren’t lucky enough to have proper requirements, user stories, and acceptance criteria in the first place. The ones that are have requirements nobody owns, stories that don’t tie back to anything in particular, and acceptance criteria the developer wrote at the last minute because the product owner has gone quiet again. A bag of tech debt accepted as the cost of moving fast. RCF is what falls out the other side of watching that pattern enough times, and then watching AI sharpen it instead of fixing it. It’s what you reach for when vibe coding stops being enough.
The frame is simple. Requirements anchor the work. Every requirement breaks down into user stories. Every story carries acceptance criteria. Every acceptance criterion maps to a test. Code arrives last, and its only job is to make the tests pass. Done well, you end up with an unbroken chain 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.
In current vocabulary, RCF is a lightweight AI SDLC, built around requirements confidence rather than IDE features. Call it an AI-augmented SDLC if you prefer; same shape. The category claim is straightforward. This is the lifecycle, with the discipline put back where AI made it cheap to skip.
The doc chain is a living spec, not a frozen artefact. Requirements change. Acceptance criteria get refined. The architecture has to bend when the build finds a constraint nobody saw coming. When that happens, traceability makes the gap between docs and code visible, and the gap becomes the next build cycle. Same shape whether it’s a bug fix, a new edge case, or a whole new module.
RCF is open. No paywall, no tool you need to buy. The pages below describe the whole thing, end to end. Read it in order if it’s new to you. Jump in if it isn’t.
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 that follows when AI-generated code outpaces the engineering practice around it. 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 eighty-twenty flip page is where the economics of the drift are 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 that mechanism is laid out.
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.