A loop, not a line. Work moves through phases, but every release feeds the next Discovery and any phase can send work back upstream. The shape below is the point: the cycle never ends, and it shifts hands — humans frame intent, AI does the build, humans judge the result.
Each phase shows its AI / human balance
AI does the work
Human guides & owns
Quality check
Team ritual
Click any step for discipline detail →
1b · Flow & feedback. Phases flow forward along a spine, then the spine bends back — Adoption returns to Discovery, and dashed arcs carry constraints and UAT findings upstream. Maintenance is the parallel track feeding off production.
1c · Infinity loop. The left loop shapes the work (human-led), the right loop delivers it (AI-led); they cross at the spec handoff and run forever. The color shift between the two lobes is the whole story.
Agile cadence wraps every cycle— ceremonies & planning run continuously around all three shapes above, human-led and agent-supported

Every step is clickable — see responsibilities for each discipline: PM · Designer · Development · AI

Why this view exists: reviewers found themselves guessing what artifacts pass between phases — for example, assuming what moves from Discovery into design and then into Epics and Stories. This view names every artifact explicitly so nothing is assumed.
Discovery & Spec → Technical Spec
Why/What doc
Problem statement, user goals, success metrics
PB One-pager
ProductBoard summary, PM-owned
Functional spec
Acceptance criteria + edge cases, PM-owned
Design prototype
Interactive, tool-agnostic, Designer-owned
Feasibility notes
Dev's early flags on implementation limits
Technical Spec → Development
Technical spec
Architecture approach, component breakdown, Dev-owned
ADRs
Decision, reasoning, and alternatives considered — required input to engineering
Test cases (TDD)
Written before implementation begins
Epics + Stories
In Jira, with story points, after team review
Development → Release
Pull request
Code + full audit log, named human reviewer
Deployed feature
In production, continuous delivery, no manual steps
UAT findings
Validated against original spec intent
Release notes
Agent-drafted, PM-approved, customer-facing where relevant
Release → Discovery ↻ closes the loop
Adoption signals
Usage telemetry, support patterns, customer feedback
Structured findings
What's working, what's not, what customers are asking for
Next Discovery inputs
Directly feeds the next cycle's Why/What doc
Maintenance — Standalone Loop
Triage report
Severity, prior occurrences, linked context
Fix PR + test coverage
Root cause explanation included
Context layer update
Learnings written back for future agents
Legend
Named artifact — the thing that physically moves between phases
Supporting context — informs the artifact but isn't the deliverable itself
Why this view exists: swim lanes in the workflow view show who is accountable for an artifact — they don't show who collaborates on it. This view separates the two. Discovery is accountable to PM, but it is not product-only: Design, Dev, and AI all participate. The goal is selective, intentional involvement — not pulling every engineer into every product call, which is low value.
Async-first by design. A distributed US/India team has limited overlap hours. Rather than requiring synchronous everyone-in-the-room sessions, handoffs use structured async artifacts — written specs, recorded walkthroughs, and agent-generated summaries — so a cross-time-zone question doesn't cost a full day of back-and-forth waiting. Synchronous time is reserved for decisions that genuinely need real-time discussion, not status updates.
StepProduct ManagerProgram ManagerDesignerDevelopmentTechnical WriterAI
Pre-DiscoveryPrimaryNoneCollaborateAwareNoneCollaborate
DiscoveryPrimaryNoneCollaborateCollaborateCollaborateCollaborate
PrototypeCollaborateNonePrimaryCollaborateNoneCollaborate
Non-Functional RequirementsPrimaryCollaborateCollaborateCollaborateNoneCollaborate
Client/Stakeholder ValidationPrimaryCollaborateCollaborateCollaborateNoneCollaborate
Functional Spec Draft + ConfirmCollaborateNoneCollaborateAwareNonePrimary
Technical Spec Draft + ConfirmAwareNoneAwareCollaborateNonePrimary
Epics/StoriesPrimaryNoneCollaboratePrimaryNonePrimary
BuildCollaborateNoneCollaborateCollaborateNonePrimary
UATPrimaryCollaborateCollaborateCollaborateCollaborateCollaborate
Company ReadinessPrimaryCollaborateCollaborateCollaborateCollaborateCollaborate
ReleaseCollaborateCollaborateCollaboratePrimaryCollaborateCollaborate
AdoptionCollaborateNoneCollaborateAwareCollaboratePrimary
Maintenance loopAwareNoneNoneCollaborateAwarePrimary
Quarterly PlanningCollaboratePrimaryCollaborateCollaborateCollaborateCollaborate
CeremoniesCollaborateCollaborateCollaboratePrimaryCollaborateCollaborate
Metrics and DashboardsCollaboratePrimaryCollaborateCollaborateNoneCollaborate
Primary — owns or drives this step
Collaborate — actively contributes, doesn't own
Aware — informed, available if needed
None — no expected involvement
On selective involvement

Cross-functional collaboration does not mean pulling every engineer into every product call — that is low value and slows everyone down. The intent is to involve the right discipline at the right moment: Dev shows up early in Discovery to flag feasibility, not to sit through every requirements discussion. The Collaborate and Aware tiers above exist to make these calls intentional rather than habitual.

Recommendation: Async coordination mechanism for distributed teams

Teams can use Microsoft Teams, Slack or some other mechanism they choose to facilitate async communications. Rather than the everyone-in-the-room model used by fully co-located teams, cross-time-zone handoffs follow this pattern:

StepWhat happensTime cost
1. Written handoffOriginating team produces a structured artifact (spec, PR, design note) with explicit open questions flagged inline — not left implicit.Same day
2. Recorded contextFor anything nuanced, a short recorded walkthrough accompanies the artifact so the receiving team doesn't need a live call to understand intent.Same day
3. Agent-assisted triageReceiving team's agent reviews the handoff against context layer, flags genuine ambiguities versus questions it can answer itself.Minutes, async
4. Targeted async questionOnly genuine ambiguities are escalated to a human, asked specifically rather than open-ended, batched where possible.One overlap window
5. Scheduled sync (exception, not default)Reserved for decisions that are genuinely contested or carry high ambiguity. Not the default path for routine handoffs.As needed
Why this view exists: cramming AI involvement into the same diagram as workflow phases and collaboration overloads the chart. This view isolates the AI-participation question on its own spectrum, phase by phase.
Discovery
Human-led
AI assists
PM × Design Collab
Human-led
AI assists research, iteration
Functional Spec
AI drafts
Human confirms & owns
Technical Spec + TDD
AI drafts spec + tests
Dev confirms & owns
Story Draft + Pointing
AI drafts + suggests points
Team reviews & confirms
Development
AI executes (orchestrated loop)
Dev directs & reviews
CI + Deploy
Fully automated
Human review gate before merge
UAT
AI-assisted testing
Human validates against intent
Release & Readiness
AI drafts notes, checklists
Human coordinates & confirms
Adoption
AI monitors signals
Human interprets & decides
Maintenance loop
AI picks up, diagnoses, fixes
Human reviews & approves PR
Ceremonies
AI prepares pre-work
Human-led & human-owned outcomes
PI Planning
AI consolidates dependencies
Human-led, cross-team
Reading this view

The percentage split is directional, not a literal time measurement — it communicates which party is doing the bulk of the generative work at each step. A step that is mostly AI-colored still has a human confirmation point; a step that is mostly human-colored may still use AI for research, drafting, or summarization in the background. No step in the AI-SDLC removes human accountability entirely — every phase that produces a durable artifact has a named human owner.

Why this view exists: the Design team flagged that terms like ADR, DoD sign-off, and UAT walkthrough are used throughout the workflow without definition. This glossary makes them explicit for anyone reviewing the AI-SDLC regardless of discipline background.
ADR — Architecture Decision Record

A short written record capturing a significant technical decision: what was decided, why (the reasoning), and what alternatives were considered and rejected. ADRs are produced during Technical Spec and carried forward as a required input to engineering — they prevent the same trade-off conversation from happening repeatedly, and they give future contributors context for why the system is built the way it is.

Dispatch — Dispatch Approval

The explicit go decision, made by the Dev lead (HI-CTRL), that releases a scoped work unit into the AI orchestration loop. It is the gate between human direction and agent execution: task intent is set and TDD test cases are confirmed, then dispatch is approved. No agent begins implementation until dispatch approval is given, and execution authority remains with the human throughout.

DoD — Definition of Done

The agreed checklist a piece of work must satisfy before it counts as complete. In the AI-SDLC, DoD confirmation means: test coverage threshold met, all CI checks passed, human review confirmed, and (where applicable) design fidelity confirmed. DoD confirmation is a quality check that flows directly into automated deployment — it is not a separate stop-and-wait approval step.

UAT — User Acceptance Testing

Validation that a built feature actually does what was intended — checked against the original functional spec and acceptance criteria, not just against technical requirements. A UAT walkthrough is the structured session (live or recorded) where PM, Designer, and relevant stakeholders step through the feature to confirm it behaves as expected before Release.

Shared Context Layer

The persistent, continuously-updated source of project knowledge that AI agents draw from across every phase — including the codebase, prior ADRs, design artifacts, specs, and decisions. It is what allows an agent drafting a spec or a fix to be "grounded" rather than guessing, and it is the mechanism that replaces manual handoffs between phases.

Quality Check

A confirmation point that work flows through once criteria are met — replacing the term "gate" used in earlier versions of this workflow. The distinction matters: a quality check is part of the continuous flow, not a stop-and-wait approval queue. Work that meets the criteria proceeds immediately; work that doesn't loops back to the relevant step rather than waiting in a queue.

TDD — Test-Driven Development

Writing test cases before writing the implementation. In the AI-SDLC, the agent generates test cases from acceptance criteria during Technical Spec — before any code is produced — so the implementation has a concrete target to satisfy from the start.

HI-CTRL

Shorthand for "human in control" — the principle that a named human holds execution authority (Producer Mode) and merge authority (Reviewer Mode) throughout the AI-orchestrated development loop. No agent output reaches production without HI-CTRL confirmation.

RACI / ACE

A framework for clarifying who is Responsible, Accountable, Consulted, and Informed (RACI) — or an adapted variant — for a given decision or deliverable. Several open questions in this workflow (acceptance criteria ownership where TPMs remain active, ceremony ownership without a TPM) are pending a team-specific RACI, currently in draft. See the note on the Standup Pre-work and Retro + Learning cards in the Continuous Loop.

PI — Program Increment

A quarterly planning cadence used across all products and teams, where cross-team and cross-product dependencies are surfaced and sequenced before the quarter begins.