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.