# AceLM product positioning

## Core message

**Agentic development. Enterprise discipline.**

**Bring professional engineering discipline to coding agents.**

AceLM gives experienced developers the structure and control to guide coding agents through complex software delivery. Its purpose spans requirements, architecture, design, implementation, independent review, functional validation, tests, regression checks, documented decisions, collaboration, and delivery oversight.

AceLM is in development. It grows from agent-workflows, created to help developers and their teams define work clearly, check that it meets specifications, and maintain quality control. The existing assessment foundation and the intended AceLM environment are different stages of that work; marketing must identify which capabilities are available and which remain product direction.

## The problem it addresses

A coding agent can produce a convincing implementation or progress report while leaving requirements unmet, tests incomplete, architectural assumptions undocumented, or regressions undetected. On a complex project, those gaps accumulate across tasks, agents, branches, and sessions.

Experienced developers need to inspect both the software and the process that produced it: the accepted scope, the reasoning behind design choices, the observed behavior, the verification evidence, the outstanding work, and the resources consumed. A reported success or passing local test is insufficient evidence for all of those questions.

## Five connected pillars

| Pillar | Developer value | Supporting design |
| --- | --- | --- |
| Engineering rigor throughout development | Define the intended system and hold work to its requirements, architecture, design, and acceptance criteria | Revision-bound specifications and plans; independent review; controlled scope and authorization |
| Evidence for work and quality | Inspect proof of work, requirements coverage, functionality, tests, and regression checks | Separate E/V obligations; independent verification; final-revision evidence; unresolved and untested work remains visible |
| Documented reasoning and decisions | Understand approaches, alternatives, rationale, architecture, design, approvals, and changes | Versioned project records linked to requirements, plans, revisions, and evidence |
| Continuity and collaboration | Let a human or agent take over or co-develop with clear intent, context, ownership, and outstanding obligations | Repository-carried records; explicit handoffs; isolated workspaces; preserved checkpoints and recovery history |
| Visibility and configurable control | Track progress, tokens, costs, and time within and across projects; tune enforcement, rigor, and auditing | Product direction for attributed resource reporting and explicit policy profiles; scoped authority and bounded retries |

These pillars describe intended product value. Detailed behavior and open lifecycle decisions remain governed by [the transition catalog](acelm-artifact-transition-catalog.md) and [terminal UX](acelm-status-and-terminal-ux.md). [Engineering rigor and delivery controls](acelm-engineering-rigor.md) defines the messaging and evidence boundaries for the broader direction.

## Experienced developers remain at the helm

People define requirements, evaluate architecture and tradeoffs, select the appropriate rigor, grant authority, resolve ambiguity, and decide what can ship. AceLM is designed to make those decisions explicit and to carry them into agent work. It supports experienced engineering judgment; its public claims must not suggest that judgment becomes unnecessary.

## Mechanisms that make the message concrete

- Versioned specifications, plans, decisions, and verification records that travel with Git; local indexes support queries without becoming portable transition authority.
- Separate authoring, review, execution, and verification contexts so an agent's own account is not its only validation.
- Execution items (`E-*`) paired with observable verification obligations (`V-*`), including functional, integration, and regression evidence appropriate to the work.
- Isolated worktrees, explicit ownership, preserved checkpoints, and bounded recovery rather than blind replay.
- Assessment across the 31 engineering lenses, with findings carried through reviewed, accepted, executed, and independently verified remediation.
- Candidate-bound release evidence and separate human release authority.
- Planned progress and resource visibility across projects, with policy-controlled rigor and inspectable changes to enforcement.

Lifecycle gates are one mechanism within this broader engineering system. The headline must not reduce the product to task completion, test automation, release approval, or conversation memory.

## Claims and evidence

Use concrete descriptions of what is defined, checked, recorded, enforced, or still pending. Demonstrate value with real project records and reproducible checks. Illustrative workspace examples must remain labeled concept previews.

Do not promise defect-free software, exhaustive test coverage, automatic regulatory certification, or fully autonomous enterprise development. Avoid unsupported explanations about model training datasets and unverified claims that competing tools lack these capabilities. Stronger assurance must be supported by inspectable controls and evidence; an agent's statement alone does not establish it.

New cost/time reporting and configurable enforcement claims are product direction unless backed by current implementation evidence. Configuration must not silently waive mandatory independence, authority, or completion gates. Changes in required scope or policy remain recorded and subject to the applicable review and acceptance rules.