railiance-master/docs/adr/ADR-0010-taxonomy-is-an-enumerated-layer.md

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