Auditor kinds
Every auditor is one of three kinds. The kind is set by where the check can run, and each kind maps to the states in Exit condition states.
The three kinds
| Kind | Where the check runs | Resolves as |
|---|---|---|
Introspective |
The project’s own tree: a compiler, a test runner, a linter, or a prose linter over |
|
Provisioned |
A generated harness asset wired to an external system: a CI workflow, a scanner configuration, a supply-chain step, or a content package. |
|
Delegated |
An external system only, or a judgment the engine cannot make. |
|
Introspective
An introspective auditor inspects the project’s own tree and reads a tool’s result. Two forms are introspective:
-
Built-in. Akka ships a set of introspective checks a condition binds by id in its
checkfield:maven-compile,maven-test,maven-deps,git-clean,git-secrets,no-build-output,deps-pinned,content-vale,file-adr,ci-green. -
Inline authored. A project — or the assistant, on your behalf — authors a command auditor
{run, applies_to}under the condition’sauditorfield, for an ecosystem the built-ins do not cover.
tsc --noEmit fails on an invented React hook; mvn compile fails on an invented Akka method; vale fails on a banned phrase. The verdict is local and immediate: green or red. When a required tool (for example, Vale) is missing on the developer’s machine, the auditor resolves open with reason blocked-outside-project and states which tool is missing.
An inline auditor that is not corporate-authored does not run on sight. It resolves open with reason needs-user-action ("approve the exact command shown below") until you approve its exact command. The approval is recorded as a hash of that command, so a changed command re-prompts. Built-in and corporate-authored checks run without a separate approval.
Provisioned
A provisioned auditor verifies a generated harness asset. Its condition’s check is harness:<capability>, and the auditor confirms the asset recorded in .akka/harnesses.lock is present and enforcing, and that its policy version is current. It resolves green ("`<capability>` harness active") when the asset is present and current, and red when the asset is missing or the lock is stale because the policy moved. A provisioned-harness gap is closed the way a coverage gap is: generate the asset and its auditor together, then approve it at the exit-condition level, where it also passes the adequacy review. See /akka:harnesses.
Delegated
A delegated auditor covers a check that runs only in an external system, or that needs a judgment the engine does not make. Its condition sets autonomy: attested. It resolves open with reason needs-user-action (the payload names the receipt required — a run URL, a signed record, a ticket number) until a recorded attestation exists, and then it resolves green. It never passes on its own: a delegated check that is never attested stays open rather than turning into a false green, so the gap stays visible and /akka:ship refuses.