Questions worth answering up frontCopy link

No. Waterfall locks scope before building. RCF assumes the chain edits constantly. The shared shape is that requirements come first; the difference is whether they’re allowed to change.

See The living spec for the full argument.

No. Spec-driven development treats the spec as the source of truth; the code is generated from it. RCF treats requirements and acceptance criteria as the contract, with the spec downstream. RCF sits one layer above SDD in the same chain.

See RCF and spec-driven development for the full distinction.

The chain absorbs change by design. A changed requirement re-derives downstream stories and ACs, traceability flags the test gap, and the gap becomes the next functional build specification. No separate workflow for change versus new build.

See The living spec for the full argument.

Not yet. The published methodology scopes the build-side of the lifecycle, downstream of an agreed PRD and TAD. The upstream work, which covers multi-role discovery, structured PRD and TAD extraction, and the human signature at the agreement gate, is the next workstream and gets its own treatment when it lands.

See What RCF covers, and what it doesn’t for what’s in frame today, and theatre risk and the human signature for the mechanism that will sit underneath the upstream tooling.

No. Unit tests sit alongside the methodology as standard engineering hygiene at the team’s normal coverage target. They prove individual functions behave the way the code says they should. They don’t prove an AC is met, and they aren’t meant to.

The one-AC-one-suite rule is about the layer that does traceability work. It isn’t a claim that all testing on the project flows through this layer. Unit tests, smoke tests, exploratory testing, and ad-hoc probes can and should exist alongside the AC-mapped suites; they just don’t need to be in the chain to earn their keep.

See the clarifying section on Acceptance criteria as the contract.

No. RCF works without AI. The methodology was already correct when the typing was expensive; AI just makes the discipline economically obvious. A human-only team running RCF gets the same traceability and the same per-feature cycle with five honest commits per slice.

On a new project, near zero, because you’re writing the documents you should have written anyway. On a legacy codebase, weeks to months depending on how much retrospective traceability you want.

Forward adoption is the honest answer for legacy. New work runs through the cycle; existing code picks up artefacts when somebody is about to change it.

Yes, with caveats. Legacy codebases are exactly where backward traceability is most valuable, because nobody can remember why anything was decided. Even partial adoption pays back: write a PRD for the feature you’re about to change, write the AC for the behaviour you’re about to alter, run the changed slice through the build cycle. The chain you build covers what you touch.

The caveat is that you don’t go back and write ACs for every feature that was already shipped, because reverse-engineering the tests against the code is high-effort work. The exception is regression: for critical features that change often, retroactive ACs and the suites that come with them can be worth the cost, because the regression suite they produce earns its keep on every future change. For everything else, adopt forward and let the chain accumulate.

Any. The methodology is language-agnostic. The document chain is in markdown and JSON. The build cycle is a discipline, not a tool. Test suites get written in whatever your stack’s test framework is. The only requirement is that you can name an AC ID in a test’s title or metadata so traceability has something to hook on.

Acceptance criteria as Given/When/Then sentences come straight out of the BDD lineage. The one-to-one mapping from AC to test suite is the acceptance-testing discipline taken to its logical end. Writing tests before code is TDD. RCF doesn’t invent these ideas; it pins them together so that they actually stick in practice rather than getting promised in a planning meeting and skipped in the rush to ship.

The thing RCF adds that BDD and TDD don’t insist on is the document chain above the AC. BDD says “write behaviours,” and is silent on where those behaviours come from. RCF says behaviours come from acceptance criteria, which come from user stories, which come from requirements, which sit in a PRD that someone signed off. That upward chain is what the BDD-and-TDD lineage left implicit. Implicit things rot. Explicit things survive.

The methodology is open and runs on plain markdown plus JSON plus git. No, you don’t need to buy anything. A team can adopt RCF with no tooling beyond a code editor and a git client.

At real scale the chain wants tooling, because several artefact types with opaque IDs and one-to-one mappings across hundreds of FBSs isn’t a comfortable manual job. The tooling can range from a simple CRUD CLI a team writes themselves to query and validate the chain, through 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 methodology is what’s stable; the tooling is how you make it tractable at scale. Read the methodology pages without assuming any particular tool; pick a tool when the project size starts to make manual chain work uncomfortable.

It scales by product, not by org. Each product has one PRD, one TAD, one build sequence. An organisation with twenty products has twenty chains running in parallel. The chains don’t merge; that would be a catastrophe in any methodology. What they share is vocabulary and tooling, not document content.

Inside a single product, RCF scales by the build sequence. A small product might have ten FBSs. A medium one might have fifty. A large one might have several hundred. The cycle is the same per FBS. The sequencing decisions get harder as the graph grows, which is where good product thinking earns its keep, but that’s a separate problem from the methodology.

Then you don’t have a product owner, you have a stakeholder who attends meetings, and the project is going to ship something nobody signed off. That’s a recoverable situation, but it’s recoverable upstream of the methodology, not inside it. RCF can’t compensate for missing ownership; nothing can. What it can do is make the absence visible, which is sometimes enough to fix it.

On smaller projects, the operator (or the engineer-acting-as-PM) writes the ACs themselves, with sign-off from whoever’s playing the PO role. That works, as long as the writing happens before the building. ACs written after the fact are not ACs. They’re commentary on what got built, which has its own uses, but isn’t the same thing.

Yes. Anyone can adopt the methodology. Anyone can teach it. Anyone can run a project on it without asking permission. The whole point of publishing the pages on this site is that the methodology is open and adoptable without involvement from me. I use it myself, and I’m building tooling that runs it well, but the methodology itself isn’t something I own.