coulomb/the-custodian
4
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Record the estate-wide view of flex-auth's layer-declaration boundaries review.

Browse source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
codex 2026-09-21 02:02:21 +02:00
parent 855835dcbc
commit 736a740286
1 changed files with 121 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

121
docs/assessments/2026-09-21-layer-declaration-boundaries.md Normal file
View file

@ -0,0 +1,121 @@
# 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.