the-custodian/docs/assessments/2026-09-21-layer-declaration-boundaries.md

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.

One repository declares a value outside the §3 vocabulary — not two. informed-decision declares surface, which appears nowhere in the model as a layer. railiance-master declares Taxonomy, and Taxonomy is §3's first enumerated layer, defined in §3.1, carried in §4's catalog, mapped in §7 and given its own §17. The custodian's first reading of this finding was wrong: it took flex-auth's validator set {Staff, Engine, Tooling} for the §3 vocabulary. §3 enumerates four layers — Taxonomy, Tooling, Engines, Staff. The correction is railiance-master's, with the citations, and it is recorded here rather than quietly amended because the first version was circulated to gate-house.

What remains of the finding is sharper and is aimed at the validator and the standard, not at the declaring repositories:

• flex-auth's validator omits §3.1 and misspells §3.3. It admits Engine where §3's table writes Engines, and omits Taxonomy altogether. Its set looks built from §4's role-typed catalog rows rather than from §3.
• §3 and §4 disagree inside the standard. §3's table says Engines; §4's catalog types eight rows Engine. A conformance run built from §3 and one built from §4 disagree about every engine repository in the estate. That is the same defect as B1 — two readings of one standard, both faithful — one level further in, and B1's precedence ruling does not reach it.
• railiance-master's casing matches §3's table exactly. Against the standard's own spelling, the nine lower-casing layer.yaml files are the divergent ones, which bears on whether case sensitivity is even the question.

informed-decision's surface is a genuinely separate case and does not behave like railiance-master's. The two should not be ruled on together.

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 only; Taxonomy is §3.1	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 — ANSWERED, TEN-DEC-2026-002	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.

Correction, 2026-09-21

The first version of this record claimed two repositories declared values outside §3's vocabulary. Taxonomy is in §3. The error was the custodian's and was made in the same shape as the one flex-auth had just corrected: a survey run against an artifact that stands in for the standard — there, a shell pipeline; here, another repository's validator — and published without reading §3 itself. A tenth question follows from the correction: whether §3's Engines or §4's Engine governs a declaration.