6.7 KiB
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.