← RCF

Concept

What RCF covers, and what it doesn’tCopy link

The methodology, as published today, scopes the build-side of the lifecycle: everything between an agreed PRD and TAD, and a feature shipped with traceability intact. Upstream of that, and downstream of that, are both deliberately out of frame. This page is the honest map.

Every methodology page 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 wider lifecycle, at a glanceCopy link

A rough sketch of where RCF sits:

Discovery → Shaping → PRD/TAD agreement → Build sequence → FBS → Build cycle → Deploy gates → Operate and Learn → loop back into shaping.

The bold span is where the methodology currently focuses. PRD/TAD agreement (upstream) and deploy gates (downstream) are on the RCF roadmap; the chain extends in both directions as those workstreams ship. Discovery, shaping, and operate-and-learn sit outside the methodology entirely. Operate-and-learn lives with the digital operator, a separate Stravica concept that runs alongside RCF rather than inside it.

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, Deploy gates, Operate and Learn. A dashed loop-back arrow runs from the digital operator at the right back to Shaping on the left. The cards sit under five treatment bands. Cards 1 and 2 (Discovery, Shaping) are muted and outlined in light grey, labelled OUTSIDE RCF: pre-methodology exploration. Card 3 (PRD and TAD agreement) is paper-filled with a burnt-orange dashed bracket, labelled UPSTREAM: the multi-role agreement work that the next RCF workstream covers. Cards 4 through 6 (Build sequence, FBS, Build cycle) are solid burnt-orange, labelled BUILD PHASE, CURRENT FOCUS: what the published methodology covers today. Card 7 (Deploy gates) is paper-filled with a burnt-orange dashed bracket, labelled DOWNSTREAM: PR, merge and deploy gating work the methodology will pick up next. Card 8 (Operate and Learn) is muted and outlined in light grey, labelled OUTSIDE RCF: the digital-operator territory where shipped product is run and learned from. The loop-back arc returns from the digital operator back to Shaping, marking how operating-time learning feeds the next product slice's shaping, a cross-methodology feedback line rather than an RCF-internal one. Outside RCF. Discovery and shaping happen before the methodology engages. Try something, decide whether it is worth pursuing, settle on the shape of the work. RCF has limited grip here today. OUTSIDE RCF Upstream. The multi-role, multi-stakeholder agreement that turns a shaped idea into a written PRD and a TAD everyone signs off on. On the RCF roadmap as the next workstream upstream of the build phase. UPSTREAM Build phase, current focus. The slice-by-slice build side: order the work, spec a slice, build the slice. Traceability runs from an agreed business decision down to the lines of code that satisfy it. BUILD PHASE · CURRENT FOCUS Downstream. PR, merge and deploy gating between a finished build cycle and a live service. On the RCF roadmap as a separate workstream downstream of the build phase. DOWNSTREAM Outside RCF. The digital-operator territory: running a live service, learning from real use, deciding what becomes the next slice. RCF feeds this loop but does not itself describe how to operate in production. 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 produces an agreed PRD and an agreed TAD. Upstream of the build phase. 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 Deploy gates. PR review, merge, deploy. The gating between a finished build cycle and a live service. Downstream of the build phase. Coming next as a separate RCF workstream. Deploy gates PR, merge, deploy Operate and Learn. The digital operator runs the live service, watches real use, decides what becomes the next slice. Outside RCF: the methodology feeds this loop but does not describe how to run in production. Operate / Learn digital operator Loop-back. The digital operator's learning from real use feeds back into the next product slice's shaping. Dashed and muted because it is cross-methodology feedback (operator's territory into the pre-RCF shape), not part of RCF's linear forward flow. feedback into next slice 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, Deploy gates, Operate and Learn. The cards sit under five treatment bands shown as a bracket column on the left. Cards 1 and 2 are muted as outside RCF, the pre-methodology exploration phase. Card 3 is outlined in burnt orange as upstream RCF scope on the roadmap, the PRD and TAD agreement work. Cards 4 through 6 are solid burnt orange, the build phase currently in scope. Card 7 is outlined in burnt orange as downstream RCF scope on the roadmap, the deploy-gates work. Card 8 is muted as outside RCF, the digital-operator territory. A loop-back stub at the bottom marks the return to shaping when operating-time learning feeds the next slice. Outside RCF. Discovery and shaping. Pre-methodology exploration, outside the current scope. OUTSIDE Upstream. The PRD and TAD agreement work upstream of the build phase. On the RCF roadmap. UPSTREAM Build phase, current focus. The slice-by-slice build side: agreed PRD and TAD through to a built slice. BUILD PHASE Downstream. PR, merge and deploy gating work downstream of the build phase. On the RCF roadmap. DOWNSTREAM Outside RCF. The digital-operator territory: running the live service 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. Upstream RCF scope, on the roadmap. PRD / TAD what to build Build sequence. Order the FBS slices. In the build phase. Build sequence order the slices FBS. Functional build spec. In the build phase. FBS spec a slice Build cycle. Define, build, review, test, finalise. In the build phase. Build cycle build the slice Deploy gates. PR review, merge, deploy. Downstream RCF scope, on the roadmap. Deploy gates PR, merge, deploy Operate and Learn. The digital operator runs the live service and learns from real use. Outside RCF. Operate / Learn digital operator Loop-back. Operating-time learning feeds the next product slice's shaping. Cross-methodology feedback, not part of RCF's linear forward flow. feedback into next slice
Discovery → Shaping → PRD/TAD → Build sequence → FBS → Build cycle → Deploy gates → Operate / Learn

What 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.

What is deliberately out of scopeCopy link

Two whole bands of work: upstream of the PRD and TAD being agreed, and downstream of ship. Both omissions are purposeful, not accidental.

Upstream: discovery and PRD/TAD agreementCopy link

Everything that happens before the PRD and TAD are agreed. 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 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.

Downstream: PR, merge, deploy gates (and operate-and-learn beyond)Copy link

Two distinct things live downstream of the build cycle. First, the gates that turn a tests-green slice into a feature actually running in production: PR review, merge protocol, CI pipelines, deployment mechanics, the deploy-gate audit trail. Second, operate-and-learn: monitoring, alerting, on-call, incident response, and the feedback loop that turns telemetry from a shipped feature back into the next slice’s requirements.

The deploy-gates piece is on the RCF roadmap. The chain extends naturally past the build cycle’s Finalise stage; making PR / merge / deploy gates first-class participants in the trace is the next workstream below the build cycle. RCF assumes a green CI run before Finalise commits today, but it doesn’t yet prescribe how the gates beyond that work.

Operate-and-learn is not on the RCF roadmap. That work lives with the digital operator, a separate Stravica concept that sits alongside the methodology rather than inside it. RCF describes how to build software; the digital operator describes how the role that runs and learns from it gets done. The two compose at the loop-back from operate back into shaping. They are not the same project.

For a reader landing here from a DevOps or platform-engineering background, the practical answer is: pick whatever CI, deploy, and ops stack suits your context. RCF will plug into it cleanly at the Finalise gate today, and into the deploy-gates layer once that workstream ships.

What that excludes for certain project typesCopy 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 or downstream, the build-side would still be a wild west and the project would have stayed agent-unsafe.

Second, the upstream and downstream bands are both 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. The deploy-gates piece touches the entire CI/CD blast radius and the audit trail that turns a tested slice into a deployed feature without losing the chain. Both deserve a proper treatment, not a tacked-on chapter. They’re the next substantial pieces, not footnotes.

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.