# 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.