--- id: RMASTER-ADR-0010 title: "Taxonomy Is An Enumerated Layer, Not A Value Outside The Vocabulary" status: accepted revision: "accepted-1" owner: railiance-master last_reviewed: "2026-09-21" review_interval: 6m --- # ADR-0010: Taxonomy Is An Enumerated Layer, Not A Value Outside The Vocabulary Date: 2026-09-21 Status: Accepted ## Context `flex-auth` published a boundaries review (`FLEX-WP-0030`, `flex-auth/docs/conformance/boundaries-review.md`) on 2026-09-20, corrected 2026-09-21, surveying how repositories declare their layer under §11 of the NetKingdom security layer model. It surveyed the twelve counterparts `flex-auth` holds boundaries with; this repository is not one of them and was not surveyed. The custodian then swept the whole estate and recorded the result in `the-custodian/docs/assessments/2026-09-21-layer-declaration-boundaries.md`. That sweep is where this reached us. It was never a finding against this repository, and nobody had raised it here before. The sweep records that `flex-auth`'s validator admits only `{Staff, Engine, Tooling}`, and that two repositories declare values outside that set: `informed-decision` declares `surface`, and this repository declares `Taxonomy`. It classes both as a third non-conformance class — "the only one where the declared layer is not a layer the model defines" — and refers the question of whether §3's vocabulary is closed to `gate-house`. This ADR is this repository's input to that ruling. It does not rule; §11 and §3 are net-kingdom canon authored by `gate-house`, and ADR-0009 already binds us to that division. ## Decision 1. **`Taxonomy` is a layer the model defines.** §3 of the security layer model enumerates four layers, and `Taxonomy` is the first row of its own table. §3.1 is the section that defines it. This is true of every version of the standard from v0.1 through v0.8, the proposed version under assent: | Layer | Character | Produces | Deterministic | | --- | --- | --- | --- | | **Taxonomy** | cross-cutting language | terms, semantic contracts, standards | n/a — describes | | **Tooling** | infrastructure and state | data structures, persistence | yes | | **Engines** | interfaces for a modeled concept | APIs, contracts | yes | | **Staff** | management, operations, change, controlling | specifications, decisions, workplans, tasks | **no** | The §3 vocabulary is therefore not `{Staff, Engine, Tooling}` and never was. A validator admitting those three omits §3.1. 2. **We do not change our declared value.** `layer: Taxonomy` stands in both `INTENT.md` frontmatter and `layer.yaml`. The artifact that disagrees with §3 is the validator's admitted set, not our declaration. 3. **We take no position on `surface`.** `informed-decision`'s value is a genuinely different question: `surface` does not appear in §3 under any version. Grouping it with `Taxonomy` as one finding is the part of the sweep's third class we do not accept. That repository speaks for itself. 4. **We take no position on the case-sensitivity question (B1/question 2)** beyond the observation in the evidence below, and none on precedence (question 1), which does not bite here: our two files agree. 5. **If `gate-house` rules otherwise** — that §3's vocabulary is closed at three for §11 declaration purposes and `Taxonomy` is not a declarable value — we will change the declaration in both files in one commit and amend this ADR by revision, not by silent edit. We will not pre-empt that ruling by changing the value now, because the declaration is the evidence of what this repository holds itself to be. ## Evidence The term is load-bearing in canon and in live estate use, not a local coinage: - **§3 and §3.1** of `security-layer-model` v0.1 through v0.8 define the Taxonomy layer: "Cross-cutting language. Taxonomy repositories define terms and semantic contracts so the other layers interoperate without integration by interpretation. They own no runtime position and no state any layer depends on." - **§4**, the security-estate catalog, assigns the layer `Taxonomy` to two rows in v0.8: `info-tech-canon` and `net-kingdom`. The model uses the value as a layer assignment in its own catalog. - **§7** maps the layers onto the Active Secrets Management Canon planes and carries `Taxonomy` as a fourth line alongside Staff, Engines and Tooling. - **§17 is titled "Taxonomy artifacts"** and assigns ownership of the claim, decision-record, gap-record and stance-map schemas to "Taxonomy" as a layer with owners. - **`gate-house`'s own `INTENT.md`** (lines 87–88) records `info-tech-canon` and `net-kingdom canon` in the `Taxonomy` layer. The doctrine owner uses the value. - **`info-tech-canon`'s `INTENT.md`** declares itself "part of the **Taxonomy** layer" in prose. It carries no `layer:` key and no `layer.yaml`, so it is a §11 B2 case rather than a vocabulary case — but its intent is the same value. - **Our own casing matches §3's table.** `Taxonomy` is capitalised in §3 as `Tooling`, `Engines` and `Staff` are. The nine repositories whose `layer.yaml` lower-cases `engine` or `staff` are the ones that diverge from the standard's own spelling; we do not. We also note the validator admits `Engine` where §3 writes `Engines`, which suggests the admitted set was built from §4's role-typed catalog rows rather than from §3. ## What `Taxonomy` denotes here, and why not Staff, Engine or Tooling This repository produces terms, family contracts and standards for Railiance workload operations — the `railiance-*` / `rail-*` / `rapp-*` / `reef-*` axes, the workload coverage rule, and the composition semantics. That is §3.1's character exactly, and `layer.yaml` states §3.1's own test in §3.1's own words: it owns no runtime position and no state another layer depends on. - **Not Engine.** It exposes no deterministic API over a modeled concept, is not PEP-shaped, and ADR-0009 §5 and INTENT principle 13 forbid it becoming a second decision point. `role: null` follows. - **Not Tooling.** It persists nothing and keeps no state. - **Not Staff.** Staff is management, operations, change and controlling. This repository defines vocabulary and boundaries; the rails, rapps and reefs that operate workloads are elsewhere and carry the §6.4 obligations themselves. The usage is consistent with `gate-house`'s and `info-tech-canon`'s: the same layer, a different scope. `layer.yaml`'s `catalog_entry.note` has stated that distinction since 2026-08-29 — "This is Railiance operations Taxonomy, not NetKingdom security Taxonomy. info-tech-canon remains ecosystem-wide semantics; net-kingdom remains NetKingdom standards of record" — and states in the same breath that we are **not** a §4 catalog row. Declaring the Taxonomy layer and claiming a §4 row are two different claims, and we make only the first. The value was chosen deliberately, under `RMASTER-WP-0026-T01`, which instructed "keep the file and the frontmatter equal". Internal agreement here is a decision that was taken, not an accident of a generator. ## Consequences - `gate-house` has, in this ADR, a citable statement that the value under question is enumerated in the section said to exclude it. The cheapest resolution of question 3 is a correction to the validator, not to two repositories' declarations. - The custodian's third non-conformance class splits. `Taxonomy` is a validator defect; `surface` remains open on its own terms. - Our `standard_version: "0.7"` in both files is a separate question — B4 asks whether a declaration may carry a standard version at all. We hold it unchanged pending that ruling for the same reason as the layer value, and will re-point at the accepted version once v0.8's assent round closes. - ADR-0009 is not amended. This ADR adds the vocabulary position that record did not have to state, because nothing had questioned it. ## Notes Tracked in `RMASTER-WP-0027`. Sent to `gate-house` as input to the §3 vocabulary ruling on 2026-09-21.