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
Every project rhymes. 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 an AI-augmented SDLC, built around requirements confidence rather than IDE features. The shape is the lifecycle most teams already use, with the discipline put back where AI made it cheap to skip. A working point in an ongoing conversation, not an end-state.
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. It runs on plain markdown, JSON manifests, and git, and a team can adopt it without anybody’s permission. At real scale the chain wants tooling. Anything from a small CRUD CLI a team writes themselves to query the artefacts, up to a full generative-agent toolchain that drafts artefacts against organisational standards and runs the approval workflow. Stravica builds toward the heavier end of that range, because that’s where most of the productivity sits at scale. None of it is a prerequisite. The pages below describe the methodology end to end. Read in order if it’s new to you. Jump in if it isn’t.
RCF’s current scope is the build-side of the lifecycle, downstream of the PRD and TAD being agreed. The scoping page covers what that means, what’s deliberately out of frame today, and what’s coming next.
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.