View project on GitHub

ADR-052: Verification Tiers and Auditability Evidence for Autonomous Work

Context

ADR-030 introduced the domain-plugin seam and named three verification tiers: VERIFIED, SCORED, and CONSENSUS. ADR-050 then defined the reusable Autonomous Trunk Skeleton, and ADR-051 planned the experience layer needed for contributors, operators, and agent fleets. Those decisions make unsorry reusable, but they leave a critical policy question under-specified: what level of verification is enough to let autonomous work merge, and what evidence must be retained so a project remains auditable?

The answer differs by domain. Lean proofs have a deterministic checker: the kernel and Gate A can decide correctness for the merged artifact, so one valid result is enough. Other domains are weaker. A test suite may be deterministic but incomplete. A benchmark can rank candidates without proving correctness. A security scanner may produce findings rather than an accept/reject theorem. A human approval gate can manage risk, but it is not a machine proof.

If the skeleton lets every adapter call itself “verified”, autonomous merge becomes unsafe. If it requires Lean-grade proof for every domain, the skeleton cannot generalize. The system needs a verifier policy that states which tier a domain is using, which merge behavior that tier permits, and which audit evidence must be produced.

This is also where compliance support belongs natively. The repository and workflows do not make the organization ISO/IEC 27001 compliant by themselves. However, the system can produce structured evidence for an ISMS owner: traceable changes, verifier outcomes, approval records, settings snapshots, exceptions, and risk decisions.

WH(Y) Decision Statement

In the context of a reusable autonomous trunk system where different domains will have different verifier strength, and where operators need audit-ready evidence without pretending that the repository itself is a certified ISMS,

facing the risk that weak verifiers could be mislabeled as deterministic truth or that audit evidence remains ad hoc across adapters,

we decided for making verification tier an explicit adapter policy and merge-control input: every adapter must declare its tier, verifier command, acceptance semantics, evidence artifacts, replay/reproduction requirements, and allowed merge mode; VERIFIED domains may auto-merge after one accepted deterministic result, SCORED domains may select and retain best candidates under project policy, CONSENSUS domains require independent redundant results or quorum, and APPROVAL domains require a human or organizational gate before merge; all tiers must emit structured audit evidence, including verifier result, provenance, toolchain/version context, risk exceptions, and approval or consensus records where applicable,

and neglected treating all green CI as equivalent (rejected because a test suite, benchmark, scanner, and theorem kernel have different trust meaning), requiring Lean-style proof for every domain (rejected because it would block useful non-proof workloads), and claiming standards compliance from evidence generation alone (rejected because compliance belongs to an organization’s ISMS, scope, risk treatment, review, and audit process),

to achieve a skeleton that can safely generalize beyond Lean while keeping merge decisions, verifier strength, and audit evidence explicit,

accepting that lower tiers need more friction and less automation than Lean’s deterministic path, that adapter authors must maintain their evidence schemas as seriously as their verifier code, and that auditability creates records useful for compliance without certifying the project by itself.

Verification Tiers

APPROVAL is added explicitly rather than hidden inside CONSENSUS because some domains are acceptable only through human risk acceptance, regulatory sign-off, or maintainer judgment.

Auditability Requirements

Every tier must produce evidence that can be preserved with the contribution:

• work-unit id and version,
• agent or contributor identity,
• verifier tier,
• verifier command or approval workflow,
• toolchain / dependency / model version context,
• result status and timestamps,
• artifact hashes,
• logs or summaries sufficient for later review,
• risk exceptions or accepted deviations,
• approval identity where humans are involved,
• consensus quorum details where redundant verification is used.

This evidence is not a compliance certificate. It is an auditable record that an ISMS, security program, or project governance process can consume.

Consequences

• Positive. New adapters cannot silently inherit Lean’s auto-merge trust level. They must state their verifier strength and evidence obligations.
• Positive. Compliance support is built into the work lifecycle: evidence is generated at the same time as verification, not reconstructed later.
• Positive. Operators can compare domains honestly: deterministic proof, test-based confidence, scored optimization, redundant consensus, or human risk acceptance.
• Negative. Some useful domains will not be eligible for full autonomous merge. That is intentional; the tier tells the truth about the risk.
• Negative. Evidence schemas add maintenance overhead and must evolve when verifier behavior changes.

Rollout

1. Add the tier policy to adapter documentation and generated status.
2. Define a shared verifier evidence schema in SPEC-052-A.
3. Mark the Lean adapter as VERIFIED and map current Gate A evidence into the schema.
4. Require future non-Lean pilots from ADR-050 to choose a tier before they can auto-merge.
5. Add evidence-pack hooks to ADR-051’s experience layer.

References

Status History