The AI-DLC operating process
AI-DLC governs a delivery loop in which people own intent and proof, Workbench controls execution and named people judge the result. The process is designed around one rule:
If work cannot be specified, evaluated, countersigned and learned from, it is not ready for AI-DLC outcome delivery.
The operating ecosystem
Section titled “The operating ecosystem”The operating ecosystem connects readiness, outcome delivery and compounding capability. It shares context, evidence and learning while each organization retains its own accountability and decision rights.
Readiness establishes people, authority, access, controls, inputs and baselines. Outcome delivery moves one feature through Define, Plan, Execute, Judge, Release and Learn on a typical 2 to 4 week cadence. Workbench decomposes that feature into small, reviewable tasks.
The capability-compounding loop improves future delivery. Workbench extracts observations from runs. Compounding and research promotes reusable patterns, corrections and conventions so future features begin with stronger defaults. This loop cannot grade delivery work it helped produce.
Three operating groups
Section titled “Three operating groups”Delivery pod
Section titled “Delivery pod”The five-person pod contains a spec owner, evaluation engineer, two engineers and a designer when UI work requires one. These people author the specs, supervise execution, evaluate the outcome and sign their claims.
Workbench platform
Section titled “Workbench platform”Two engineers or architects operate agent workflows, runbooks, worktrees, providers, telemetry and artifact lineage. Workbench makes execution observable and recoverable. It does not accept the outcome.
Client counterparties
Section titled “Client counterparties”The outcome counterparty countersigns the contract and accepts or rejects the result. Controls and access, domain knowledge, executive sponsorship and production release remain client responsibilities.
Outcome delivery is not ready when the outcome counterparty is missing.
Feature lifecycle and ecosystem implementation
Section titled “Feature lifecycle and ecosystem implementation”The feature lifecycle stays small: Define, Plan, Execute, Judge, Release and Learn. The operating ecosystem supplies the organizational structure needed to make those stages work across boundaries.
| Feature lifecycle | Ecosystem implementation |
|---|---|
| Intake | Outcome and feature plan linked to a tracking issue and Spec ID |
| Define | Mob elaboration, developer accuracy check, BRD review and locked specs |
| Plan | Approved task graph, file ownership and independent verification |
| Execute | Mob build, isolated branches, deterministic gates and retained evidence |
| Judge | Confidence package, independent signatures and client outcome acceptance |
| Release | Engineering integration followed by separate client release authority |
| Learn | Live validation, recorded signals and promoted reusable learning |
The operating ecosystem also assigns a delivery lead, status cadence, SME clinic, escalation ladder and systems of record. These make the process operable but do not change its core decision rights.
Evidence is not authority
Section titled “Evidence is not authority”Workbench can build a confidence package and compute a recommendation. It cannot sign product intent, technical correctness, design fidelity, evidence sufficiency or outcome acceptance.
The merge gate signs nothing. The confidence gate records claim decisions. Outcome acceptance does not automatically approve release or declare production readiness.
Put the model into operation
Section titled “Put the model into operation”- Set up the delivery pod.
- Establish the ceremonies and records.
- Confirm the canonical RACI.
- Use the ceremony reference during delivery.