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 through configured native coding engines or isolated Docker workers with 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.
Review the evidence
When intent, requirements or design stops for a produced-artifact review, the optional Survey interface displays the current artifact bytes, source references, original deadline and remaining worker budget. The review summary shows why the run is waiting, open findings and reviewer concerns. Read each document and mark it reviewed, then approve, decline, request changes with a correction note, or record that you could not confirm. A changed artifact or expired request is refused. Resume the same request through Flow Agents after the decision is recorded.
The kit pins Flow Agents 9.0.0, which opens the native review interface with Survey 8.2.0 and its persisted review session. Its MCP server and embedded MCP App can record decisions against that same session; the host applies admitted decisions through the same producer callback. The review shows findings, artifact acknowledgments and named actions, with one final submit button. Questionnaire answers and input confirmations keep their existing typed decision interfaces.
The kit retains AWS’s sensor names for methodology-specific checks such as required sections and traceability. Plumb carries bounded check results and their evidence basis. Veritas consumes the same observation contract for repository standards and readiness; its colocated Governance Kit uses the same native review host for standards plans, while its engine retains standards and readiness evaluation.
The interface runs locally and records your decision against the current artifact version; no reviewer account is needed. Could not confirm leaves approval unresolved, and requesting changes requires a new author and distinct review within the original budget.
npm install --save-exact "github:kontourai/aidlc-kit#f7f167e29927427cb33f8cf624879493345a474f"
# Write artifact-review.json using the current pending subject:
# {"schema":"kontour.kit.review_request","version":"1.0","kit_id":"aidlc",
# "input":{"controllerRoot":"/private/run-controller",
# "pendingFile":"/private/run-controller/authority/pending/CURRENT.json",
# "reference":"operator:proposal-reviewed"}}
npx flow-agents kit review aidlc --dest /absolute/aidlc-bootstrap \
--request /private/artifact-review.json
# Open the loopback URL, read the findings, and mark each artifact reviewed.
# Choose an action, add a correction note if needed, and send the review once.
# Resume with the original kit run request and controller.This command reference targets the current source at f7f167e. See the review and resume guide for setup and the MCP command. Keep the bootstrap and private controller outside the application workspace. The native host verifies installed kit integrity again before applying; the kit checks its current subject and original budget. Existing kit-specific commands remain compatibility paths.
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. The current kit pins Flow 5.2.0 and Flow Agents 9.0.0, and uses Plumb 0.2.0 for shared check observations. The terminal captures below retain their original revision and dependency versions.
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.
Independent effectiveness remains withheld pending final-source qualification and grading. 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 declared profile flows, stage skills and 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 install, setup, doctor, native execution, review and resume; the environment guide covers Docker and provider 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.