diff --git a/history/2026-08-28-security-layer-model-v0.4-review.md b/history/2026-08-28-security-layer-model-v0.4-review.md
new file mode 100644
index 0000000..e2f3e39
--- /dev/null
+++ b/history/2026-08-28-security-layer-model-v0.4-review.md
@@ -0,0 +1,120 @@
+# 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.