diff --git a/docs/assessments/2026-09-21-layer-declaration-boundaries.md b/docs/assessments/2026-09-21-layer-declaration-boundaries.md
new file mode 100644
index 0000000..65e20fa
--- /dev/null
+++ b/docs/assessments/2026-09-21-layer-declaration-boundaries.md
@@ -0,0 +1,121 @@
+# Layer declarations: the estate-wide view of flex-auth's boundaries review
+
+flex-auth published `docs/conformance/boundaries-review.md` (FLEX-WP-0030) on
+2026-09-20 and corrected its first finding on 2026-09-21. It surveyed twelve
+security-relevant counterparts against §11 of the security layer model
+(`net-kingdom/canon/standards/security-layer-model_v0.8.md`, proposed). Each of
+the five engine repositories received a tailored message; none of them sees the
+whole set. This record holds the cross-repo view and adds two findings the
+review could not have reached from inside one repository.
+
+## What the review established
+
+**B1 (as corrected) — precedence between two permitted forms.** §11 accepts a
+`layer:` key in `INTENT.md` frontmatter *or* an equivalent declaration file, and
+does not say which governs when a repository carries both. Nine repositories
+carry both and disagree in every case: `INTENT.md` capitalises, `layer.yaml`
+does not. A conformance run reading one file and a run reading the other reach
+different answers for nine repositories, and both follow §11. Two rulings are
+needed: which form governs, and whether the §3 vocabulary is case-sensitive.
+
+The first published B1 claimed the estate spelled `layer:` three ways *across*
+repositories. It was produced by a shell pipeline that took the first match per
+repository across two files without recording which file it came from. flex-auth
+rebuilt it as `tools/survey_layer_declarations.go` with a receipt, and running it
+falsified the finding it was built to reproduce. The correction is the stronger
+result: the disagreement is *within* each repository and universal rather than
+careless.
+
+**B2 — four security-relevant repositories carry no `layer:` key**: gate-house,
+key-cape, ops-mason, net-kingdom.
+
+**B3 — an emission guarantee nobody has claimed.** §11 requires every repository
+catalogued in §4 as a source of evidence to declare class, cadence and detection
+surface, and says a source declaring none is not conforming. flex-auth produces
+the decision record and declares none. Whether it is a §4 source, or only the
+producer of an artifact audit-core is the source of, is unruled. flex-auth has
+declined to take the reading that favours it and holds the gap open as G2.
+
+**B4 — whether a layer declaration should carry a standard version.** flex-auth
+removed `0.7` from its own and enforced the absence by test: assent is to a
+boundary at a named version, not to current text, so a version in the declaration
+makes every revision read as though it invalidated the declaration.
+
+**B5 — canon names `access-engine`; the repository still answers to `flex-auth`**
+and the rename (FLEX-WP-0020) has not landed.
+
+## Two findings the review could not see
+
+The review surveyed the twelve counterparts flex-auth has boundaries with. An
+estate-wide sweep of every repository carrying a declaration finds fourteen, and
+the three it did not cover change two of its conclusions.
+
+**Two repositories declare values outside the §3 vocabulary.**
+`informed-decision` declares `surface` and `railiance-master` declares
+`Taxonomy`, in both files. flex-auth's validator admits only
+`{Staff, Engine, Tooling}`, so these fail it on the value rather than on casing
+or precedence — a third non-conformance class, and the only one where the
+declared layer is not a layer the model defines. Whether §3's vocabulary is
+closed, or these name a real tier the model has not enumerated, is a question
+for the same ruling that settles B1.
+
+**The "two generators, two conventions" reading does not hold estate-wide.**
+Nine of nine is true of the repositories flex-auth surveyed, but
+`informed-decision` and `railiance-master` agree between their two files. The
+split tracks the vocabulary values, not the generators: exactly the repositories
+whose value is outside the vocabulary are the ones written by hand and
+internally consistent. This does not weaken B1 — precedence is still unruled —
+but it removes the inference that a single generator pair explains the estate,
+and with it the hope that one generator fix closes the finding.
+
+`whitehat-security` declares `Staff` in `INTENT.md` and has no `layer.yaml`,
+which is flex-auth's own shape: a second repository that cannot exhibit the
+split for the same reason.
+
+## Where the questions sit
+
+| # | Question | Owner |
+|---|---|---|
+| 1 | Which §11 form governs when both are present | gate-house |
+| 2 | Is the §3 vocabulary case-sensitive | gate-house |
+| 3 | Is §3's vocabulary closed — `surface`, `Taxonomy` | gate-house |
+| 4 | gate-house's own layer declaration (B2) | gate-house |
+| 5 | Is flex-auth a §4 source of evidence (B3) | gate-house |
+| 6 | May a declaration carry a standard version (B4) | gate-house |
+| 7 | Which side of the B3 line audit-core holds | audit-core |
+| 8 | What `CheckRequest.tenant` denotes on the write API | tenant-engine |
+| 9 | Layer declarations for key-cape, ops-mason, net-kingdom (B2) | each owner |
+
+gate-house holds six of the nine, including the ruling that decides whether
+flex-auth is non-conformant on its own conformance record today. That
+concentration is not an accident of routing: every one of them is a question
+about what §11 means, and gate-house authors §11. It is also the repository
+flex-auth names as the clearest B2 case — a doctrine owner that has not
+discharged its own obligation.
+
+audit-core can state its side of B3 without waiting for anyone, but stating it
+does not close G2: flex-auth holds the gap open until gate-house rules *and*
+audit-core confirms.
+
+tenant-engine's is the longest-running — asked 2026-09-15, re-asked 2026-09-20,
+still unanswered — and the only one of the nine blocking implementation rather
+than documentation. FLEX-WP-0022-T02 waits on it by choice: flex-auth can read
+`FlexAuthWriteAuthorizer.authorize` copying `tenant_id` onto both
+`CheckRequest.tenant` and `resource.id`, and has declined to encode a policy rule
+from reading a consumer's code. "None of the nine write actions is refused
+cross-tenant" is a complete answer; silence is not, because a deliberate
+cross-tenant scope and an omitted rule are indistinguishable in the published
+package.
+
+## The custodian's reading
+
+The v0.8 assent round should not close while §11's own mechanical check is
+ambiguous. Six of the nine questions are §11 interpretation, and a standard that
+cannot tell two conforming conformance runs to agree is not yet mechanically
+checkable in the sense §11 claims for itself. gate-house has already been asked
+to hold v0.8 over audit-core's §11 review; these belong in the same hold rather
+than in a follow-on amendment.
+
+None of this is the custodian's to rule. §11 is net-kingdom canon authored by
+gate-house, and the custodian's contribution is the estate-wide survey and the
+observation that the questions concentrate in one repository.