Exit condition schema

An exit condition is the technical unit of "done" in spec-driven development. Each condition carries the fields below. See Exit conditions and Definition of Done for the conceptual model.

Fields

Most fields describe the condition; a few determine its auditor. An exit condition’s auditor is expressed in one of four ways: a built-in introspective check id; an inline introspective auditor block; a provisioned check: harness:<capability>; or a delegated autonomy: attested. The three auditor kinds follow from that choice.

id

A stable identifier for the condition (for example, OPS-COMPILES, SEC-SECRETS). Used in status output, receipts, and waivers.

summary

A short human-readable statement of what the condition requires.

dod_type

The Definition-of-Done type the condition belongs to (for example, Functional, Reliability, Repository Hygiene). Required on every condition. Determines the tier (Product, Project, or Process) the condition rolls up into.

kind

Whether the condition is a completion or a prohibition (default completion). A completion condition must become true and starts open. A prohibition condition must never become true; an unaudited prohibition resolves red ("unenforced prohibition — needs a check"), and it cannot be closed by a human sign-off, because sign-offs only turn open green. See Prohibition conditions.

provenance

Where the condition comes from, which determines whether a developer can change it:

Value Meaning

akka-intrinsic

Guaranteed by the platform. The condition activates directly to green with the reason platform-guaranteed, is always applicable, and is never authored by a developer. Annotated [akka] on the manifest.

recommended-default

From the default library; on by default, may be marked inapplicable.

corporate

Inherited from the organization policy; locked according to its governance level.

developer

Added by the developer for this feature.
governance_level

For corporate conditions, the level that controls developer configurability (see Policies): always-apply, never-apply, on-but-dev-configurable, or off-but-dev-configurable.

pass

The binary predicate that defines success — a check over an observable surface that evaluates to true or false. A condition whose success cannot be expressed as a binary predicate is not yet an exit condition.

check

Names the auditor when it is not written inline. A built-in introspective check is named by id (maven-compile, git-secrets, content-vale, and so on). A provisioned harness auditor is named harness:<capability> and is satisfied by the matching /harnesses asset recorded in .akka/harnesses.lock. See Auditor kinds.

auditor

An inline introspective auditor, used when a project introduces an ecosystem the built-in checks do not cover. It delegates to a tool the ecosystem already provides and is green when that tool exits zero, red otherwise. The sub-schema has two fields:

Field Meaning

run

The command that decides the invariant, given as an argument array (for example ["npm", "run", "-s", "typecheck"] or ["mvn", "-q", "compile"]). A zero exit code is green.

applies_to

Where the command runs. requirement names the environment it needs (node, maven, git, and so on); module names the sub-project it runs in, relative to the repository root (for example web).

The pass predicate states the invariant; the auditor block is the check that decides it:

pass: "tsc == 0"          # the invariant, on the condition
auditor:                  # the inline introspective check that decides it
  run: ["npm", "run", "-s", "typecheck"]
  applies_to:
    requirement: node
    module: web

A developer condition can be materialized from /akka:specify feedback and carry its own inline auditor. A non-corporate inline auditor stays open until you approve its exact command on first run. See Auditors.

autonomy

How the condition closes: auto (the auditor closes it), human-signoff (a person closes it), or attested (a delegated check, closed by a recorded attestation). An attested condition stays open with reason needs-user-action until its attestation exists, then green.

state

The condition’s current status. One of open, green, or red. See Exit condition states for the meaning of each and the transitions between them.

reason

Set only when state is open. Names why the auditor has not decided the condition. One of needs-user-action (a person working on this project can move the condition forward) or blocked-outside-project (a required tool is missing, or the policy has no auditor mapped to the condition). See Exit condition states.

applicable

Whether the condition applies to this project. true by default. When false, the condition stays visible on the manifest with an applicable = false marker and does not count for the ship verdict. Set through /akka:scope or by a policy strike on a recommended-default condition.

ship_tier

The ship target the condition is verified for: author, review, or release. Set by the library, the org policy, or (when omitted) defaulted by /akka:conform based on kind and autonomy — prohibitions default to author, attested conditions default to release, everything else defaults to review. Individual developers do not set this field; it is a policy-level choice. See Ship tiers.

waiver

An optional modifier attached to a still-active condition. It does not change the state — the auditor still runs and the state still shows what it decided — but a waiver permits shipping despite red or open. Waivers record the accepter, the reason, and an expiration; on expiry the waiver is removed and the condition returns to blocking. Waivers are policy-gated; the organization may forbid them or require approval.

verified_at

Set when the auditor last returned green. Used by /akka:ship to detect drift: if any file in the project (outside .akka/, .git/, build outputs, and paths matched by .gitignore) has been modified after verified_at, the condition is marked stale and the ship refuses until the auditor re-runs. See Exit condition states for the drift model.

struck

Whether a recommended-default condition has been struck as inapplicable. Strikes are bounded (an organization-locked condition cannot be struck) and recorded in the conformance receipt. A struck condition has applicable = false.

Related