What RCF covers, and what it doesn’tCopy link

Every methodology pages I’ve read either oversells the bit the author cares about, or quietly assumes the bits they don’t. RCF is no different in that risk, so this page exists to make the scope explicit before a reader gets to the substantive pages and starts pattern-matching against what their project actually looks like.

The bit that is in scopeCopy link

RCF, as it currently stands, covers the build-side of the software lifecycle. Concretely, that means everything from “the PRD and TAD are agreed and signed off” through to “the feature is built, tested, and shipped, with traceability from a business decision to the line of code that satisfies it.”

Inside that frame, the methodology is reasonably complete. The document chain defines the artefacts. The build cycle defines the operating loop. The AC-as-contract mechanism defines how intent becomes machine-checkable. The traceability rules define how the chain stays interrogable as the project evolves. These pieces hang together and have been used in anger.

The bit that is deliberately out of frameCopy link

Everything upstream of an agreed PRD and TAD. The discovery work that identifies a product worth building, the multi-stakeholder negotiation that turns a vague idea into a structured PRD, the architectural shaping that turns a PRD into a TAD. The role-mix that does that work properly: product management, design, technical architecture, compliance, infrastructure, security, devops, sometimes legal, sometimes finance. None of that is in the current pages.

The omission is purposeful, not accidental. The upstream work is genuinely multi-role and multi-stakeholder. An RCF project still has one owner, but many roles feed into the PRD and TAD state, and the agreement among them is its own discipline. That discipline gets a separate treatment, with its own pages, its own tooling, and its own mechanism for the human signature at the approval gates. It’s on the roadmap. It isn’t on this site yet.

What that excludes (read this if you think RCF isn’t for you)Copy link

A reader landing on a methodology page that assumes a PRD already exists will reasonably ask whether the methodology has anything to say about their kind of work. Honest answers, in order:

Platform and infrastructure work. Often there’s no classical PRD because there’s no end-user surface. RCF still applies once you decide what the platform is for and what it must do: that becomes the PRD, and the rest of the chain runs the same. The shape of the requirements changes (more non-functional, fewer user stories that look human-shaped); the mechanism doesn’t. The upstream work of writing that PRD is what’s missing.

Research and exploration. Genuinely exploratory work where the question is “is this idea worth pursuing” sits upstream of RCF entirely. Build something, learn, throw it away. The methodology kicks in if and when the exploration produces something worth productising. Don’t wrap a spike in nine artefacts. That’s the methodology being misused.

Bug fixes and security patches. A single-AC slice through the existing chain, run through the normal build cycle, against the AC the bug exposed. RCF covers this; the surface is smaller because the upstream work was done when the original feature shipped. If the bug exposes a missing AC, write the AC, then fix the code against it. The chain accumulates as you touch it.

Open source and consulting work. Same answer as platform work. Once there’s a thing the work is for, RCF runs. The upstream who-agrees-what is different (maintainers and contributors, or client and stakeholders, instead of internal product management), but the build-side mechanism is the same.

In short: the build-side mechanism is the same shape regardless of project type. The upstream work is where the variation lives. RCF currently sits where the variation has settled out into a PRD and TAD that the team agrees to build against. If you’re upstream of that point, the methodology has limited grip on your work today. That’s the gap the next workstream closes.

Why ship the build-side firstCopy link

Two reasons, both honest.

First, the build-side is where AI agents are doing the work right now and where the trust problem is most acute. The discipline that makes AI agent output trustworthy is the discipline of the document chain, the build cycle, and the AC-as-contract rule. If we’d started upstream, the build-side would still be a wild west and the project would have stayed agent-unsafe.

Second, the upstream work is harder, not easier. Multi-role agreement on a PRD and TAD touches organisational shape, role authority, sign-off politics, and the social mechanism by which the human signature on the PRD actually means something. That deserves a proper treatment, not a tacked-on chapter. It’s the next substantial piece, not a footnote.

The wider lifecycle, for contextCopy link

A rough sketch of where RCF currently sits in the wider lifecycle:

Discovery and shaping → multi-role PRD and TAD agreement → (RCF picks up here) build sequence → FBS → build cycle → ship → operate and learn → (loop back into shaping when the operate-and-learn stage surfaces new work).

The bold step is the bit that’s coming. Everything from the italic onwards is what the published methodology covers today.

What this means for the trust mechanismCopy link

A fair worry, looking at the published methodology, is that if AI drafts the acceptance criteria (which the AC-as-contract page concedes is a sweet spot for AI assistance), the contract risks becoming a contract between two AIs with a human signature attached. The signature is theatre, the argument runs, unless something structural anchors it.

The answer is real, and it lives at the approval gates. The same gates that live in the upstream work also live at every layer of the chain: PRD approval, TAD approval, AC review, FBS sign-off, test review. The mechanism that stops the signature being theatre is the same mechanism at every layer, and it gets its own page: theatre risk and the human signature. Read that one alongside this one. The two pages together answer the “where does trust live” question.

What to read nextCopy link

If you’re landing here because you’re unsure RCF fits your work, the next two pages worth reading are the document chain (what the build-side mechanism actually is) and theatre risk and the human signature (how the chain stays anchored to a real human commitment rather than drifting into self-report). After those, the FAQ covers the questions that come up most often.