One Feature Through All Five Phases A worked example of AIDLC, artifact by artifact
The framework pages describe each phase on its own. This page follows a single feature from a forwarded customer email to a production incident and back into the backlog, and shows the actual artifact each phase hands to the next - what the agent drafted, what people decided, and which gate caught which mistake.
About This Example
The team, the product and the feature below are invented for illustration. Nothing on this page reports a real result, a real customer or a measured outcome - it is a demonstration of the method, in the same spirit as the templates it uses. For first-hand practice, see the field notes.
The setting: a product team of eight engineers runs a business invoicing application used by many small companies, each one a separate tenant. They have adopted AIDLC at roughly maturity level 2 - an AI usage policy, a repo instruction file, plan-first review and risk tiers are in place; unattended agents are not.
The Artifact Chain
Every phase ends by handing a written artifact to the next one. That chain is what lets an agent work from context instead of guesses, and what lets a reviewer check the work against something other than memory.
Analyze
Requirements Brief
Problem, users, acceptance criteria, open questions, risks.
Ideate
Design Note, ADR, Contract, Spec
The decision, why it won, the interface, and a spec an agent can execute.
Develop
Ticket Contracts, Plan, PR
Small slices, an approved plan for each, and a risk-tiered review.
Launch
Tests and Release Plan
A mutation-scored suite, a flagged rollout and a rollback path.
Curate
Runbook, Review, Rule
Alerts, a post-incident review, and a new rule in the instruction file.
The Request
The customer success lead forwards three customer emails and a chat thread with one line on top: "People keep asking for this - can we do it?" The gist of the emails is that bookkeepers re-type invoice data into their accounting software every month, and want a file they can import instead.
That is the raw input. It is ambiguous on purpose, because real input always is: one email asks for a live sync, one asks for a spreadsheet, and the chat thread mentions a customer who "needs it weekly".
Phase 1. Analyze
The product manager pastes the emails and the thread into an assistant with the requirements-extraction prompt and asks for a draft brief plus every question the input leaves open.
The agent drafted
A brief that separated three different asks (a file export, a scheduled export, a live sync), acceptance criteria for each, and seven open questions - including two nobody had raised: which invoice states count (drafts? voided?) and whether an export should contain data from every user on the account.
People decided
The product manager cut scope to a scheduled CSV export - no live sync - after two short customer calls. The tech lead added the risk the draft underplayed: an export is a bulk read of financial data, so tenant isolation is the failure that matters most.
Artifact: Requirements Brief (excerpt)
Problem: Bookkeepers re-type invoice data into accounting software every month.
Users: Account owners and bookkeepers (role: billing-admin).
In scope: Scheduled CSV export of finalized and paid invoices, weekly or monthly,
delivered by email as a time-limited download link.
Out of scope: Live sync, XLSX, accounting-tool integrations.
Acceptance criteria:
Given a billing-admin has scheduled a monthly export
When the schedule runs on the 1st
Then they receive a link to a CSV of last month's finalized and paid invoices
And the CSV contains only their own account's invoices
And the link expires after 7 days
Open questions (resolved):
- Draft and voided invoices? Excluded.
- Who can schedule? billing-admin only.
Risks:
- Cross-tenant data exposure in a bulk read (severity: critical)
- Large accounts make the job slow (severity: medium)Exit Gate
Every open question answered or explicitly deferred, the risk list reviewed by the tech lead, and the product manager's sign-off on scope. Full phase guide: Analyze.
Phase 2. Ideate
The tech lead asks an agent, with read access to the repository, for two competing designs instead of one - the competing-designs prompt - and has a designer prototype the settings screen in parallel.
The agent drafted
Design A generates the CSV on request while the user waits; Design B runs a scheduled background job that writes the file to private storage and emails a signed, expiring link. It also drafted a throwaway prototype of the schedule screen from the existing design-system components.
People decided
Design B, because large accounts would time out under A. The designer ran the prototype past two customers and a keyboard-and-screen-reader pass, which caught a schedule picker that could not be operated without a mouse. The prototype was then thrown away, as planned.
Artifact: ADR-031 (excerpt)
Title: Scheduled invoice export runs as a background job
Status: Accepted
Context: Large accounts hold many years of invoices;
a request-time export would exceed request timeouts.
Decision: A scheduled job per account writes the CSV to
private storage and emails a signed link (7-day expiry).
The job reads invoices ONLY through the tenant-scoped
repository, never with a raw query.
Consequences: Exports are not instant. Storage needs a
lifecycle rule. The job needs its own alerting.
Alternatives: Request-time generation (rejected: timeouts).Artifact: API contract (excerpt)
PUT /accounts/{accountId}/export-schedule
auth: billing-admin of {accountId}
body:
frequency: weekly | monthly
recipients: [email] # must be account members
200: { nextRunAt, frequency, recipients }
403: caller is not billing-admin of {accountId}
DELETE /accounts/{accountId}/export-schedule
204: schedule removed; no further exports runThe last Ideate artifact is the spec: the brief, the ADR and the contract condensed into the format the team's agents execute - intent, acceptance criteria, constraints, the files likely to change, and what is out of scope. Context and spec-driven development covers the format.
Exit Gate
The ADR accepted by the tech lead and one other senior engineer, the contract reviewed against the brief, and the prototype's findings folded into the spec. Full phase guide: Ideate.
Phase 3. Develop
The spec becomes three small slices, each with its own ticket contract: the schedule table and API, the export job, and the settings screen. Each slice gets its own risk tier - the job reads financial data across a whole account, so it is Tier 3.
Artifact: Ticket contract, slice 2 (excerpt)
Title: Scheduled export job writes tenant CSV and emails link
Risk tier: 3
Lane: A (human-driven, agent-assisted)
Data classification touched: Confidential (customer financial data)
Feature flag: scheduled-invoice-export
Acceptance criteria (Gherkin):
Given account A and account B both have invoices
When the export job runs for account A
Then the CSV contains only account A's finalized and paid invoices
Data contract:
Inputs: invoices via TenantScopedInvoiceRepository
External systems: private object storage, transactional email
Required audit log writes: export.generated (accountId, rowCount, requestedBy)
Rollback plan: disable flag; job no-ops; existing links expire in 7 days
Blast radius: every account with a schedule
Out of scope: XLSX, retries beyond 3 attemptsThe agent drafted
A plan before any code, as the team's plan-first rule requires. Step 3 of the plan read invoices with a direct query filtered by date - fast, simple, and missing the tenant filter that the repository applies.
People decided
The engineer rejected step 3 at plan review, pointing at the ADR line the plan contradicted. The revised plan used the tenant-scoped repository. The cheapest gate in the whole process caught the most expensive bug, before a single line was written.
Artifact: PR description (template fields)
AI assistance: agent-authored (identity: team coding agent, model: pinned in repo config)
Plan approved by: link to plan review, revision 2
What a human verified, and how: read every line touching the repository call;
ran the cross-tenant test locally against seeded accounts A and B
Tests: both. Mutation score on touched critical modules: reported by CI
New dependencies: none
Risk tier: 3 (two reviewers plus architect)
Rollback: disable scheduled-invoice-exportExit Gate
Each slice merged only after the reviewers its tier requires approved it, with the reviewer checklist applied. Full phase guide: Develop.
Phase 4. Launch
Tests were written alongside each slice; Launch is where the team decides whether to trust them, and how the feature reaches customers without betting every account on it at once.
The agent drafted
Unit and integration tests, including the negative test the brief demanded: seed two accounts, run the job for one, assert the other's invoices never appear. Mutation testing on the CSV formatter then left a mutant alive - flipping the rounding mode on totals changed no test result - so the agent added a test for half-cent amounts.
People decided
The migration only adds a table (the expand half of expand/contract), so nothing existing can break. The release goes out behind the flag: the team's own internal account first, then a small slice of customer accounts, then everyone - with the job's error rate as the stop signal.
Artifact: Release plan (excerpt)
Flag: scheduled-invoice-export (default off)
Stage 1: internal account only, one full monthly run observed
Stage 2: small slice of customer accounts, one weekly cycle
Stage 3: all accounts
Stop and roll back if: job failure rate rises above normal background,
any export.generated audit event has a rowCount from another account,
or support receives a data-exposure report
Rollback: flag off (job no-ops); revoke outstanding links
Release validation: download one export per stage and compare it
with the in-app invoice list for that accountExit Gate
Stage 3 reached with the stop conditions quiet, and the release validation signed. Full phase guide: Launch.
Phase 5. Curate
The feature ships, and the work is not over. Two weeks in, a bookkeeper reports that opening an export in a spreadsheet program showed a security warning about formulas.
The agent drafted
The incident timeline from the support ticket and the job logs, and a root-cause hypothesis: a customer name beginning with an equals sign was written to the CSV unescaped, so the spreadsheet treated the cell as a formula. This is the attack OWASP documents as CSV injection, or formula injection.
People decided
The on-call engineer confirmed the hypothesis, shipped a fix that neutralizes leading formula characters, and asked the real question in the review: why did no phase catch it? Because the brief, the ADR and the spec never mentioned it - so no agent, test or reviewer was looking for it.
Artifact: New rule in the repo instruction file
## Exports and spreadsheets
- Every CSV or spreadsheet export neutralizes cells that begin with
=, +, -, @, tab or carriage return (OWASP: CSV Injection).
- Every export ships with a test that writes a hostile cell and asserts
it is neutralized.
- Source: post-incident review INC-112.That rule is the learn loop doing its job: one incident becomes a permanent instruction that every future agent session reads, and a test that every future export inherits. The incident review followed the incident checklist, and the same customer calls that surfaced the bug produced two new backlog items - XLSX output and a direct accounting-tool integration - which enter Analyze as the next request. The cycle closes.
Exit Gate
Curate has no final exit. Its outputs are the runbook entry for the export job, the alert on its failure rate, the rule above, and the next requests for Analyze. Full phase guide: Curate.
Artifacts at a Glance
| Phase | Artifact | Drafted by | Approved by | Template |
|---|---|---|---|---|
| Analyze | Requirements brief | Assistant, from raw input | Product manager, tech lead | Analyze prompts |
| Ideate | ADR, API contract, spec, prototype | Agent and designer | Tech lead plus one senior engineer | Ideate prompts |
| Develop | Ticket contracts, plan, PRs | Coding agent | Reviewers per risk tier | Ticket contract, PR fields |
| Launch | Tests, release plan | Coding agent | Engineer on the release | Reviewer checklist |
| Curate | Incident review, new rule | Agent, from logs and tickets | On-call engineer, tech lead | Incident checklist, instruction file |
What the Example Shows
AI drafted everything
Every artifact on this page started as an agent draft. None of them was the final word.
People made every decision
Scope, design, plan approval, merge, rollout and the incident fix all had a named human owner.
The cheapest gate caught the worst bug
The cross-tenant read died at plan review, because the ADR had written the constraint down.
Gaps in context become gaps in code
The formula-injection bug existed because no artifact mentioned it. Agents build what the context describes.
Incidents become rules
Curate turned one bug into an instruction and a test that apply to every export from now on.
The loop closes
The same customer conversations that found the bug produced the next two requests for Analyze.
Frequently Asked Questions
No. The team, product, feature and incident are invented to show how the five phases connect, and the page reports no real results. The artifacts follow the formats on the Templates page, so a team can compare its own work against them.
No. The depth scales with risk. A Tier 1 copy change needs a ticket and a reviewed diff; a feature that reads financial data across a tenant earns the full chain. The phases still happen in order - a small change just moves through them in minutes rather than days.
Plan review is the cheapest place to stop a mistake, because nothing has been written yet and the reviewer can compare the plan against the brief and the ADR. In this example it caught a cross-tenant data read before any code existed.
Run Your Own Feature Through It
Pick one small feature, start with the Analyze prompts, and keep every artifact. The second feature goes faster than the first.