Intent-complete

Intent-complete is a verdict on a requirements tree. It says the product owner has said enough for an engineer to start: the brief is complete, every noun in it has been resolved to something the tree knows about, every requirement has at least one story, and every open decision is written down with a default. It is the first of two readiness points on the way from a brief to a frozen tree, and it is the point at which the work changes hands.

RCF (the Requirements Confidence Framework) keeps a chain of documents from the product requirements down to the tests that prove them. The chain serves three purposes equally: better requirements, builds that run from those requirements without a person steering, and verification an auditor can follow. Intent-complete belongs to all three. It is the point at which the first has been served well enough for the second to begin.

Two readiness points, two owners

Between a brief and a tree the build loop can run from, there are two points worth naming. The first is intent-complete: the product owner has said enough. The second is ready-to-build: every acceptance criterion is covered, every decision is closed, and the tree is frozen at a known state. Everything that stops the tree reaching either point is a question, and every question has exactly one owner, the product owner or the engineer.

That ownership is what makes a readiness check useful rather than merely true. “Not ready” is accurate and unhelpful. “Not ready; two questions for the product owner, nine for the engineer” tells each person whether the next move is theirs. The product owner’s questions are about what the product must do. The engineer’s are about how it will be built, and most of them are architectural: record shapes, interfaces, the deployment target, the security architecture. On this page “engineer” means the whole technical side, architecture included; where a team has an architect, the architect is first on that stretch. A check never asks the product owner to settle a record shape or a deployment target, and it never asks the engineer to decide what the product is for.

What intent-complete requires

Four conditions, all of them about intent.

• The brief is complete. Every statement in it is numbered and classified: a capability, a constraint, an actor, a boundary. No question raised in the brief is left unanswered, unless it has been turned into a listed decision.
• The nouns are resolved. Each statement resolves to a requirement, an entity, an actor, a system, a surface, or a deliberate omission. Nothing in the brief is left pointing at nothing.
• Every requirement has a story. At least the happy path: what someone does with this requirement, and what they get.
• Open decisions are listed, each with a default. A decision can stay open at intent-complete. What it cannot be is unwritten. Each one carries the question, at least two options, and the option that stands if nobody chooses.

None of these asks the product owner to know how the thing will be built. The conditions that need engineering judgement sit on the far side of the line.

What ready-to-build adds

The second readiness point is the engineer’s. Every story carries testable criteria, including the failure cases and the things the product must never do. Every record shape and every route is settled. The architecture documents cover security and operations. Every decision that was open is now closed. The tree validates, and it is frozen: a recorded state that the build sequence is computed from and the build cycle runs against.

By volume, this stretch is the larger of the two, and by some distance. A human team works from a brief and fills the gaps in conversation as it goes. An agentic build has no conversation to fall back on; everything it is not told, it guesses, and a guess inside a build is drift. The specificity a build needs is far beyond what a product owner would write down, or should be asked to. Intent-complete marks where that elaboration starts, and who carries it.

Drafts travel across the line

Working with the product owner towards intent-complete, the agent learns a good deal the engineer will need: the entities the product handles, the routes a user takes, the rough shape of the records involved. RCF lets the agent write those down as drafts, marked as drafts, so the engineer starts from a filled page rather than a blank one. A draft never counts against the product owner. It is entry material for the engineer, who settles it, replaces it or discards it, and the readiness check on the engineer’s side lists every draft still unsettled.

Bigger teams

Team size moves neither point. Intent-complete stays the product owner’s, and ready-to-build stays the state the build runs from. What grows is the number of people between the two. In a larger organisation the second stretch’s questions fan out from one engineer to several architects, each with a domain, and to security, compliance, infrastructure and data.

Each question still has exactly one owner, and the check names who is holding it rather than reporting it as with engineering. Data residency sits with compliance, the deployment target with infrastructure, the boundary between two services with the architect who owns it. The check’s job is then routing: each open question in front of the one person who can close it.

A verdict, not a ceremony

Intent-complete is computed, never recorded. There is no sign-off document and no stored flag to go stale. The check reads the tree as it stands and reports which questions remain and whose they are; run it again after an edit and the answer may change. The artefact a delivery team attaches to its ticket is the verdict at a known state of the tree, which anyone can reproduce from the chain. The only thing RCF freezes is the second point, ready-to-build, because that is the state a build runs from.