How one feature moves through the six BVDLC phases — from first signal to measured value, with four sign-off points where human judgment decides the next move.
The fourteen steps below follow the six BVDLC phases. Each step has an owner, a typical agent contribution, and a primary artifact it produces or updates. Four steps are sign-off points — the work cannot move past them without an explicit human decision.
Each orange diamond is a sign-off point: 1 intent approved · 2 idea validated · 3 spec locked · 4 verified for release.
Phase 0 establishes why the feature matters. Phases 1–2 turn the idea into a locked spec. Phases 3–4 turn the spec into shipped software. Phase 5 closes the loop with outcomes and learning — which feeds the next trip through Phase 0.
A customer complaint, competitive move, regulatory change, internal hypothesis, or metric drift. Something is asking for a feature.
Human-led. The PM interviews stakeholders, reads the signal in full, and writes a first-cut statement of what the feature should do for whom — with the KPI it is expected to move.
PM and agent expand the idea. The agent offers alternative framings, prior-art references, and a rough sizing. The PM edits ruthlessly.
The PM signs off: the feature is worth pursuing further. This is the exit gate of Phase 0 — below this line the work moves from discovery to discovery-plus-design.
The BA reads the relevant rules, regulations, and edge cases. The agent pulls referenced sources and drafts edits to the business-context documentation. The BA decides which updates are accepted into the shared context.
If the feature is novel or its value is uncertain, a small prototype is built to test the idea before committing to full design. This is where weak bets get killed cheaply.
The PM reviews the validation signal. If the idea holds, continue. If not, pivot or kill — cheaply, before design and build costs accumulate.
BA, PM, Quality Lead, and an agent co-author requirements.md and acceptance-criteria.md. Criteria are Given/When/Then, machine-parseable.
The Squad Lead and an agent draft design.md and data-contracts.md. Alternatives are considered and recorded. The architect reviews.
PM, BA, Squad Lead, and Quality Lead all sign off. After this, the spec is the contract: agents implement against it, humans verify against it.
An agent turns the locked spec into an epic with child stories in the work-tracking system. Each story references the spec in Git. The Squad Lead reviews the breakdown before anything starts.
The squad runs. Squad Engineers feed agents context and review drafts. The Squad Lead reviews PRs against spec intent, not line-by-line diffs.
The Quality Lead validates acceptance criteria. Agents run the regression suite. A human signs off before merge to the main line.
The feature ships. The success metrics defined in the feature brief are measured. PM, BA, and agent capture the learning — what to keep, what to change, what surprised the team — into the business-context documentation, the architecture documentation, or the audit log as appropriate. That learning is the input to the next trip through Phase 0.
The full fourteen steps describe a brand-new feature. Most of a team’s work is enhancements and fixes — and they enter the same workflow at later steps, because the earlier artifacts already exist. Same workflow, three doors in.
Nothing exists yet. Run the full path: intent, validation, spec, build, measure. All four sign-offs apply.
The feature brief and validated idea already exist — update the brief, then re-run requirements through release. Dip back to step 5 only if the change touches a domain rule. Sign-offs 3 and 4 always apply.
The spec exists; the bug is the signal. Start by writing a failing test that reproduces it, fix, verify, ship. Step 14 is mandatory for fixes — a bug usually means the shared context was missing something, and that gap gets closed.
If a feature skips any of these, it is no longer moving through the BVDLC delivery model. Everything else can flex. These cannot.
The four sign-offs are permanent — they are business judgment, and they never move to an agent. But the smaller human reviews between the sign-offs should shrink as the team earns confidence. Tie each reduction to a measured threshold, not a feeling.
| Human review | Why a human is there at first | When it can relax |
|---|---|---|
| Reviewing the agent’s task breakdown (step 11) | Early on, agents misjudge slice size and dependencies. | When the breakdown needs no edits for several consecutive features, switch from full review to spot-check. |
| Reviewing every agent PR line-by-line (step 12) | Trust in agent output against the pattern library isn’t established yet. | When reviewer-requested changes stay low across a quarter, review against spec intent only and sample the rest. |
| Manually re-running acceptance scenarios (step 13) | The automated verification suite hasn’t proven it catches what humans catch. | When the suite has caught every defect humans also caught over a sustained period, humans review the report instead of re-running the checks. |
| The four sign-offs themselves | What to bet on, what the contract says, and what ships are business decisions. | Never. These are the speed bumps you keep on purpose. |
At sign-off 4, three different kinds of checking happen, and they are not interchangeable. The first two exist in traditional software. The third is new — and teams that skip it find out the hard way.
Three recurring failure patterns. If you see one, treat it as a signal that the delivery model is degrading.