How the Five Phases Connect
The phase pages describe each phase on its own. This page describes the seams between them: which artifact crosses each handoff, who writes it and who approves it, and what happens when a later phase finds something an earlier one missed. Most confusion about AIDLC lives at these seams, and so does most of the rework.
Not a Waterfall: Phases Run Per Ticket
The five phases describe the state of a piece of work, not a stage of the calendar. At any moment a team has work in every phase at once: one feature is still being analyzed, three tickets from another are in Develop, a release is in Launch, and last month's work is in Curate.
The grain differs by phase. Analyze and Ideate usually work per feature, because a requirements brief and a design cover more than one ticket. Develop works per ticket, in thin slices. Launch works per release, which may bundle several tickets. Curate never stops: it watches everything that has shipped and feeds new work back to Analyze.
What makes it a life cycle rather than a pipeline is that work can move backward on purpose. The rule is not "never go back". It is "go back with an artifact, to the phase that owns the decision, and count it".
The Artifact Chain, End to End
Every handoff is a document, not a conversation. Each artifact below fixes one decision, so the next phase can start without re-asking it. The worked example shows every one of them for a single invented feature.
| Artifact | Phase | Drafted by | Approved by | Read by | Decision it fixes |
|---|---|---|---|---|---|
| Requirements brief | Analyze | Agent, with the product owner | Product owner | Ideate | What problem, for whom, and the Given/When/Then criteria that define done |
| Design note and ADR | Ideate | Agent, with the tech lead | Tech lead | Develop, future teams | Which design won, and why the others lost |
| API and data contract | Ideate | Agent | Tech lead | Develop | The module boundaries, which become contract and integration tests |
| Spec | Ideate | Agent | Tech lead | Develop | Goal, files, interfaces, out of scope; traces to every acceptance criterion |
| Ticket contract | Develop | Agent or engineer | Ticket owner | Coding agent, reviewers, Launch | One thin slice: criteria, risk tier, flag, external systems, rollback |
| Plan | Develop | Coding agent | Senior engineer | Coding agent, reviewer | Files, order, test surface and blast radius, before any code |
| Tests | Develop | Coding agent | Reviewer | CI, Launch | Unit, integration and contract tests for every criterion, seen to fail first |
| Pull request | Develop | Coding agent | Reviewer at the risk tier | Launch | The change itself, with what a human verified |
| Release plan and assurance results | Launch | Release agent | Release owner | Curate, on-call | What ships, to whom first, the rollback path, and that the integrated build passed |
| Runbook, incident review, new rule | Curate | Monitoring agent | On-call engineer | Analyze, every agent | What went wrong, and the rule, test or eval that stops it recurring |
Who Owns What: A RACI Across the Phases
R is responsible for doing the work, A is accountable for the outcome, C is consulted, I is informed. Read the agent column carefully: an agent can be responsible for drafting nearly everything, and it is never accountable for anything. Accountability needs a name, and a name means a person.
Role titles vary by organization. Map them to yours; keep the rule that every A is a human.
| Activity | Product owner | Tech lead or architect | Ticket owner (engineer) | Reviewer | QA lead | Release owner | AI agent |
|---|---|---|---|---|---|---|---|
| Requirements brief and criteria | A | C | C | I | C | I | R |
| Design, ADR and contracts | C | A | C | I | C | I | R |
| Spec and ticket contracts | C | A | R | I | C | I | R |
| Plan approval | I | C | A | C | I | I | R |
| Tests from the criteria, then code | I | I | A | C | C | I | R |
| Pull request review | I | C | C | A | I | I | R (pre-review) |
| Quality gates and mutation thresholds | I | C | I | I | A | C | - |
| Release assurance and go decision | C | C | I | I | C | A | R |
| Monitoring, triage and incident cause | I | C | C | I | I | A | R (read-only) |
| New rule, test or eval after an incident | I | A | C | C | C | I | R |
For how these roles shift as agents take on more of the drafting, see Teams and Skills. For review depth by risk tier, see risk-tiered review.
When a Later Phase Finds a Problem
Every backward move follows the same three rules. It carries an artifact, never just a chat message. It goes to the phase that owns the decision, not the nearest one. And it is counted, because a rising count is the clearest sign that an earlier phase needs fixing.
| Found in | What was found | Goes back to | The artifact that carries it | Who decides |
|---|---|---|---|---|
| Ideate | A requirement is ambiguous or two contradict | Analyze | An open question added to the brief | Product owner |
| Develop | A criterion cannot be tested as written | Analyze | The criterion, flagged for rewrite | Product owner |
| Develop | The spec or contract cannot be built as written | Ideate | A change request against the spec or an amended ADR | Tech lead, never the agent |
| Launch | A gap test fails on the integrated build | Develop | The failing test | Ticket owner |
| Launch | A gap test passes: the code was right, the suite was thin | Develop's gate | The kept test, and a tightened gate rule | QA lead |
| Launch | A migration or infrastructure step has no safe rollback | Ideate or Develop | The blocked release plan | Release owner |
| Curate | A production incident or a bad pattern in the field | Analyze, plus every agent | An incident review and a rule, test or eval pull request | Tech lead |
The controlled backward move is also an engine feature: see the pipeline can go backwards, under control and the gate configuration on Building AIDLC Into an AI Engine.
Keeping Rework Rare
A backward move is not free. Each phase a problem travels adds another review, another build and another round of agent work, and that agent work is billed. The cheapest fix is the one made in the phase that owns the decision, before anything downstream depends on it.
Make criteria testable at the source
Given/When/Then, one behavior each, with an ID and the boundary it crosses. Develop cannot write the right test for a criterion that names no observable outcome. See writing criteria an agent can test.
Fix the boundaries before the code
The API and data contract from Ideate tells Develop exactly which module boundaries and external systems a ticket touches, so the integration and contract tests are written with the ticket, not discovered at release.
Test first, at the right level
Tests come from the criteria before the code, at whatever level each criterion needs, with the mutation gate on critical modules. Launch then has little left to find. See Testing Strategy.
Count the backward moves
Track how often each phase sends work back, and why. A rising count from Launch to Develop points at Develop's gates; from Develop to Ideate, at the spec. Report it with the delivery metrics on Measuring Impact.
Ready to Hand Off
The short test for each seam. The full entry and exit criteria are on each phase page.
The brief has all six parts, every criterion is Given/When/Then with an ID, and the product owner has signed it. Criteria
The spec traces to every criterion, the contracts name every boundary, and the ADR records the decision. Criteria
Every criterion has a test at the right level, CI and the mutation gate are green, and a reviewer approved at the risk tier. Criteria
The integrated build passed assurance, the rollback was rehearsed, and production validation is recorded. Criteria
The incident review names the cause, and a rule, test or eval pull request exists before the incident closes. Criteria
The artifact is written down, versioned and approved by a named person. If the next phase would have to ask a question, the handoff is not done.
Frequently Asked Questions
No. The five phases describe the state of a piece of work, not a stage of the calendar, so a team has work in every phase at once. Analyze and Ideate usually run per feature, Develop per ticket, Launch per release, and Curate continuously. Work can also move backward on purpose, carried by an artifact to the phase that owns the decision.
Always a named person. An agent can be responsible for drafting almost every artifact - the brief, the spec, the plan, the tests, the code - but it is never accountable. The product owner signs the brief, the tech lead approves the design, the ticket owner approves the plan, a reviewer approves the pull request, and the release owner makes the go decision.
The work goes back with an artifact, to the phase that owns the decision, and the move is counted. An ambiguous requirement returns to Analyze as an open question, an unbuildable spec returns to Ideate as a change request, a failing gap test from Launch returns to Develop as the test itself, and a production incident returns to Analyze with a new rule, test or eval.
Follow One Feature Across Every Seam
See the handoffs with real artifacts, then see where each test in the chain gets written.