diff --git a/canon/standards/security-layer-model_v0.4.md b/canon/standards/security-layer-model_v0.4.md
index 00da5c6..7fe6e0a 100644
--- a/canon/standards/security-layer-model_v0.4.md
+++ b/canon/standards/security-layer-model_v0.4.md
@@ -414,9 +414,21 @@ Conformance has three states, and the distinction is the point:
 | **Declared gap** | a §5.3 contact with owner, blocker, and review date — tracked non-conformance |
 | **Undeclared violation** | anything else — a finding |
 
+**Who must declare.** A repository the estate authors declares its layer in its
+own `INTENT.md`, in its own voice. For a component the estate catalogues but does
+not author — third-party or vendored, such as `OpenBao` — the §4 catalog row
+**is** the declaration, and no `INTENT.md` obligation attaches. A rule that
+assigns an obligation the holder cannot discharge is the §9.1 defect applied to
+conformance rather than capability.
+
+A layer stated *about* a repository by another repository is not a declaration.
+Review notes, catalog rows, and correspondence record an intent to adopt; only
+the repository's own file, in its own voice, conforms.
+
 Mechanically checkable:
 
-- every repository in §4 declares its layer in `INTENT.md`;
+- every estate-authored repository in §4 declares its layer in its own
+  `INTENT.md`;
 - every direct Tooling client in a Staff repository maps to a declared §5.1,
   §5.2, or §5.3 entry;
 - no repository other than `access-engine` exposes an authorization decision
@@ -493,6 +505,16 @@ Adoption for a repository means its `INTENT.md` declares its layer, its
 ownership claims fall inside that layer, its Tooling contacts are declared under
 §5, and any shared boundary has been assented to by the other side.
 
+**Adoption status as of 2026-08-28: seven of fifteen** estate-authored §4
+repositories have declared in their own voice — `gate-house`, `flex-auth`,
+`kings-guard`, `ops-warden`, `audit-core`, `approval-engine`, `maturity-engine`.
+The remaining eight — `info-tech-canon`, `net-kingdom`, `key-cape`,
+`user-engine`, `tenant-engine`, `zone-engine`, `secrets-engine`, `ops-mason`,
+`whitehat-security` — carry a layering review note authored by `gate-house` and
+have not answered it. Those notes state a layer but do not constitute a
+declaration, and this standard does not claim estate-wide adoption on their
+basis. Declaration requests are open as intakes in each.
+
 ## 15. Change log
 
 v0.1 → v0.2:
@@ -524,6 +546,11 @@ v0.2 → v0.3:
    names the engine it acts through.
 4. §13 register updated: the approval hole is assigned, two new entries added.
 
+Amended in place while `proposed`, 2026-08-28: §11 gained the who-must-declare
+rule after a conformance sweep found the standard required an `INTENT.md`
+declaration from `OpenBao`, which the estate does not author; and §14 gained the
+honest adoption count.
+
 v0.3 → v0.4:
 
 1. **§4 catalog gained `audit-core`** as an Engine, on its own declaration. v0.3