EUWardenAI SDLC · model
← Process presentation Process tools
Architectural assumptions of the process

What the AI SDLC is built from

Four views of one system. The goal: separation of responsibilities, not more process layers. Each building block has one job; whatever is shared across roles lives in one place — never in copies.

01System building blocks

Nine building blocks, one responsibility each

An agent skill contains only the behavior of its role or domain. How to talk to a human, hand work between agents, access tools and record evidence — those are shared contracts, defined once and shared by every role.

HUMAN Human interaction contract one way of talking for every role AI SDLC PROCESS Intake → Analysis → Architecture → Planning → Development → Verification → Release → Learning → Done SKILLS capability of one role / domain Agent communication contract one handoff format Machine output contract deterministic packets Decision and scope rules when an agent decides, asks, stops Tools Jira · GitHub · CI · runtime Domain knowledge specs · ADR · security · operations EVIDENCE AND STATE stage in Jira · PR HEAD · CI results · runtime proof process activates roles feeds authoritative record
A skill contains only the role's behavior. Communication contracts, decision rules, tool access and evidence recording are shared — defined once, used by everyone.
Process

says which stages exist and when work moves forward.

Skills

say who (which capability) performs the specialist work.

Human interaction

says how each role talks to a person — one shared contract.

Agent communication

says how agents hand work to each other — a concise, structured format.

Machine output

says how deterministic packets are encoded — only where needed.

Decision and scope rules

say when an agent may decide, must ask, must stop.

Tools

define how authoritative systems are read and changed.

Domain knowledge

supplies the truth about the domain: specifications, ADRs, security requirements.

Evidence and state

prove what really happened — not what was declared.

02Dependency rule

Dependencies point toward shared foundations

The process and skills depend on shared contracts — never the other way around. If behavior is shared by multiple skills, it moves into a shared contract instead of being copied. Copies always drift apart; one contract does not.

Process definitions stages · gates · flow Role and domain skills specialist behavior Humancontract Agentcontract Machineoutput Decisionpolicy Toolcontracts Domainknowledge ✗ the human contract must not depend on skills ✗ machine output does not define the human conversation SHARED FOUNDATIONS — defined once
The dependency direction is an architectural rule, not a convention: the foundations know nothing about skills. That is why adding a new role changes neither how humans are talked to nor the evidence format.

Target rule: if behavior is shared by multiple skills — move it into a shared contract instead of copying it. No skill may define a competing communication contract.

03Runtime loop

From need to outcome — always through evidence

Every unit of work goes through the same loop: understand the goal, pick the owner, specialist work on authoritative systems, evidence collection, gate. The human sees goals, decisions, risks and outcomes — internal execution packets stay inside until they ask for them.

NEED goal + scope human conversation stage owner process picks the role specialist work skill + domain knowledge evidence Jira · PR · CI · runtime GATE human decision explained in goal context, not jargon blocked named reason + next owner OUTCOME FOR THE HUMAN after passing all stages needs a human decision fail / blocked pass → next stage, until Done
The gate has three exits: forward (evidence complete), to the human (a decision reserved for people, explained in the language of the goal) or blocked (a named reason and the next owner — never silence).
04Lifecycle map

One line, zero alternative routes

All delivery rides one line. Required controls — security, architecture — join it as supporting evidence, they do not create detours. Every transition between stages has a named exit gate and exactly one role that fires it. Jira holds the truth about the stage, GitHub the truth about the code, and the human conversation is about goals and decisions — not every intermediate station.

Intake Analysis Architecture Planning Development Verification Release/Close Learning Done exit gate: scope accepted analysis accepted design accepted plan accepted PR + CI green verification PASS merged, deployed lessons recorded fired by: Domain Director Domain Director Domain Director Domain Director Domain Director QA role merge gate human accepts Jira: stage state GitHub: code state from any active stage and back again BLOCKED · waiting on a person or a dependency returns to the status it came from — not to the start security evidence supports, does not bypass human conversation goal · scope · decisions · acceptance
One line = no alternative routes to "Done". Every segment carries a named exit gate and exactly one role that fires the transition — authority moves from the Domain Director to QA, the merge gate and the human. Controls join as evidence. "Blocked" is reachable from every active stage and returns exactly where it came from; there is no shortcut to "Done".

This is a map of responsibilities, not a second process engine. Detailed stage rules live in the canonical process documentation, role behavior in skills, shared communication in shared contracts. The map shows where each thing lives — and why nowhere else.

05Evidence depth

One path, three depths of evidence

Every change goes through the same lifecycle — but the required evidence bundle scales with the change's reach. The classification is verified by a gate based on what the change actually touched, not on the author's declaration.

ReachWhat it coversRequired evidence bundle
LOW Documentation, descriptive configuration — changes that do not alter system behavior. Lint, page/document build, one review. No full product test run.
STANDARD Product code — logic, APIs, interface, tests. Full bundle: tests, lint, formal review, QA verdict pinned to the exact revision.
HIGH Authentication, cryptography, data migrations, infrastructure. The standard bundle extended with a mandatory security opinion; all verdicts bound to the same revision.

What this is not: these are not three process paths. There is one path — the same sequence of stages leads to "Done". Only the depth of required evidence scales, and the reach classification is verified by a gate, not by the author of the change.

Let's talk through this architecture Process presentation → Results → Walkthrough demo → Adoption path → Process tools → FAQ →