audit-core/history/2026-08-28-approval-evidence-assent.md

Approval evidence — audit-core's assent (AUDIT-IN-0001)

Date: 2026-08-28 Intake: AUDIT-IN-0001 Requested by: gate-house Standard: net-kingdom/canon/standards/security-layer-model_v0.3.md §9.4 (proposed) Outcome: assent, with two corrections to the rationale and one condition on the emitting engine.

---

What was asked

gate-house proposed that audit-core own the evidence half of approvals — issuance, use, supersession, and revocation, emitted as audit events — while a new approval-engine owns the operative state: the durable object, atomic supersession, single consumption, and revocation without holder cooperation.

The two reasons given for keeping the operative state out of audit-core are correct and audit-core does not contest them:

• operational custody is append-only Postgres by design (docs/audit-backend-contract.md), and an approval needs mutable current-state semantics with compare-and-swap supersession; and
• access-engine must read approval state in-path, so putting it behind the audit fabric would make an audit outage an authorization outage.

The answer

Assent. The split is the right one. Approval evidence is a record of what happened, not the authoritative answer to whether an approval is still valid, and that distinction is what keeps this inside INTENT.md's "policy decision making" exclusion rather than a violation of it.

Two corrections and one condition follow. None of them reject the split; they state what audit-core actually delivers so the standard does not rest on a stronger claim than the implementation supports.

---

Correction 1 — principle 6 is an aspiration, and the delivered bound is weaker

gate-house's rationale cites INTENT.md principle 6 — signed or hash-chained manifests so operators can later prove whether a record set was changed, omitted, or truncated — as already being what authenticated approval entries need forensically.

docs/integrity.md is more careful than principle 6, and it is the contract that ships. In its own words: a chain inside the same database detects a rewritten payload_hash only if the attacker does not also recompute the suffix — and a database owner can. Tamper evidence against that class of attacker requires the external chain-head attestation, and even with it:

It still does not mean WORM, object lock, or ITC-CAP data.archive.

tamper_evidence=True is conditional on two preconditions being live (verify failing on a rewritten row, and verify-against-attestation reporting a missing cited head as a break). It is not a property of the store at rest.

So: approval events get exactly the guarantee every other audit source gets — no more. That guarantee is real and it is useful, but it is bounded by the attestation being taken and stored outside platform-pg. If §9.4 needs a stronger property for approvals specifically — WORM, object lock, or a transparency log — that is an engine gap to declare under §5.3, not a setting audit-core can turn on.

Correction 2 — the chain proves alteration, not omission at source

This is the more consequential one, and it is the reason for the condition below.

The hash chain proves that accepted records were not altered or truncated. It cannot prove anything about an approval event that was never emitted. For an approval object the omission case is not a corner: a suppressed revocation is precisely the event an attacker most wants missing, and it leaves the chain perfectly intact. Verify would report intact.

Principle 6 claims audit-core can prove a record set was "omitted". Against a compromised or buggy sender, it cannot, and neither can any append-only archive. Completeness at the boundary is the emitter's property, not the archive's.

The condition — approval-engine owns emission atomicity

audit-core accepts the evidence half on the condition that approval-engine guarantees emission is atomic with the state change — a transactional outbox or equivalent, such that an approval cannot be issued, consumed, superseded, or revoked without the corresponding event being durably queued in the same transaction.

Without that, the evidence half is silently incomplete and audit-core has no mechanism to detect the gap. audit-core will report what it received; it will not imply that what it received is everything that happened.

This is a requirement on approval-engine, not a task audit-core can discharge on its behalf. It should appear in approval-engine's contract before the evidence half is treated as load-bearing.

Boundary audit-core states explicitly

approval-engine will be registered as a distinct source, with its own sender registration, tenancy mapping, retention profile, and secret_policy under the existing onboarding rules (principle 4: a source is onboarded when ownership, retention, access, export, and evidence policy are declared and validated — not when events start arriving).

audit-core will not expose an approval-validity query. No read surface will answer "is this approval still valid". Records, yes; a verdict, never. Such a surface would be deciding early under §6.1, and a consumer branching on an audit-core answer would be routing an authorization decision through the audit fabric — the exact coupling §9.4 exists to prevent. Callers who need current state ask approval-engine.

The four event classes accepted as a distinct source: issuance, use, supersession, revocation, per §9.4.

Conformance note raised in passing

§11 requires that every repository in §4 declare its layer in INTENT.md. audit-core declares none today. It is corrected in the same change: audit-core is Engine layer — it exposes a deterministic API contract and holds operational custody — and it is explicitly not a decision point, per the boundary stated above.

---

What changed in this repository

File	Change
INTENT.md	layer declared; approval evidence named as a source; principle 6 cross-referenced to the docs/integrity.md bound
intakes/intakes.md	AUDIT-IN-0001 closed, outcome assent-with-conditions
history/	this record

Reply sent to gate-house on the State Hub inbox thread.