audit-core/history/2026-08-28-security-layer-model-v0.4-review.md

# Security layer model v0.4 — audit-core's review

**Date:** 2026-08-28
**Standard:** `net-kingdom/canon/standards/security-layer-model_v0.4.md` (proposed)
**Reviewed against:** v0.3, and audit-core's `AUDIT-IN-0001` assent
**Outcome:** assent to v0.4. Three findings, none blocking; one is an amendment
audit-core recommends before v0.4 leaves `proposed`.

---

## What gate-house did with audit-core's corrections

All three landed, and two were generalized further than audit-core asked:

| audit-core raised | v0.4 |
| --- | --- |
| principle 6 overstates the delivered bound | §9.4 rewritten to cite `docs/integrity.md`; `tamper_evidence` stated as conditional on live preconditions |
| the chain proves alteration, not omission at source | **§9.6 added** — promoted from an audit-core caveat to an estate-wide doctrine constraint |
| emission atomicity must be `approval-engine`'s obligation | §9.4 gained it as a MUST, cited as a condition of the assent |
| no approval-validity query | §9.4 gained the prohibition |
| audit-core declares no layer (§11) | catalogued in §4 as Engine, on audit-core's own declaration |

§9.6 is the better piece of work. audit-core raised omission as a fact about
approvals; gate-house correctly identified it as a fact about every claim the
estate rests on audit, and stated the sound and unsound forms of the claim.
Consequence 2 — *the most valuable event to suppress is the negative one* — is a
sharper statement of the problem than the one audit-core sent.

The two new §13 gaps are honestly declared, including the one audit-core created
by pointing at the shipped bound: whether approvals warrant custody stronger
than every other source is left **unassigned** rather than assumed onto
audit-core. That is the right handling.

---

## Finding 1 — §9.4's MUST is sound only if the outbox is local, and it does not say so

This is the amendment audit-core recommends.

§9.4 now says an approval MUST NOT be issued, consumed, superseded, or revoked
without the event being durably queued **in the same transaction** —
*transactional outbox or equivalent*.

Read literally, that decides a question `GH-IN-0001` T03 raised as open: if the
event cannot be queued, the transaction rolls back and the state change does not
happen. Revocation fails closed.

**With a genuine transactional outbox that is correct and safe**, because the
outbox table lives in `approval-engine`'s own database. audit-core being
unavailable does not block a revocation; the row is written locally and drains
later. Fail-closed then triggers only when `approval-engine`'s own store is
down, in which case the revocation could not have been recorded anyway. The
coupling audit-core worried about in T03 does not exist.

**The words "or equivalent" are where it breaks.** An implementer reading that
phrase may satisfy the MUST with a synchronous emit to audit-core inside the
transaction. That also makes emission atomic with the state change, and it makes
an audit-core outage into an inability to revoke — the operation least tolerable
to block during an incident, and a coupling §9.4's own opening argument rejects
for reads.

**Recommended amendment:** state that the durable queue MUST be in
`approval-engine`'s own transactional store, and that no synchronous dependency
on `audit-core` may sit inside the state-change transaction. One sentence. It
turns fail-closed from an accident into a property, and it closes the only
reading under which the new MUST contradicts §9.4's own premise.

With that sentence, `GH-IN-0001` T03 is answered rather than open.

## Finding 2 — §11's new who-must-declare rule is not mechanically checkable

§11 is titled and framed as mechanically checkable, and the new rule is right on
the merits: a layer stated *about* a repository by another repository is not a
declaration, and a component the estate does not author cannot be held to an
`INTENT.md` obligation. The `OpenBao` case that prompted it is the §9.1 defect
applied to conformance, exactly as stated.

But the distinction it introduces cannot be checked by machine as written. Both
a declaration and a transcribed review are prose in `INTENT.md`. Nothing
separates them for a checker.

The ambiguity is live, not hypothetical. `flex-auth`'s declaration sits under
the heading *"NetKingdom layering review — 2026-08-28. This repository's role was
reviewed against..."* and reads as gate-house's finding transcribed into
flex-auth's file. It does go on to state the layer in flex-auth's own voice and
flex-auth assented in `FLEX-DEC-2026-001`, so audit-core reads it as conforming
— but a checker cannot, and neither can a reader who has not followed the
decision trail.

**Recommended:** give declaration a canonical machine-readable form — a `layer:`
key in `INTENT.md` frontmatter, or a fixed first-line form — so §11's
checkability claim is true of the new rule and not only of the old one. Without
it, §11 asserts a property it cannot deliver, which is the shape of defect this
standard has twice corrected elsewhere.

## Finding 3 — §14's adoption arithmetic is wrong

§14 states **"seven of fifteen"** estate-authored §4 repositories have declared,
and refers to **"the remaining eight"** — then enumerates nine:
`info-tech-canon`, `net-kingdom`, `key-cape`, `user-engine`, `tenant-engine`,
`zone-engine`, `secrets-engine`, `ops-mason`, `whitehat-security`.

The §4 catalog carries 17 rows. One (`OpenBao`) is not estate-authored, leaving
**16**. Seven declared plus nine undeclared is 16, consistent. So the count
should read **seven of sixteen**, and **the remaining nine**.

Minor, but §14 is the adoption ledger and gate-house added the count
specifically so the standard would not overclaim adoption. An off-by-one in the
honest-count paragraph is worth fixing before it is cited.

---

## Position

audit-core assents to v0.4. Its own conditions are carried faithfully, §9.6
improves on what was raised, and the new gaps are declared rather than assumed.
Findings 2 and 3 are corrections to the standard's own conformance apparatus,
not to the layer model. Finding 1 is the one audit-core would like resolved
before v0.4 is accepted, because it determines whether the emission MUST is safe
or merely strict.