Enforced mode

Enforced mode treats "done" as something the system checks, not a judgment call. It separates "done" into three layers, each with a distinct owner:

The layers roll up in the other direction: an auditor produces a verdict, verdicts set each exit condition’s status, and those aggregate into a Definition-of-Done type status. A developer sees progress in business language ("Reliability: covered", "Functional: 2 of 3 met") while the machine works in precise conditions underneath.

Every exit condition resolves to a single boolean pass — there is no "mostly done". A requirement that cannot be expressed as a binary predicate over an observable surface is not yet an exit condition; it is a Definition of Done item still waiting to be made precise.

Every condition also carries a provenance that determines whether a developer can change it: akka-intrinsic (platform-guaranteed; the trivial auditor returns green immediately, always applicable, annotated [akka]), recommended-default (from the default library, may be marked inapplicable), corporate (the organization policy, locked), and developer (added for this feature). Done is layered and additive — the organization defines mandatory controls and developers add to them, tightening but never loosening. See the exit condition schema for the full field set.

Every exit condition is tagged with a fixed, versioned Definition-of-Done type. Types are the scaffold the tooling walks to infer which conditions a feature needs, and the buckets progress rolls up into. Each is pinned to a distinct Akka observable surface. They are organized into three tiers — the "three P’s".

Product — does the software work? (developer- and customer-led)

Project — is the codebase healthy and standards-compliant? (heavily organization-authored)

Process — did the AI build stay honest and efficient? (organization policy)

The core types are closed and versioned. Organizations extend "done" by adding conditions within a type, not by inventing new types.

Akka ships a browsable exit condition catalog of candidate conditions for every type. Browse it for inspiration, or point your AI coding assistant at it to help identify the conditions that make sense for your project.

Enforced mode is two human touchpoints book-ending a silent machine phase — not a gate at every step.

An auditor is the check bound to an exit condition. The engine resolves each condition’s auditor into one of three kinds, set by where the check can run:

The built-in introspective set is small, and there is no large closed catalogue of checks you pick from by id. Beyond the built-ins, auditors are authored per ecosystem (inline commands), provisioned as harness assets, or delegated via attestation. Each auditor declares what it needs to run (a git tree, Maven, a live service); the tooling checks availability and resolves the condition accordingly rather than blindly failing. See Auditor kinds for the full model.

Every condition carries a state and a set of properties. See Exit condition states for the full model. The three states:

Alongside the state, three properties describe the condition itself: provenance (who guarantees it — akka-intrinsic, recommended-default, corporate, or developer), waiver (a time-bound record permitting shipping despite red or open), and applicable (whether the condition applies to this project). All three appear as annotations on the manifest and are described in the states page.

/akka:ship <review|release> runs the auditors for every applicable exit condition in scope for the target and, if they pass, runs the ship steps the organization declared for that target. Akka provides the mechanism; the organization writes what its ship steps do — push a branch, open a pull request, deploy and activate, publish an artifact, or a sequence of these. There is no fixed menu of ship profiles.

/akka:ship requires an explicit target — review or release — and refuses when called without one. The target names which set of auditors runs:

Author-time is a precondition, not a ship target. Every ship, review or release, requires every applicable author-tier condition to be green or waiver-covered. See Ship tiers.

The author tier is evaluated first, on its own. In Enforced mode a ship that fails it stops there. The review-tier and release-tier auditors do not run, so you do not wait on a scan whose result cannot change the outcome. The verdict you get back covers the author tier only. The higher tiers were skipped rather than failed, so the output does not report a status for them.

One rule holds regardless of target: the ship steps run only when every in-scope condition is green and not stale, or covered by an effective waiver.

When ship completes, Akka writes a conformance receipt — which conditions were green, which auditors ran, which stayed open and why, and any waivers in effect. The receipt is what makes an AI-built handoff auditable: the downstream owner sees exactly what was verified and what remains. In Enforced mode, a successful ship also offers to shut down the local services the build started, closing the lifecycle that /akka:setup opened.

In Enforced mode an organization defines a mandatory baseline of exit conditions and definitions of done — security, compliance, repository hygiene, its "way of working" — that Akka enforces and developers can tighten but never loosen. Each condition is assigned a governance level (always-apply, never-apply, on-but-dev-configurable, off-but-dev-configurable).

Every Specify command remains available — Enforced mode changes the ship gate, not the command set (see /akka:mode). In practice you drive an Enforced build through /akka:specify as the re-entrant engine, and use the governance commands to inspect progress and release: