The adequacy review

For each auditor the review attempts to construct an input where the check passes while its invariant is false. If one can be constructed, the check is inadequate and must be tightened or clarified. Asking "is this adequate?" invites a rubber stamp; asking "how does this pass while being wrong?" does not.

The review runs on every feedback turn, whenever a check is authored, and always before ship.

The review is recorded as an artifact at .akka/adequacy/review.json, keyed to a state signature — a hash taken over each active, auditor-backed condition’s id, invariant, pass predicate, and auditor spec (the built-in check name, or the JSON of an inline auditor). It deliberately does not include the code: adequacy is a property of (requirement, auditor), not of the code content, so a comment-only edit does not force a re-review. A newly-appeared surface is the coverage gate's concern instead.

The artifact’s covered set must include every active auditor-backed condition, excluding the two meta gates. A condition missing from the covered set, or a signature that no longer matches the current conditions, leaves the gate OPEN until the review re-runs. When a project has no active auditors there is nothing to review and the gate is GREEN.

Because the signature is derived from the checks, feedback that changes a check stales the review and forces it to re-run — an auditor can never quietly drift out of adequacy. The review is submitted with the akka_ec_adequacy_submit tool.

The engine guarantees the review occurred and covered every check; it cannot guarantee it was deep. Depth is backstopped by the adversarial framing and your in-context veto when a new or changed check is surfaced for approval.