a published delivery method, gated stage by stage
AI-DLC, the AI-Driven Development Life Cycle from AWS Labs, is an open method for running software delivery with coding agents: 33 stages from intent to operations, each with the documents it produces, the role that reviews them, and the points where a person decides.
The AI-DLC Kit is a Kontour adaptation of that method. It pins one upstream commit and runs every stage through Flow Agents as a Flow step with a gate. A stage advances only when Flow has the evidence the gate asked for, not when the agent reports that it is done.
$ kontour-aidlc profiles ["bugfix","classic","enterprise","express","feature","infra","mvp","poc","refactor","security-patch","workshop"] $ kontour-aidlc check AI-DLC generated kit contracts verified.
Verbatim output from a fresh clone of the kit at f5190c2. check recompiles the 11 profile flows and 34 stage skills from the pinned upstream snapshot and fails if any committed file differs.
The problem
AI-DLC already says what each stage needs. The hard part with agents is enforcement: who confirms that the stage really produced its documents, that a reviewer read the current version, and that a person approved the exact thing that went forward.
A method written as instructions tells the agent which documents a stage must produce and who reviews them. Nothing in the instructions themselves checks that the documents exist, that the review happened, or that the reviewer saw the current version.
AI-DLC asks people to answer questions and confirm summaries at set points. When the answer is a line in a transcript, nothing ties it to the exact document it approved, and a later edit quietly inherits the approval.
Requirements change after the design was written from them. Unless something tracks which artifacts each stage read, the design stays marked complete against requirements that no longer exist.
How it runs
The kit imports the upstream stage graph, profiles and procedures byte-for-byte, with their source digests, and compiles them into ordinary Flow definitions and Flow Agents skills. It adds no lifecycle engine of its own. Each product keeps its own job:
The canonical run, every gate evaluation, route-back and retry budgets. The kit never writes Flow state directly; it attaches evidence and lets Flow decide.
Kit install and activation, the stage skills your agent reads, and the host execution: isolated Docker workers, a scoped provider broker, and the execution receipts.
Stage results arrive as trust bundles: claims, the evidence behind them and their status. A missing, failed, stale or tampered bundle cannot satisfy a gate.
verifiedpoc 8, bugfix 9, express 10, refactor 10, security-patch 10, infra 13, classic 18, mvp 23, workshop 26, feature 33, enterprise 33. Counts are from the kit’s compare.mjs method, which matched every profile against the pinned source.One stage, start to finish
The upstream record for this stage names a lead agent that writes the requirements, a separate lead that reviews them (advisory, at most two iterations), two sensors that check the documents, and a required summary confirmation: a person has to confirm before the stage can go on.
The kit compiles that into a gate with two required expectations. One is a completion claim: the current required artifacts and applicable checks were observed. The other is a review claim on the current artifact and source. Both have to be verified. Missing evidence routes back to the same stage, twice at most; after that the run blocks.
$ jq '.stages[] | select(.slug=="requirements-analysis") | {name, lead_agent, reviewer, review_class, reviewer_max_iterations, summary_confirmation, sensors, produces}' upstream/snapshot.json { "name": "Requirements Analysis", "lead_agent": "aidlc-product-agent", "reviewer": "aidlc-product-lead-agent", "review_class": "advisory", "reviewer_max_iterations": 2, "summary_confirmation": "required", "sensors": [ "required-sections", "upstream-coverage" ], "produces": [ "requirements", "requirements-analysis-questions" ] }
$ jq '.gates["requirements-analysis-gate"]' flows/feature.flow.json { "step": "requirements-analysis", "expects": [ { "id": "requirements-analysis-completion", "kind": "trust.bundle", "required": true, "description": "Requirements Analysis: current required artifacts and applicable checks were observed.", "bundle_claim": { "claimType": "aidlc.requirements-analysis-completion", "subjectType": "flow-step", "accepted_statuses": [ "verified" ] } }, { "id": "requirements-analysis-review", "kind": "trust.bundle", "required": true, "description": "Requirements Analysis: recorded review of the current artifact and source basis.", "bundle_claim": { "claimType": "aidlc.requirements-analysis-review", "subjectType": "flow-step", "accepted_statuses": [ "verified" ] } } ], "on_route_back": { "missing_evidence": "requirements-analysis", "default": "requirements-analysis" }, "route_back_policy": { "max_attempts": 2, "on_exceeded": "block" } }
Verbatim, from the kit at f5190c2. All 33 gates in the feature profile have a completion expectation; 13 also require a review claim, matching the 13 stages the method assigns a reviewer.
Run that gate through the Flow CLI before anything has been attached and it does not pass. Evaluation exits 1, routes the run back to Requirements Analysis, and records attempt 1 of 2. The next action and the place to resume come from the run’s own record.
Re-evaluating the same failed visit does not spend another attempt. Flow counts a new attempt only when the run returns to the gate or new failed evidence arrives, so retrying cannot exhaust the budget on its own.
$ flow start excerpt.flow.json --run-id ra-demo started flow run: ra-demo current step: requirements-analysis report: .kontourai/flow/runs/ra-demo/report.md $ flow evaluate ra-demo --exit-code route-back requirements-analysis-gate: Requirements Analysis: current required artifacts and applicable checks were observed. missing current step: requirements-analysis next action: return to requirements-analysis and replace failing evidence attempt 1/2 $ flow status ra-demo flow run: aidlc.requirements-analysis-excerpt / ra-demo current step: requirements-analysis ROUTE-BACK requirements analysis gate: Requirements Analysis: current required artifacts and applicable checks were observed. missing expected: Requirements Analysis: current required artifacts and applicable checks were observed., Requirements Analysis: recorded review of the current artifact and source basis. route: missing_evidence -> requirements-analysis; attempt 1/2; limit exceeded: no transition diagnostics: transition.gate.route-back status: active next action: return to requirements-analysis and replace failing evidence attempt 1/2 continuation: resume from requirements-analysis, not chat memory report: .kontourai/flow/runs/ra-demo/report.md ready steps: requirements-analysis
Verbatim. excerpt.flow.json holds the gate above, copied unchanged with jq into a two-step definition (requirements-analysis then user-stories) so it can run on its own.
When the stage reaches its confirmation, the run stops and the host writes a signed pending request. You answer the questionnaire, approve, deny or ask for changes with decide, then resume the same original request. The answer is bound to that request, the current visit and the exact artifact digests, so it cannot authorize a different version later.
To raise a concern about a review that came back clean, add an operator: concern. The author revises and a fresh reviewer has to dispose of that concern on the new bytes. To change an input that later stages already used, revise-input records the edit, and the evidence of stages that read the old version is invalidated through Flow, so they run again.
These are host-observed operator receipts, signed with the private controller’s key. The kit’s docs say plainly that they are not personally authenticated human signatures.
$ kontour-aidlc decisions --controller-root /private/run-controller $ kontour-aidlc decide --controller-root /private/run-controller \ --pending /private/run-controller/authority/pending/<digest>.json \ --reference "Operator answered the exact retained questionnaire" \ --disposition /private/operator-reply.json $ kontour-aidlc run --request /private/original-request.json \ --controller-root /private/run-controller --auth-file /private/provider-auth.json
Commands from the kit’s questionnaire reply guide. This is reference, not a capture: a live run needs Docker and model credentials, and we did not run one for this page. The tests below exercise the same path.
The kit’s conformance eval drives the published Flow and Surface packages through a one-expectation gate of the same trust.bundle kind. Verified evidence passes. Missing, failed, stale, wrong-revision and tampered evidence each block, and each names its reason.
The evidence in this eval is deliberately synthetic. It tests the package contracts, not a model’s output or how good it is.
$ node evals/public-flow-conformance.mjs > conformance.json $ jq -r '.cases[] | "\(.id) gate=\(.observed.gate) run=\(.observed.run) \(.diagnostics[0].reason // "")"' conformance.json verified-evidence gate=pass run=completed missing-evidence gate=block run=blocked failed-evidence gate=block run=blocked disputed stale-evidence gate=block run=blocked stale wrong-revision-subject gate=block run=blocked claim_not_found tampered-stored-bundle gate=block run=blocked integrity_mismatch $ jq -r .outcome conformance.json pass
These tests drive the real kontour-aidlc decide command against real Flow runs, with scripted stand-in workers in place of a model: questionnaire answers, operator concerns on a clean review, input revisions that are stale or denied, and model output rejected for its shape, which keeps its receipt and routes back for repair instead of being published.
$ node --test evals/questionnaire-replies.test.mjs evals/operator-review-concerns.test.mjs \ evals/input-revisions.test.mjs evals/observed-output-rejections.test.mjs ✔ normal signed CLI answers and edited fields resume a nondeterministic observed questionnaire producer without erasing operator input ✔ real intent assumptions wait before independent review, even with optional summary off, and exact operator acceptance retains labels ✔ ordinary signed operator concerns revise a ready model review without inventing model findings and re-reviews without accepting or restarting the old stage ✔ ordinary signed input revision custody and real reentry: stale ✔ ordinary signed input revision custody and real reentry: denied-after-apply ✔ actual malformed planning output retains receipt without publication and new canonical invocation repairs safely: shape … ℹ tests 23 ℹ pass 23 ℹ fail 0
Test names are verbatim, with timings removed; the ellipsis stands for 17 more passing cases. The full suite, npm test, reported 274 tests, 274 passing, on the same commit. The paths arrived in kit pull requests #13, #16, #18 and #20.
What you get
Every stage leaves evidence that Flow evaluated, and every person-made decision leaves a receipt bound to what it decided. After a run you can see which stage it stopped at and why, without asking the agent.
Where the kit is stricter than the pinned upstream, it says so: missing checks never count as passing, review evidence must match current bytes even where upstream guard policy would keep a stale verdict, and artifact presence alone never advances a run. These are recorded as deliberate differences in parity.json.
Status
The kit is not on npm; @kontourai/aidlc-kit returns 404 from the registry. Install it from GitHub at a commit you have reviewed. It pins Flow 5.2.0 and Flow Agents 7.2.0; install and activation also completed under Flow Agents 8.0.0.
Stage selection, order, roles, artifact contracts and policies are compared against the pinned source. That does not show the kit behaves like the upstream engine.
A first paired comparison against the upstream method produced no execution-qualified pairs. The parity ledger records effectiveness as not_verified, and nothing here claims the kit produces better software.
Deployment and operation stages need a host-supplied provider and existing authorization. Selecting a stage never deploys anything on its own. Live runs need Node 24, Docker and model credentials.
Install
Installing the kit validates the repository, copies it and records a content hash. Activation writes the 11 profile flows, 34 stage skills and 11 docs into your runtime’s projection. Running a profile is a separate step: flow-agents kit run aidlc with a request that names the profile, the task and finite model, turn and time budgets.
The environment setup guide covers the Docker worker, provider broker and authentication.
$ npm install "git+https://github.com/kontourai/aidlc-kit.git#f5190c245e51a9598fb8383a28076ced7e58de61" (npm output omitted) $ npx flow-agents init --runtime base --telemetry-sink local-files --dest . (init output omitted) $ npx flow-agents kit install node_modules/@kontourai/aidlc-kit --dest . installed local kit 'aidlc' at …/kits/local/repositories/aidlc $ npx flow-agents kit activate --dest . --format json > activation.json $ jq -r '[.generated_runtime_files[] | select(.kit_id=="aidlc") | .asset_class] | group_by(.) | map("\(.[0]): \(length)") | .[]' activation.json docs: 11 flows: 11 skills: 34 $ jq -c '{errors, warnings}' activation.json {"errors":[],"warnings":[]} $ npx flow-agents kit status --dest . | jq '{id, state, recorded_hash, observed_hash}' { "id": "aidlc", "state": "installed", "recorded_hash": "sha256:664aab4e7424cdf9b641451392b67dba2d6fe90471dc06da4d1eaf45eddcbf39", "observed_hash": "sha256:664aab4e7424cdf9b641451392b67dba2d6fe90471dc06da4d1eaf45eddcbf39" }
Verbatim, in a fresh empty Git workspace, using the Flow Agents 7.2.0 binary the kit installs. The workspace path in the install line is elided. A second clean workspace produced the same content hash.
AI-DLC is published by AWS Labs in awslabs/aidlc-workflows under the MIT-0 license. The kit imports its methodology from commit 2a555f7 (declared version 2.11.0) and keeps the original license in upstream/. The kit is maintained by Kontour, is not an AWS product, and is licensed Apache-2.0.