STRUCTURED PROGRESSION

The development lifecycle, made visible.

AceLM is being designed to connect each stage of development to project records, review decisions, and verification evidence.

STATE MACHINE & GRADUATION MODEL

Artifact lifecycle flowchart.

Specifications, backlog items, and plans follow explicit, observable state machines with kickback recovery loops, multi-artifact graduation, and universal exit rules.

SVG Vector Lifecycle State Machine & Graduation Flow

Open Full SVG

AceLM Lifecycle State Machine and Graduation Flowchart

Specification

Spec

draft → to-review → reviewing → reviewed → accepted → implementing → implemented

Kickback & Rework:

Can be kicked back from reviewing, reviewed, or implementing states to draft or to-review for scope refinement.

Graduation Target:

An accepted or implemented spec graduates to one or more Backlog Items or one or more Plans / Plan Sets.

Exit States:

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

Backlog Item

Backlog

Origins & Sources:

Can originate from a Spec, from a Plan (e.g. bug or gap found during execution/verifying), or Ex Novo (direct triage).

draft → to-review → reviewing → reviewed → ready → graduating → graduated → done

Kickback & Rework:

Can be kicked back during triage or review back to draft or to-review.

Graduation Target:

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 Set

Plan

Origins & Sources:

Originates from a Spec, from a Backlog Item, or as a sub-plan of a Plan Set.

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

Kickback & Rework:

Can be kicked back during review or if verification fails back to draft or accepted.

Defect Discovery Loop:

Discovering bugs during execution or verification creates new Backlog Items.

Exit States:

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

Universal Lifecycle Rules Across All Artifacts

Every active entity (Spec, Backlog Item, Plan, or Plan Set) at any point in its lifecycle can be kicked back to an earlier stage for rework, or transitioned directly to one of three universal terminal states: superseded (replaced by a newer artifact), retired (deprecated or obsolete), or abandoned (cancelled with audit notes).

DELIVERY EXECUTION STAGES

The 6-stage verification pipeline.

From specification to release-readiness gating, AceLM tracks evidence across each delivery milestone.

Specify Record requirements and scope

Plan Map reviewable tasks

Review Authorize execution

Build Execute scoped changes

Verify Record check results

Check release readiness Evaluate findings and gates

Planned security checks, regression testing, and release reviews connect delivery decisions to recorded evidence.

1. Specify

Record requirements, scope, constraints, and acceptance criteria.

2. Plan

Break work into reviewable tasks and identify dependencies.

3. Review

Evaluate the approach and record the required authorization before execution.

4. Build

Execute scoped changes in separate Git worktrees and inspect the resulting diffs.

5. Verify

Run project-defined regression tests, builds, linting, type checks, and configured security checks. Record the results and evaluated revision.

6. Check release readiness

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

VERIFICATION SCOPE

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.

Explore enterprise direction