The build sequence

The build sequence is RCF’s plan for getting from nothing to shipped: the full set of build specs for a product, the dependencies between them, and the order they will be built in. One per product. It is the last document written before building starts, and the one the build loop reads to choose the next piece of work.

RCF (the Requirements Confidence Framework) keeps a chain of documents from the product requirements down to the tests that prove them. A build spec is the unit of work in that chain: a set of acceptance criteria sized so it can be built, tested and shipped in one go. RCF’s formal name for it is the Functional Build Specification, or FBS.

What is a build sequence?

A directed acyclic graph. Each node is a build spec. Each edge is a dependency: this spec cannot start until that one has finished. Acyclic means no spec can depend on itself, directly or through others. Every build spec names the specs it depends on; the sequence document carries the build order and the strategy used to derive it. It carries no dates: what comes before what, not when.

Why sequence before building

The sequence is written once every requirement has stories, every story has testable criteria, and the criteria have been grouped into build specs. Nothing has been built yet. Writing the order down at that point does three things.

It makes the plan reviewable as a whole. A person can read the queue, see what depends on what, and correct it before an agent starts on the wrong first item.

It takes the choice of next item away from the agent. Given a pile of specs, an agent picks one, usually the nearest to hand. With a sequence, the plan chose, and the plan was approved.

It makes done measurable. The queue is complete when every spec on it is complete or verified.

How the order is chosen

The sequence names its ordering strategy in one field. Four are common.

• Dependency first. What must exist first goes first. The default.
• Vertical slice. One thin path through every layer of the product, working end to end, before anything is widened. Ships visible behaviour earliest.
• Domain grouped. Finish one area of the product before starting the next.
• Risk front-loaded. The uncertain items first, while there is still time to react to what they reveal.

The strategy decides the order among specs that could go either way. Dependencies still win: no strategy may schedule a spec ahead of something it depends on.

What the queue decides

Once building starts, the sequence becomes a queue. Each build spec carries a status: not started, in progress, complete or verified. An item is actionable when it is not started and every dependency is complete or verified. An item with an unsatisfied dependency is blocked.

The next item is always the actionable one with the lowest build order. Tooling makes that selection, not the agent, and a blocked item is never selected on the grounds that its dependency is nearly done. Nearly done is not done.

Items with no dependency path between them can be built in parallel. Everything else runs in queue order. When nothing is actionable and the queue is not complete, something is blocked or has been left in progress. That is a condition to report, not a reason to pick an item anyway.

Declaring dependencies honestly

The queue is only as truthful as its edges. A dependency belongs on a spec when the spec genuinely cannot be built first, and only then. Padded dependencies serialise a queue that could have run in parallel. Missing ones hand the build loop a lie, and the first sign is a worker outside its spec looking for something that was never built.

Size matters for the same reason, and it is not measured in time. Two things bound a build spec: the complexity one worker can hold at once, and the context the spec pulls into the build. A spec stays on one topic. Work that belongs to a different topic goes in its own spec, because unrelated context in one build degrades everything built with it. A spec that fails either test is two specs, with a dependency between them.

How the sequence changes as specs finish

Each build spec runs through the build cycle. Its final stage records completion and updates the sequence: specs that were waiting on the finished one become actionable, and the loop selects the next. Nothing is renumbered. Order and dependencies were set at planning time; the build only changes status.

When the requirements change

A sequence is not only for a product built from nothing. Most of a product’s life is spent changing one that exists: a small feature, an amended requirement, a bug traced back to a criterion. The sequence covers those by recomputing over the difference.

The chain records the state of every document when the sequence was last computed. Any edit after that is detected by comparing the current chain with that record, not declared by whoever made it. From each changed document, the chain’s references identify what depends on it, down to the build specs whose scope has moved.

Those build specs re-execute: back onto the queue, complete or not, and through the build cycle again over their new scope. A spec in progress when its criteria change stops rather than finishing against a scope that no longer holds. New criteria are grouped into a new build spec, given its dependencies and appended. Everything untouched keeps its status and its place.

A small feature shows the shape. An export added to an existing screen produces one new requirement, two new stories and one amended criterion on a story already built. The fan-out reaches the two specs that implemented that story. The recomputed sequence holds one new spec at the end, two re-opened ones and thirty untouched. The queue selects as before, lowest actionable build order first, so the re-opened specs come ahead of the new one.