Skip to content

Worksheet — SDLC mapping

Phase: 2 — Scale; refreshed whenever a new stage of work adopts AI (e.g., when agents move from "write code" to "write and run tests"). Duration: 90 minutes. Primary output: AI-SDLC map + stage-level controls + Decision Record.

Why this meeting matters

Most AUPs say "use approved tools for code generation." That is only one SDLC stage. In practice, AI is used at requirements drafting, design, code generation, review, testing, documentation, and operations — each with different risk profiles, different data exposures, and different regulatory touchpoints.

Without an SDLC map, the controls you build tend to be clustered at "code generation" and porous everywhere else. The map makes the gaps visible.

Pre-work

Who to invite

Sizing guide

  • Small (< 50): Founder + senior engineer + Product owner. 60 min.
  • Mid (50–500): CoE + 1–2 Eng leads + Product + DevEx + AppSec. 90 min.
  • Enterprise (500+): CoE + Eng Architect + Product Ops + DevEx + AppSec + Platform Ops + Documentation lead + Data Governance. Two sessions: stage-by-stage walk then controls design.
  • Regulated: add Compliance and QA/Validation (especially for industries with FDA/FSA style validation for software).

In the room:

  • CoE Lead — owns the framework.
  • Eng Lead or Architect — maps activities to reality.
  • Product / Analyst — upstream stage owner.
  • DevEx / Platform — tooling integration points.
  • AppSec — controls per stage.
  • Operations / SRE — downstream stage owner.

Materials to circulate 48 hours in advance

  1. Current SDLC diagram — if one exists, even informal.
  2. AUP — to see where it already speaks to specific stages and where it's silent.
  3. Risk classification — so stage controls can be tiered.
  4. Frameworks overview — which framework applies to which stage.

The stages

Stage Typical AI activity
1. Ideation / Requirements Drafting user stories, acceptance criteria, domain analysis
2. Design / Architecture Proposing designs, generating ADRs, sequence/C4 diagrams
3. Planning / Estimation Task breakdown, estimate ranges
4. Implementation Code generation, refactoring, scaffolding
5. Review PR review assistance, style/lint suggestions, diff explanations
6. Testing Test generation (unit, integration, property-based), test data synthesis
7. Documentation API docs, runbooks, changelogs, in-line comments
8. Release / Deploy Release-note drafting, rollout script generation
9. Operations Alert triage, incident summaries, postmortem drafts
10. Maintenance / Sunset Migration scripts, refactors, deprecation notices

Agenda (90 minutes)

Time Topic Owner
0–10 Purpose, rules, walkthrough of the ten stages. Facilitator
10–40 Stage-by-stage. For each stage: current AI use? Desired? Risks? Rotating
40–60 Controls per stage. What inputs are allowed, what outputs are reviewed, what evidence is captured? CoE + AppSec
60–75 Cross-stage concerns. Data flow, prompt lifecycle, audit trail continuity. All
75–85 Governance additions. AUP gaps, runbook changes, training updates. Facilitator
85–90 Sign. All

Discussion prompts (per stage)

For every stage, work through the same six questions. Don't skip; the pattern matters.

  1. What AI activity is happening today at this stage? (Often surprising — teams are using AI at stages they haven't mentioned in any policy document.)
  2. What do we want to allow at this stage, next 12 months?
  3. What data is involved? (Source code, customer data, financial data, PII, contract text.)
  4. What risk tier does this data touch? (Map to the risk classification.)
  5. What controls are required? (Prompt lifecycle, reviewer gates, audit retention, logging.)
  6. What evidence captures this? (Who asks us during an audit, and what would we show?)

Stage 1 — Ideation / Requirements

  • AI is often used to draft user stories from conversational notes ("take this meeting transcript and produce a JIRA-ready story"). Are meeting transcripts in the approved-input category?
  • If requirements drafted by AI become the authoritative artifact, how do we prevent silent drift from what the stakeholder actually said?
  • Does the Product Owner review and attest?

Stage 2 — Design / Architecture

  • AI proposing architecture is increasingly common — what level of senior review is required before a proposed ADR is accepted?
  • Are design artifacts checked against prior ADRs for drift? (AI is prone to re-proposing patterns the company has already rejected.)

Stage 3 — Planning / Estimation

  • Estimation help is generally low-risk; but are the estimates flagged as AI-derived so managers don't treat them as firm?

Stage 4 — Implementation

  • This is where most controls already live. Use this stage to cross-check the AUP for gaps.
  • Agent-driven implementation (e.g., multi-file edits by an AI agent) needs explicit rules — is each file still reviewed individually? Is the agent's decision log retained?

Stage 5 — Review

  • AI reviewers are tempting because they scale — but they shouldn't replace human review, only augment it.
  • What happens when AI review suggestions conflict with human review? Which wins, and how is the disagreement captured?

Stage 6 — Testing

  • Test generation is one of the highest-leverage AI activities — and one of the most dangerous, because a generated test that "passes" may be testing the wrong thing.
  • Are generated tests subject to the same review standard as generated implementation code?
  • For mutation testing / property-based test generation, what is the evidence that the test suite actually caught the original bug patterns?

Stage 7 — Documentation

  • AI-generated docs decay unless re-generated. Is there a cadence?
  • Are generated runbooks validated against real incidents or tabletops?

Stage 8 — Release / Deploy

  • Release-note drafting is low-risk; rollout script generation is high-risk.
  • Are AI-generated rollout scripts reviewed by the SRE team before execution?

Stage 9 — Operations

  • AI summaries during an incident can help — or mislead. What is the human-in-the-loop requirement for an AI-generated incident summary shared externally?
  • Postmortem drafts: who is the responsible author?

Stage 10 — Maintenance / Sunset

  • Migration scripts are high-risk (they change prod data).
  • Deprecation notices are low-risk — but must be reviewed for customer-facing accuracy.

Cross-stage concerns

  • Data flow. A prompt at Stage 1 that contained a customer name is different from a prompt at Stage 7 that contains the same name. Build a map of what data enters the AI system at which stage.
  • Prompt lifecycle. Where do prompts/completions live across stages? (Typically they should be discarded after the stage unless audit requires retention.)
  • Audit trail continuity. An audit asks "how did this production-shipped code get here?" The AI-SDLC map should let you answer that question stage by stage.
  • Compensating controls. When a stage lacks a specific AI control, what non-AI control compensates? (E.g., static analysis at Stage 5 compensates for limitations in AI review at the same stage.)

Map template

AI-SDLC Map — v1.0

Effective: 2026-07-01 Owner: CoE Lead Scope: Entire engineering organization.

Stages.

Stage AI allowed? Who reviews Prompt retention Audit evidence
1. Requirements Yes, with PO review Product Owner 30 days PO sign-off recorded in JIRA
2. Design Yes, with Architect review Architect 90 days ADR with ai-assisted tag
3. Planning Yes Tech lead 30 days Estimate metadata
4. Implementation Yes, per AUP PR reviewer Per AUP PR with ai-adjacent tag
5. Review Augment only Human reviewer 30 days Review comments thread
6. Testing Yes, with review Human reviewer Per AUP Test file headers
7. Documentation Yes Doc lead 30 days Changelog tag
8. Release Yes for notes; review for scripts Release manager 30 days Release record
9. Operations Advisory only On-call + SRE lead 90 days Incident record
10. Maintenance Yes, with AppSec for migrations Owning team + AppSec Per AUP Migration record

Tier overlays.

  • Critical-tier systems: all stages require V.E.R.I.F.Y. Level 3 and AppSec pre-merge.
  • High-tier systems: Stages 4–6 require Level 2 and peer review beyond immediate team.
  • Medium-tier systems: Stages 4–6 default at Level 1; others at standard review.

Cross-stage controls.

  • Prompt-retention owner: role.
  • Cross-stage audit trail: every AI-touched artifact carries the SDLC-stage tag and the tool-session identifier.
# AI-SDLC Map — v1.0

**Effective:** 2026-07-01
**Owner:** CoE Lead
**Scope:** Entire engineering organization.

## Stages

| Stage | AI allowed? | Who reviews | Prompt retention | Audit evidence |
|---|---|---|---|---|
| 1. Requirements | Yes, with PO review | Product Owner | 30 days | PO sign-off recorded in JIRA |
| 2. Design | Yes, with Architect review | Architect | 90 days | ADR with `ai-assisted` tag |
| 3. Planning | Yes | Tech lead | 30 days | Estimate metadata |
| 4. Implementation | Yes, per AUP | PR reviewer | Per AUP | PR with `ai-adjacent` tag |
| 5. Review | Augment only | Human reviewer | 30 days | Review comments thread |
| 6. Testing | Yes, with review | Human reviewer | Per AUP | Test file headers |
| 7. Documentation | Yes | Doc lead | 30 days | Changelog tag |
| 8. Release | Yes for notes; review for scripts | Release manager | 30 days | Release record |
| 9. Operations | Advisory only | On-call + SRE lead | 90 days | Incident record |
| 10. Maintenance | Yes, with AppSec for migrations | Owning team + AppSec | Per AUP | Migration record |

## Tier overlays

- **Critical-tier systems:** all stages require [V.E.R.I.F.Y. Level 3](../frameworks/verify-protocol.md) and AppSec pre-merge.
- **High-tier systems:** Stages 4–6 require Level 2 and peer review beyond immediate team.
- **Medium-tier systems:** Stages 4–6 default at Level 1; others at standard review.

## Cross-stage controls

- Prompt-retention owner: <role>.
- Cross-stage audit trail: every AI-touched artifact carries the
  SDLC-stage tag and the tool-session identifier.

Outputs

  1. AI-SDLC map — the table above, filled in.
  2. Decision Record — what was allowed, what was restricted, what was deferred.
  3. AUP amendments — specific clauses to add based on map gaps.
  4. Runbook / process updates — where AI is touching operations, what the runbook must now include.
  5. Training module updates — by stage, for the affected roles.

Follow-ups

  • Within 14 days: AUP amendments drafted.
  • Within 30 days: AI-SDLC map published to a durable location.
  • Every 6 months: refresh the map (stages shift fast, especially as agents expand capability).

Facilitator tips

  • Walk the current reality first. Ask "what's happening now?" before "what should happen?" — shadow use is the norm and must be named before it can be governed.
  • Don't boil the ocean. If three stages are contentious, park them on a list and come back after the easy stages are agreed.
  • Test the map against a recent PR. Walk a real PR through the map — does it clear each stage, and is the evidence actually retrievable?
  • Prioritize the Critical-tier overlay. If the Critical systems aren't covered, the rest is lower-stakes polish.

Anti-patterns

Don't

  • Don't treat Stage 4 (Implementation) as the only stage with controls. Most incidents surface at Stage 6 (Testing) or Stage 9 (Operations), but trace back to weak Stage 1–2 governance.
  • Don't allow "AI wrote it" to be the final attributable author. A human is always the responsible reviewer; the map must record who.
  • Don't forget retention. A stage without retention rules is an audit gap.
  • Don't assume the map is finished. Agents' capabilities change materially every quarter; revisit the map accordingly.

Next