AceLM alm Request early access Sign in

The lifecycle

From a requirement to a release you can defend.

AceLM combines planning, execution, review, and continuous learning to improve quality, speed, and cost while giving people control over how much responsibility they delegate. The lifecycle is how that happens, one gate at a time.

It is the same loop as on the overview, plan, build, review, verify, and learn, with each step opened up to show exactly what it must prove.

An agent saying "done" is a claim, not a result. Each gate asks for the evidence before the work moves on, so "done" means the same thing every time.

Six stages

Every stage leaves evidence for the next.

Take a small fix: expired sessions must be rejected (requirement AUTH-03). The regression tests pass, but a dependency review finds an unresolved vulnerability, so the release stays blocked. Here is how each stage keeps those results connected and in view.

1.

Specify

Gate: requirements written down

Record requirements, scope, constraints, architecture, interfaces, design assumptions, and acceptance criteria.

2.

Plan

Gate: every task has a check

Document the approach, alternatives, tradeoffs, affected files, and dependencies. Pair execution work with explicit verification obligations.

3.

Review and accept

Gate: a person accepts the scope

Independently challenge the requirements, architecture, design, and plan. Resolve blocking findings and record scoped acceptance separately from the review verdict.

4.

Build

Gate: work stays in scope

Execute accepted work in separate Git worktrees. Record changes, decisions, deviations, and proof of work; newly discovered scope needs the appropriate review and authority.

5.

Verify

Gate: evidence for the final revision

Independently check completeness against accepted requirements and observed functionality. Run applicable tests, regression checks, builds, linting, type checks, and security checks. Record evidence for the final revision and identify skipped or unavailable checks.

6.

Check release readiness

Gate: a person authorizes the release

Evaluate required evidence, documentation, and unresolved findings. Surface blockers for the team's release decision.

A passing check has a scope

Verification records are intended to show what ran, what it evaluated, and what remains unresolved. Passing checks provide evidence for the tested scope; they do not establish that every requirement is met or every vulnerability is absent.

State machines

How work gets iterated and why it gets better.

Every piece of work, from a specification to a release, moves through written states. When a problem turns up, the work goes back to the step that can fix it, and the reason is recorded, so the next attempt starts from what the last one learned. Nothing skips a gate quietly.

Red lines are kick-backs: where a problem is found, and the step the work returns to. Each numbered card says what triggers it. marks where a person decides.

Specification

Specification lifecycle from draft to implemented. Kick-backs: a reviewer finds an untestable criterion; the owner asks for a revision at acceptance; a new policy triggers re-review; building shows a requirement was wrong.

Backlog item

Backlog item lifecycle from draft to done. A quick change takes one chat message: AceLM records it, checks it is small, changes it in its own worktree, runs the tests and a separate checker, and commits it without pushing; anything bigger comes back to you. Also shows the direct chore route. Kick-backs: an unreproducible bug report; a chore that turns out to need a plan; broken successor mapping; a required successor abandoned.

Plan

Plan lifecycle from draft to executed. Kick-backs: a step with no check or rollback; the builder needs files outside approved scope; a regression test fails; evidence is regenerated without re-running code; the acceptance criterion itself was wrong.

Release

Release lifecycle from draft to released. Kick-backs: a lens finds an issue and remediation runs before the next lens; a late fix invalidates the reviewed snapshot; a smoke test fails and is remediated; a changed candidate needs fresh review and authority.

Shared rules

Expected waits keep the state already reached and never consume a retry. Failure states are rejected, verify-err, exec-err, gate-fail, interrupt, and crashed. Recovery resumes only unfinished work.

All four on one page: open the full-size lifecycle-flowchart.svg

Show every state, kick-back, and failure rule

The diagram is the overview. The detailed rules for execution, verification, derivation, and recovery, and the status vocabulary, are in the documentation for invited teams. Work keeps the phase it reached while it waits, so nothing silently slides backward.

Specification

Spec
Origins & Sources:

Originates from requirements, product vision, RFC proposals, or graduated backlog items.

draft → to-review → reviewing → reviewed → accepted → implementing → implemented
Kickback & Rework:

Changed scope or content returns to draft for revision, independent review, and acceptance again. Unchanged-content reassessment returns to to-review. Ordinary waiting retains the reached phase.

Graduation Target:

An accepted spec may derive Backlog Items, Plans, or Plan Sets. Children start in draft and do not inherit acceptance. Adding required fulfillment after completion requires explicit closure revalidation or reopening.

Exit States:

At any point, can transition to superseded, retired, or abandoned.

Backlog Item

Backlog
Origins & Sources:

Can originate Ex Novo (direct triage/idea), from an accepted Spec, or from a Plan (bug, chore, or follow-up feature discovered during execution or verification).

draft → to-review → reviewing → reviewed → accepted → graduating → graduated → done
Direct Chores (No Plan Needed):

A bounded chore may proceed without a full plan, but still requires accepted scope, execution evidence, and independent verification against its acceptance criteria before done. The direct arrow is shorthand for these gates.

Quick change. The smallest chores need only a chat message. AceLM records the item, accepts it under the project's standing quick-change permission, makes the change in its own worktree, runs the required checks and an independent verifier, and commits to the current branch without pushing. If the request is not small and low risk, it stops before committing and proposes a route.

Kickback & Graduation:

Changed content returns to draft and fresh independent review/acceptance; unchanged-content reassessment returns to to-review. For larger work, graduates to one or more of Specs, Plans, or Plan Sets.

Exit States:

At any point, can transition to superseded, retired, or abandoned.

Plan

Plan
Origins & Sources:

Can be created Ex Novo (standalone operational/refactor plan), originate directly from an accepted Spec, graduate from a Backlog Item, or act as a sub-plan of a Plan Set.

draft → to-review → reviewing → reviewed → accepted → executing → verifying → executed

A plan set is versioned membership and orchestration, with required child completion, the orchestrator's own E/V obligations, and integration checks. No independent set state machine is agreed.

Plan E/V Item Contract:

Every plan requires at least one E-* execution deliverable and one V-* empirical verification item. Completing E items never implies a V pass.

Discovery Feedback Loop:

Realizing a bug, missing chore, or follow-up feature during execution or verification creates new Backlog Items for tracking.

Exit States:

At any point, can transition to superseded, retired, or abandoned.

Release Candidate

Release
Release Sequence:

Versioned artifact governing deployment and distribution through explicit candidate assessment.

draft → to-review → reviewing → reviewed → accepted → releasing → verifying → released
Assessment Profile & Verdicts:

Evaluates configured lenses from the 31-concern catalog and records candidate-bound findings, evidence, and an assessment verdict. Separately, readiness for release is go, need-ok, no-go, or unspecified (-). Positive assessment alone does not authorize publication.

Candidate-Specific Authority:

Acceptance of a spec or plan is not release authorization. Humans explicitly authorize the exact candidate commit, target environment, and actions.

Post-Release Verification:

Reaching released requires successful post-deployment smoke tests and health checks.

Universal Lifecycle Rules & Failure Dispositions

Changed artifact content or scope requires draft, fresh independent review, and renewed acceptance; unchanged-content reassessment uses to-review. Ordinary dependency waits retain phase with Run wait and readiness no-go; pending approval alone uses issue and need-ok when other gates pass. Artifacts can also be transitioned to universal dispositions: superseded (replaced by a newer artifact), retired (deprecated or obsolete), or abandoned (cancelled with audit rationale).

When retries or infrastructure boundaries are hit, AceLM records precise failure classifications: rejected (exhausted review retries), verify-err (exhausted verification retries), exec-err (operation failure), gate-fail (unrecoverable gate or exhausted authorized gate-remediation budget), interrupt (SIGINT/interruption), or crashed (unclean worker death). Every label fits a ten-character column, so the terminal shows it in full.

Early access

Your standards decide what each gate requires.

Bring the checks your team already trusts. We will show you how they become gates on a real project of yours.

Request early access See AceLM for teams