diff --git a/SCOPE.md b/SCOPE.md index 680db36..84e872b 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -29,9 +29,15 @@ NetKingdom security-layer-model v0.7). It is not a row in the NetKingdom §4 catalog. It is not PEP-shaped. Assent to statute §20 is `docs/adr/ADR-0009-netkingdom-security-layer-interaction.md`. +`Taxonomy` is the value §3.1 of the standard enumerates, not a local +coinage. Where a conformance tool admits only `{Staff, Engine, Tooling}`, +that tool omits §3.1; the position and its citations are +`docs/adr/ADR-0010-taxonomy-is-an-enumerated-layer.md`, held through +`gate-house`'s ruling under `RMASTER-WP-0027`. + The current implementation includes: -- nine accepted framework ADRs covering repository families, rail composition, +- ten accepted framework ADRs covering repository families, rail composition, production admission, the rapp declaration contract, exposure posture, and the NetKingdom security-layer interaction boundary; - framework contracts and migration guidance under `docs/`; @@ -150,7 +156,9 @@ the same publication addressing. accepted ADRs and contracts - Layer declaration: `INTENT.md` frontmatter and `layer.yaml` declare `layer: Taxonomy` against security-layer-model v0.7; no Tooling contacts; - State Hub listed as a non-Tooling client; not PEP-shaped + State Hub listed as a non-Tooling client; not PEP-shaped. The two files + agree and match §3's own casing. Held unchanged through `gate-house`'s + ruling on whether §3's vocabulary is closed (ADR-0010, RMASTER-WP-0027) - Security consumption: ADR-0009 and `docs/netkingdom-security-consumption-contract.md` encode the §20.2 rules (one PDP, approvals as claims, credentials after a decision, evidence diff --git a/docs/adr/ADR-0010-taxonomy-is-an-enumerated-layer.md b/docs/adr/ADR-0010-taxonomy-is-an-enumerated-layer.md new file mode 100644 index 0000000..ed8b29b --- /dev/null +++ b/docs/adr/ADR-0010-taxonomy-is-an-enumerated-layer.md @@ -0,0 +1,152 @@ +--- +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. diff --git a/workplans/RMASTER-WP-0027-layer-vocabulary-ruling.md b/workplans/RMASTER-WP-0027-layer-vocabulary-ruling.md new file mode 100644 index 0000000..4a188ec --- /dev/null +++ b/workplans/RMASTER-WP-0027-layer-vocabulary-ruling.md @@ -0,0 +1,101 @@ +--- +id: RMASTER-WP-0027 +type: workplan +title: "Hold the Taxonomy layer declaration through the gate-house vocabulary ruling" +domain: financials +repo: railiance-master +status: active +owner: claude +topic_slug: layer-vocabulary-ruling +flavor: planning +created: "2026-09-21" +updated: "2026-09-21" +--- + +# RMASTER-WP-0027 - Hold the Taxonomy layer declaration through the gate-house vocabulary ruling + +## Goal + +State and hold this repository's position that `layer: Taxonomy` is a value §3 +of the NetKingdom security layer model enumerates, through `gate-house`'s +ruling on whether §3's vocabulary is closed, and act on the ruling once it +lands. + +Position: `docs/adr/ADR-0010-taxonomy-is-an-enumerated-layer.md`. +Source: `the-custodian/docs/assessments/2026-09-21-layer-declaration-boundaries.md` +(custodian estate sweep), derived from `flex-auth` `FLEX-WP-0030`. +Statute: `net-kingdom/canon/standards/security-layer-model_v0.8.md` §3, §3.1, §11. + +## Boundaries + +- Do not change the declared value in `INTENT.md` or `layer.yaml` before the + ruling. The declaration is the evidence of what this repository holds itself + to be. +- Do not rule on §3, §11 or the vocabulary. That is `gate-house`'s. +- Do not speak for `informed-decision` on `surface`. Different question, other + owner. +- Do not touch `standard_version` here; B4 is a separate open question. +- Do not modify any repository other than this one. + +## T01 - Record the position + +```task +id: RMASTER-WP-0027-T01 +status: done +priority: high +``` + +Establish from this repository's own documents and history what `Taxonomy` +denotes, why it was chosen over Staff, Engine and Tooling, and whether the term +is used consistently with `gate-house` and `info-tech-canon`. Record the result +as a framework ADR. + +**Done when:** an accepted ADR states the position with the canon and estate +citations behind it. + +Completed 2026-09-21 as `ADR-0010`. §3 enumerates four layers with `Taxonomy` +as §3.1 in every version v0.1–v0.8; §4 assigns the value to `info-tech-canon` +and `net-kingdom`; §7 and §17 both carry it; `gate-house`'s own `INTENT.md` +uses it. Our casing matches §3's table. + +## T02 - Send the position to gate-house + +```task +id: RMASTER-WP-0027-T02 +status: done +priority: high +``` + +Send `ADR-0010` to `gate-house` via the State Hub as input to the §3 vocabulary +ruling, noting that the custodian's estate sweep is where this surfaced and +that it was not a finding against this repository. + +**Done when:** the message is sent and cites the ADR and the canon sections. + +Completed 2026-09-21. + +## T03 - Act on the ruling + +```task +id: RMASTER-WP-0027-T03 +status: wait +priority: medium +``` + +Wait on `gate-house`'s ruling on question 3 of the custodian's table (is §3's +vocabulary closed). + +- If the vocabulary is open and `Taxonomy` is declarable — nothing changes + here. Record the confirmation in `ADR-0010` notes and close. +- If `gate-house` rules the §11 declaration vocabulary closed at three despite + §3.1 — change the value in `INTENT.md` and `layer.yaml` in one commit, + keeping the two files equal per `RMASTER-WP-0026-T01`, and amend `ADR-0010` + by revision rather than by silent edit. + +Also pick up questions 1 (precedence), 2 (case sensitivity) and 6 (may a +declaration carry a standard version) if the same ruling settles them; 6 is the +only one that changes a file here, since our two files already agree and our +casing already matches §3. + +**Done when:** the ruling has landed and this repository's declaration and ADR +reflect it.