Set up an AI-DLC delivery pod
Use this guide to staff one pod around a bounded feature or defect. The core delivery cadence is typically 2 to 4 weeks per feature.
1. Confirm the outcome boundary
Section titled “1. Confirm the outcome boundary”Record the application or product context, the first intended outcome and the client organization that can accept it. Link the boundary to its intake record.
Do not start with an open-ended technology objective. If the work cannot be specified, evaluated, countersigned and learned from, it is not ready for AI-DLC outcome delivery.
2. Staff the five-person delivery pod
Section titled “2. Staff the five-person delivery pod”The pod builds and signs. A discipline describes the person’s primary craft. A hat describes the accountability they carry for a feature.
| Seat | Count | Accountability hat | Owns | Signs at Judge |
|---|---|---|---|---|
| Spec owner | 1 | Spec owner | Define ceremony and product spec | Product intent and scope |
| Evaluation engineer | 1 | Evaluation lead | Evaluation plan, sufficiency thresholds and false-pass controls | Evidence sufficiency |
| Engineer | 2 | One wears technical boundary lead | Technical spec, agent supervision, code and release boundaries | Technical correctness |
| Designer | 1 | Design fidelity lead | Design spec, component states and fidelity rubric | Design fidelity |
Design is a standing seat when the work has a UI surface. For headless work, staff zero or one designer and record design fidelity as not applicable when it does not arise.
3. Assign authorship without self-ratification
Section titled “3. Assign authorship without self-ratification”Define is split by spec type:
- The spec owner authors the product spec.
- The engineers author the technical spec.
- The designer authors the design spec when a UI surface exists.
- The evaluation engineer maps every acceptance criterion to an evaluation path.
Any qualified pod member can claim a spec, but the author cannot ratify the spec they wrote. Record who authors and who countersigns each spec before Define closes.
4. Staff the two-person Workbench platform team
Section titled “4. Staff the two-person Workbench platform team”Workbench operationalizes the loop. Its platform team supports the pod and is consulted at Judge.
| Seat | Count | Hat | Responsibility |
|---|---|---|---|
| Engineer or architect | 1 | Agent operations lead | Agent workflow, runbook, supervisor escalation, observability and recovery |
| Engineer or architect | 1 | Platform and data | Worktrees, providers, intake connectors, telemetry, artifact lineage and orchestrator operations |
The same two people can support multiple pods only when response and recovery commitments remain credible.
5. Name client counterparties
Section titled “5. Name client counterparties”| Client role | Responsibility |
|---|---|
| Outcome counterparty | Countersigns the spec and accepts or rejects the outcome. Outcome delivery cannot proceed without this named owner. |
| Controls and access owner | Approves repository, data and tool access. Owns the client exception and incident path. |
| Domain SME or data owner | Supplies domain judgment and data lineage the pod cannot provide for itself. |
| Executive sponsor | Funds the mandate and receives escalations that exceed the delivery boundary. |
Outcome acceptance and production release are separate decisions. Name the release authority when it differs from the outcome counterparty.
6. Place governance and delivery around the pod
Section titled “6. Place governance and delivery around the pod”The delivery lead runs status cadence, delivery health, scope, commercials and the escalation line to the executive sponsor. The delivery lead holds no Judge signature.
The head of AI-DLC owns portfolio staffing, operating indicators and refusal authority. Compounding and research promotes reusable patterns, defects and conventions after delivery. Research cannot grade pod work it contributed to.
7. Run the readiness check
Section titled “7. Run the readiness check”Do not enter the delivery loop until all applicable items are true:
- Five delivery seats are filled, with design adjusted only for a headless feature.
- Both Workbench platform hats are assigned.
- The outcome counterparty is named.
- Controls, access, domain knowledge and escalation have named owners.
- Each spec has an author and an independent ratifier.
- Every applicable Judge claim has a named signer.
- The team has agreed the ceremonies and exit gates.
- The named people have reviewed the pod RACI.
The operating ecosystem can add outcome planning, SME clinics, design review or client release ceremonies. Record these as overlays without changing the core decision rights.