On this page

Related reading

← RCF

Concept

The build cycle

Each functional build specification follows five stages: Define, Build, Review, Test and Finalise. Each stage ends with a commit that can be reviewed independently.

Last updated

The build cycle is the loop RCF runs to ship one slice of work with AI agents: five stages, Define through Finalise, each ending in a commit. It is the build slice of an AI SDLC, the part of the lifecycle where the code actually gets written.

The document chain defines what to build. The build cycle defines how to deliver each slice. Every functional build specification runs through one cycle with five stages and five commits.

The stages are:

  1. Define. Test scaffolding first: every in-scope acceptance criterion gets its suite, derived from the criterion text.
  2. Build. Code required to pass the tests.
  3. Review. Check the diff for coverage, scope and architecture.
  4. Test. Run every suite on the project, not just the slice’s.
  5. Finalise. Record completion, update the chain and release dependent slices.

Finish and commit each stage before starting the next. The cycle prohibits skipping stages or running them in parallel.

The RCF build cycle A left-to-right five-stage iterative loop applied to each functional build specification slice in the Requirements Confidence Framework. Stages in order: Define (test scaffolding), Build (code plus assertions), Review (read the diff for AI drift), Test (full suite pass), Finalise (CI green, ship). A small commit indicator beneath each stage marks the per-stage commit discipline that the methodology relies on. A dashed return arrow loops from Review back to Build to show the optional micro-loop when Review surfaces fixes. The forward path is solid burnt orange; the return loop is dashed. The terminal Finalise stage carries a small check mark to mark the end-state. Optional Build↔Review micro-loop. If review surfaces fixes, work returns to Build (re-commit) and Review runs again. Dashed because it is the exception path; the main flow is the solid forward arrow. if review surfaces fixes Define, Lay down test scaffolding: test files, cases, describe/it blocks for every acceptance criterion in scope. The bodies remain stubs until Build fills them in. OUT: failing test scaffolding committed. Define test scaffolding Build, Write the code that satisfies the acceptance criteria. Fill the test assertions as the code lands. OUT: code plus green tests committed. Build code + green tests Review, Read the diff. Look for AI drift, missed criteria, sloppy code. Make corrections; commit them. OUT: a review commit showing what changed (small or substantial, always visible in history). Review diff corrections Test, Run the full test suite (not just this slice's tests). Verify nothing regressed elsewhere. OUT: full-suite pass committed. Test full suite green Finalise, CI/CD green. Merge, deploy, mark slice done. The chain updates and the build sequence advances. OUT: the slice is shipped. Finalise slice shipped The RCF build cycle (vertical layout) A vertical top-to-bottom five-stage stack of the RCF build cycle: Define, Build, Review, Test, Finalise. Each stage carries a commit indicator. A dashed arc on the left side loops back from Review to Build to mark the optional micro-loop when Review surfaces fixes. Optional Build↔Review micro-loop. If review surfaces fixes, work returns to Build (re-commit) and Review runs again. Dashed because it is the exception path; the main flow is the solid forward arrow. Define, Lay down test scaffolding: test files, cases, describe/it blocks for every acceptance criterion in scope. OUT: failing test scaffolding committed. Define test scaffolding Build, Write the code that satisfies the acceptance criteria. Fill the test assertions as the code lands. OUT: code plus green tests committed. Build code + green tests Review, Read the diff. Look for AI drift, missed criteria, sloppy code. Make corrections; commit them. OUT: a review commit showing what changed. Review diff corrections Test, Run the full test suite (not just this slice's tests). Verify nothing regressed elsewhere. OUT: full-suite pass committed. Test full suite green Finalise, CI/CD green. Merge, deploy, mark slice done. OUT: the slice is shipped. Finalise slice shipped
DEFINE → BUILD → REVIEW → TEST → FINALISE

Stage 1: Define

Lay down the test scaffolding. Every acceptance criterion in scope on the FBS gets its test suite as a file, with the cases sketched as describe and it blocks (or whatever your framework’s equivalent is) that name what each case will check, derived directly from the AC text. The criterion-to-suite-to-cases structure exists in code before any production code does.

Define isn’t where the assertions get written. The actual test code, the arrange/act/assert that makes each case run, lands in the Build stage that follows. Define records the structure: what suite covers which AC, what cases each suite contains, what behaviour each case is going to verify. The bodies of the cases are stubs (failing or pending) until Build fills them in alongside the implementation.

Deriving the test structure from acceptance criteria takes time before implementation. It ensures the suite reflects the required behaviour. Tests invented after implementation can merely describe the code that already exists.

Define ends with a commit. Test files exist. Test runner sees them. Every case in the FBS’s scope is present, even if it’s pending or red. CI may or may not be green at this point depending on how the project handles pending tests, but the structure is in place.

Stage 2: Build

Write the code that makes the tests pass. No more, no less. Build context comes from the FBS’s declared sources: the PRD sections it points at, the TAD components it touches, the modules and schemas it’s allowed to change. A worker doesn’t grep around looking for orientation. If the context didn’t come from the FBS, it isn’t context.

Spec-driven development inside the RCF build cycle A left-to-right five-stage build cycle showing where spec-driven development sits within the Requirements Confidence Framework. The five stages in order are Define, Build, Review, Test, Finalise. Four of the five stages are owned by RCF discipline and carry an RCF tag: Define (write the tests from the acceptance criteria before any code exists), Review (the diff is reviewed against intent), Test (the acceptance-criteria suite runs as the gate), and Finalise (CI green, the slice closes, the chain updates). Only the Build stage is owned by spec-driven development: it is filled in burnt orange and tagged SDD, and an agent generates code against a precise spec target. A dashed bracket arc spans from Define over Build to Test, annotated to show that Define writes the tests before Build and Test runs them after, so the Build stage is bracketed by the test contract. The takeaway is that SDD generates the code, RCF verifies it, and the test, not the spec, is the authority on whether the code is right. Define writes the tests from the acceptance criteria before any code exists; Test runs that same suite afterwards as the gate. Build sits between them, so SDD generates code against the spec but the test, not the spec, decides whether it is right. the test is the authority tests written tests run Define, RCF. Write the tests from the acceptance criteria, before any code exists. OUT: the failing test suite committed. Define tests, from AC Build, SDD lives here. An agent generates the code against a precise target, the spec or functional build specification. This is the one stage SDD owns; the test written in Define still decides whether the output is right. Build code, from spec Review, RCF. The diff is reviewed against intent: AI drift, missed criteria, sloppy code. OUT: a review commit. Review diff vs intent Test, RCF. The acceptance-criteria suite written in Define runs as the gate. This, not the spec, is the authority on whether the code is right. OUT: full-suite pass. Test suite is the gate Finalise, RCF. CI green, the slice closes, the chain updates and the build sequence advances. OUT: the slice is shipped. Finalise slice closes Spec-driven development inside the RCF build cycle (vertical layout) A vertical top-to-bottom five-stage stack: Define, Build, Review, Test, Finalise. Four stages are tagged RCF; only Build is tagged SDD and filled in burnt orange. A dashed bracket on the left links Define to Test, showing Define writes the tests before Build and Test runs them after, so the test, not the spec, is the authority. Define writes the tests before Build; Test runs them afterwards as the gate. SDD generates the code in Build, but the test, not the spec, decides whether it is right. the test is the authority Define, RCF. Write the tests from the acceptance criteria, before any code exists. OUT: the failing test suite committed. Define tests, from AC Build, SDD lives here. An agent generates the code against a precise target, the spec or functional build specification. The test written in Define still decides whether the output is right. Build code, from spec Review, RCF. The diff is reviewed against intent: AI drift, missed criteria, sloppy code. OUT: a review commit. Review diff vs intent Test, RCF. The acceptance-criteria suite written in Define runs as the gate. This, not the spec, is the authority on whether the code is right. OUT: full-suite pass. Test suite is the gate Finalise, RCF. CI green, the slice closes, the chain updates and the build sequence advances. OUT: the slice is shipped. Finalise slice closes
SDD generates. RCF verifies. The test, not the spec, is the authority.

Agents can implement a clear FBS scope against the failing tests from Define. Those two inputs constrain the output. Without them, the agent must infer missing behaviour.

Build is also the one stage where spec-driven development lives. The FBS is the spec the agent generates against, in the SDD sense: a precise build target written above the code rather than inferred from a chat thread. SDD makes the agent reliable on the spec. RCF, around it, makes sure the spec is one the requirements asked for, and keeps the criterion-derived tests written in Define as the actual authority on whether the output is right. The layered comparison sits on the RCF and spec-driven development page; for this cycle the short version is: SDD generates in Build, RCF owns the other four stages, and the test is what decides.

Build ends with a commit. Code exists. The tests in scope pass.

The code landing here is also where its Code Nodes get written, each in-scope AC pointing at the file or symbol that satisfies it while the change is still fresh in hand, which is why Finalise refuses to flip the FBS to complete when an in-scope AC has no Code Node behind it.

Stage 3: Review

Review the diff independently of the implementation pass. Check test coverage, scope and architecture.

Check that each test exercises its criterion. For AC-042-03, the test must verify that cleanup happens within sixty seconds. Adding a sixty-second sleep does not itself verify the cleanup time. A passing test must provide evidence for the AC.

Check changes against the FBS story scope and declared files. An additional file may reveal a missing dependency that must be added to the FBS, or an out-of-scope change that must be removed.

Check the implementation against the TAD. If exports must use the job service, a directly spawned process does not satisfy that architecture decision.

Review ends with a commit, including an empty commit recording a review pass when no changes are required. Otherwise, commit the corrections before continuing.

Stage 4: Test

Run every suite on the project, including existing suites outside the current slice.

A new slice can break existing behaviour. For example, photo-upload changes to the identity service can affect avatar retrieval. Run the avatar tests as well as the new upload tests. If the existing tests miss the regression, record that coverage gap as a separate issue.

Test stage failures aren’t bugs in the slice. They’re evidence that the slice is interacting with the rest of the system in ways the slice didn’t plan for. Fix the interactions, not the tests. If a test was wrong on its own terms, that’s a finding about the AC behind it, not a reason to lower the bar.

Test ends with a commit. Whole project green. Coverage report attached.

Stage 5: Finalise

CI green. Coverage report green for the slice. The FBS status flips to complete, but only once every in-scope AC has a Code Node behind it or a recorded no-code exemption; a missing one blocks the flip until it’s resolved. The work item that opened against the FBS closes. The build sequence updates: dependent FBSs that were gated on this one become eligible to start.

Finalise records completion in the system. Its explicit checks give completed FBSs a consistent meaning throughout the project.

Finalise ends with a commit. The commit message names the FBS. The status change is in the same commit. The status is recorded.

Why each stage commits

Each commit is independently accountable. A senior reviewer should be able to assess whether its stage was completed correctly without reviewing the other four stages.

The Define commit shows the tests, in isolation, before any code. You can reason about whether they cover the criteria.

The Build commit shows the implementation, in isolation, with the tests it satisfies already present. You can reason about whether the implementation is the right shape for the tests.

The Review commit records corrections from reviewing the diff, whether small or substantial.

If Review identifies material fixes, the team can make a new Build commit and review that diff again. This optional Build ↔ Review loop ensures the corrections are also reviewed. It is especially useful for higher-risk work.

The Test commit records any fixes required after running the whole project, including regressions outside the slice.

The Finalise commit records the FBS completion and its durable status change.

Squashing the cycle into one commit removes the ability to assess each stage independently. Reviewers must then judge tests, implementation, corrections and completion together.

What the cycle costs

The cycle takes time. On a small slice, its early stages can take longer than starting implementation immediately.

The continuing benefit is a maintained build sequence, current FBS statuses, suites mapped to criteria and a commit history that new engineers can read. These records keep completion measurable as the project grows.

Creating commits is cheap. Running the stages in order for every slice requires sustained discipline.

The cycle prevents AI drift: the gradual divergence between intent and output when a team skips engineering checks. Each cycle checks the work against its FBS, ACs and suites. This is a team-practice issue, distinct from model drift.

The cycle for changes, not just new work

The cycle runs the same way when the trigger is a change to the spec, not a new slice of greenfield. A requirement gets refined, an AC gets edited, the architecture grows a new constraint: traceability flags the gap between docs and code, the gap is scoped into a functional build specification, and the FBS runs through Define, Build, Review, Test, Finalise. Define generates fresh test suites from the updated AC text, or amends the existing ones. Build closes the diff. The other three stages run as usual.

Bug fixes, edge cases and new modules use the same stages and reviewable commits. Read the living spec for how changes become FBSs.

What is the agentic SDLC?

The agentic SDLC is the software development lifecycle once AI coding agents are part of the team rather than a tool the team uses. The five-stage cycle on this page is the build slice of that lifecycle: everything that happens inside a single PR scope, from defining the slice to closing it. The wider SDLC still wraps it. PR review, merge, release, observation in production, back-filling the next FBS from what you learned. Those stages sit either side of the build cycle, and AI agents take part in them too; they aren’t the subject of this page.

RCF applies the same stages and commits to work carried out by agents, humans or both.

The cycle was designed for human teams. It does double duty for AI-assisted work, and the structure is more important, not less, when an agent is doing the typing. A worker agent can run the whole cycle inside one session, when the brief is sharp enough. Define stage: the agent reads the FBS, generates the test suites from the AC text, commits. Build stage: the agent writes the implementation against the failing tests, commits. Review stage: a second agent (or the same agent in a different role) reads the diff against the FBS and flags scope or correctness issues. Test stage: the runner runs, the agent fixes the bleed, commits. Finalise stage: the agent updates the FBS status, commits.

Each stage limits what an agent may change. Define cannot add files outside FBS scope. Build cannot change tests. Review cannot silently rewrite criteria. These constraints make generated output reviewable against the agreed work. PR review, merge and release remain separate stages in the wider lifecycle.