On this page

Related reading

← RCF

Concept

What RCF covers, and what it doesn’t

RCF covers the build phase: from an agreed product requirements document (PRD) and technical architecture document (TAD) to a shipped feature with traceability. Upstream agreement and downstream deployment gates are on the roadmap.

Last updated

This page defines the current scope so teams can assess where RCF applies to their projects.

The wider lifecycle, at a glance

RCF covers the highlighted stages of the software lifecycle:

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 scope

RCF starts with an agreed and approved PRD and TAD. It covers building, testing and shipping a feature with traceability from a business decision to the code that satisfies it.

The code that satisfies a criterion is a node in the chain. It records the implementing file or symbol and links to the acceptance criteria. Validation checks that the reference still resolves against the working tree.

The document chain defines the artefacts. The build cycle defines the stages of work. The AC-as-contract rule makes intent machine-checkable. The traceability rules keep these relationships queryable as the project changes. Together, these parts provide a substantially complete build method that has been used on real projects.

What is deliberately out of scope

Work before PRD and TAD agreement and work after shipping are deliberately outside the current scope.

Upstream: discovery and PRD/TAD agreement

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.

Upstream agreement involves several roles and stakeholders. An RCF project has one owner, but many roles contribute to its PRD and TAD. The roadmap includes separate pages and tooling for this agreement process, including the human signature at approval gates.

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

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.

Teams can use the CI, deployment and operations stack that suits their project. RCF connects to it at Finalise today. The planned deployment gates will extend that connection.

What that excludes for certain project types

RCF applies differently depending on whether the project already has an agreed PRD and TAD.

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. Work that tests whether an idea is worth pursuing sits upstream of RCF. Build a prototype, learn from it and discard it if appropriate. RCF applies when the result is ready to become a product. An exploratory spike does not need the full document chain.

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. RCF applies once the purpose of the work is agreed. Maintainers and contributors, or clients and stakeholders, make the upstream decisions. The build process stays the same.

The build process stays the same across project types. Upstream work varies until the team agrees the PRD and TAD. RCF has limited coverage before that agreement; the next workstream extends it.

Why ship the build-side first

RCF starts with the build phase for two reasons.

First, AI agents already carry out build work, where verifying their output is an immediate concern. The document chain, build cycle and AC-as-contract rule address that concern. Starting elsewhere would have left this work without those safeguards.

Second, upstream agreement and downstream deployment gates require broader work. PRD and TAD agreement involves organisational roles, authority and accountable approval. Deployment gates affect CI/CD and the audit trail from tested code to a deployed feature. Both need substantial treatment.

What this means for the trust mechanism

AI can draft acceptance criteria. If another AI writes the code and tests, human approval needs explicit standards to avoid approving an unverified chain of AI outputs.

Approval gates apply throughout the chain: PRD approval, TAD approval, AC review, FBS sign-off and test review. Theatre risk and the human signature explains how these gates tie approval to standards and recorded gaps.