Stravica

← RCF

Concept

What RCF covers, and what it doesn’tCopy link

The methodology, as published today, scopes the build-side of the lifecycle: everything downstream of an agreed PRD and TAD. The upstream is coming. This page is the honest map.

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 → (loop back into shaping for the next slice).

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

One thing to flag explicitly: the operate-side of the lifecycle is also out of frame in the current pages. CI, pipeline, gates, deploy, and the operate-and-learn feedback the Engineering PA layer eventually owns are not covered here. The published methodology covers the build-side from agreed PRD/TAD through to ship. Both ends of the wider lifecycle, upstream discovery and downstream operations, are deliberately not in scope today.

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, Ship, Operate, with a dashed loop-back arrow from Operate back to Shaping. The cards are rendered in three distinct treatments. Cards 1, 2 and 8 (Discovery, Shaping, Operate) are muted and outlined in light grey, labelled OUTSIDE RCF: outside the methodology's current scope. Card 3 (PRD and TAD agreement) is paper-filled with a burnt-orange dashed bracket, labelled FUTURE RCF SCOPE: the upstream multi-role agreement work that the next workstream covers. Cards 4 through 7 (Build sequence, FBS, Build cycle, Ship) are solid burnt-orange, labelled RCF SCOPE TODAY: what the published methodology covers. The loop-back arc, drawn dashed and muted below the band, returns from Operate to Shaping to mark the feedback loop when operating surfaces new work. Outside RCF. Discovery and shaping happen before the methodology engages. Build something, decide what is worth pursuing, settle on the shape of the work. RCF has limited grip here today. OUTSIDE RCF Future RCF scope. The multi-role, multi-stakeholder agreement that turns a vague idea into a structured PRD and a shaped TAD. On the roadmap as the next workstream. Not on the site today. FUTURE RCF SCOPE RCF scope today. The build side, from agreed PRD and TAD through to a shipped feature, with traceability from a business decision down to the lines of code that satisfy it. RCF SCOPE TODAY Outside RCF. Operating and learning from the shipped product. RCF feeds the work that becomes the next slice, but does not itself describe how to run an in-production service. 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 turns a shape into a written PRD and a TAD that everyone signs off on. 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 Ship. CI/CD green, merge, deploy. The slice lands in production and the chain advances. Ship merge, deploy Operate. Learn from real use. Surfaced learnings feed back into shaping for the next slice. Outside RCF: the methodology does not describe how to run a live service. Operate learn from use Loop-back. When operating in production surfaces new work, the lifecycle restarts at shaping. Dashed and muted because it is feedback into a future cycle, not part of the linear forward flow. loop back to shaping 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, Ship, Operate. A loop-back stub at the bottom marks the return to shaping when operating surfaces new work. Cards 1, 2 and 8 are muted as outside RCF. Card 3 is outlined in burnt orange as the future RCF scope. Cards 4 through 7 are solid burnt orange, the current RCF scope. Outside RCF. Discovery and shaping. Outside the methodology's current scope. OUTSIDE RCF Future RCF scope. The upstream PRD and TAD agreement work, coming next. FUTURE RCF scope today. The build side: agreed PRD and TAD through to shipped feature. RCF SCOPE TODAY Outside RCF. Operating 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. Future RCF scope. PRD / TAD what to build Build sequence. Order the FBS slices. In scope. Build sequence order the slices FBS. Functional build spec. In scope. FBS spec a slice Build cycle. Define, build, review, test, finalise. In scope. Build cycle build the slice Ship. CI green, merge, deploy. In scope. Ship merge, deploy Operate. Learn from real use. Outside RCF. Operate learn from use Loop-back. When operating surfaces new work, the lifecycle restarts at shaping. loop back to shaping
Discovery → Shaping → PRD/TAD → Build sequence → FBS → Build cycle → Ship → Operate

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.

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.