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.