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

id	title	status	revision	owner	last_reviewed	review_interval
RMASTER-ADR-0010	Taxonomy Is An Enumerated Layer, Not A Value Outside The Vocabulary	accepted	accepted-1	railiance-master	2026-09-21	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.