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.

Resolution, 2026-09-21

gate-house ruled all six of its questions the same day, in GH-DEC-2026-017 (declaration form), GH-DEC-2026-018 (B3) and GH-DEC-2026-019 (the v0.8 hold), with the canon changes drafted as gate-house amendments A9–A13 and circulated for assent. No net-kingdom file was edited; publication stays with net-kingdom.

• Precedence. INTENT.md governs; a layer.yaml is a derived artifact that must agree. Precedence alone would have made eight of the nine disagreements invisible rather than settled, so a disagreement between the two forms stays a reportable finding.
• Case. Case-insensitive, ASCII fold, §4's column spelling canonical. No repository re-spells anything; flex-auth's validator changes, as it offered.
• Vocabulary. Closed at four tokens, not three. The validator's omission of Taxonomy is the defect; railiance-master is conforming. surface is the only genuine off-vocabulary value.
• Scope. §11 binds §4, and both off-vocabulary repositories sit outside §4 — so neither is a non-conformance, and a conformance run must now state its scope. That rule reaches this record: the sweep below was published without stating that it ranged over every repository carrying a declaration rather than over §4, and two of its three findings turned on repositories §11 does not bind.
• B2. Discharged for gate-house in the same commit: INTENT.md frontmatter, layer: Staff, no sidecar. The prose **Layer:** Staff line had stood since v0.1 and is exactly what gate-house's own paragraph says does not count.
• B3. Ruled against flex-auth: a custodian is never the source of what it holds, so flex-auth is a §4 source, owes an emission guarantee, has none, and is non-conforming on §11 today. audit-core's reading is upheld. The finding under it: §11 says "catalogued in §4 as a source of evidence" and §4 catalogues no such thing, so flex-auth could not have answered from the text.
• B4. No standard version in a declaration. Every sidecar in the estate carries standard_version: "0.7" because ops-warden's reference form does — one change in one repository, not seven.
• v0.8 stays held, with three stated conditions so the hold cannot drift.

Of the ten questions this record tracked, eight are ruled or answered. Outstanding: informed-decision's §4 membership (asked, not enrolled) and the role: vocabulary, which needs A9 first.

What the custodian got wrong, twice

Both errors were the same error. The sweep was run against flex-auth's validator as a stand-in for §3, and published as an estate property without stating the scope it ranged over. Taxonomy was in §3 all along, and the two repositories named were never bound by §11. The reviewed repositories caught both: railiance-master supplied the §3 citations, informed-decision narrowed its own request rather than re-litigating, and gate-house's scope rule names the defect generally. The custodian's contribution that survived is the §3-Engines/§4-Engine disagreement, which became amendment A9.

Application, 2026-09-21

• ops-warden applied GH-DEC-2026-017 to the reference form after verifying it at gate-house@def0af2. Its conformance checker listed standard_version as required, so any repository that copied the checker must drop the key from the checker's required list in the same commit, or a conforming declaration fails MALFORMED. Change set: ops-warden/wiki/playbooks/netkingdom-layer-declaration.md.
• flex-auth fixed its validator (four tokens, ASCII fold, §4 spelling, scope stated per run), published per-class emission guarantees in cadence.yaml, and holds G2 as a dated declared gap to 2026-10-19 under FLEX-WP-0031. FLEX-DEC-2026-015: resource.system follows the runtime, not the repository.
• informed-decision declares Staff/pep-shaped and asked for a §4 row with its guarantee reported as owed. The §3.4 fit — Staff is defined as non-deterministic; this repository is deterministic by test — stays open as INFD-IN-0007.
• secrets-engine established that its exec reads the ungoverned legacy path secret/coulomb/whynot-design/npm/publish (field npm_token), while ops-warden's runbook rotates the governed path (field NPM_AUTH_TOKEN). A rotation per the runbook would not reach the live publish path. Held for the operator.

Ten repositories still carry the pre-ruling sidecar form.

Second round, 2026-09-21

GH-DEC-2026-017 is applied in thirteen repositories. No standard_version field remains in any declaration, and no layer value was re-spelled. Six repositories carried a copy of ops-warden's conformance checker, not five as first counted; zone-engine's was under tools/. Each required standard_version, and several compared layers with plain equality. Every one changed in the same commit as its field.

Three questions about A12's reach went to gate-house with counts measured on disk. The repositories' own reports had suggested a 3–3 split on the versioned standard: path. On disk, only audit-core and user-engine still pin one.

• flex-auth closed FLEX-WP-0022. It enforces tenant-engine's invariant (tenant = resource.id) as a deny, and states and tests cross-tenant scope. One exception is named: user-engine's onboarding grant excludes tenant:platform. That was sent back to tenant-engine rather than decided. v3 is not rolled out.
• tenant-engine is admitted as an audit-core sender but cannot deliver: the egress NetworkPolicy, the URL, and the token projection are missing from its deploy manifests. TEN-IN-0005; this needs an operator credential path.
• secrets-engine surfaced a question: the service JWT design names tenant:coulomb, but the approval chain resolved to tenant:platform.