--- id: RMASTER-DEMAND-2026-08-29-001 type: demand-review status: accepted received: "2026-08-29" reviewed: "2026-08-29" reviewer: grok source: operator consumer: railiance-master maintainers, rail/rapp/reef implementation repos, gate-house, glas-harness resulting_workplan: RMASTER-WP-0026 standards: - net-kingdom/canon/standards/security-layer-model_v0.7.md - net-kingdom/SECURITY-COMPANION.md --- # Review: align railiance-master with the NetKingdom security-layer model ## Demand signal The NetKingdom security-layer standard has been finalized as **accepted v0.7** (2026-08-29) and complemented by **working companion v0.2**. Read the latest text, adapt `INTENT.md`, update `SCOPE.md`, assess remaining gaps between intent and current implementation, and open a workplan for the evolution this repository still owes. ## Consumer purpose Maintainers and downstream Railiance repositories need to tell, without reconstructing context from `gate-house` notes: - which NetKingdom layer this architecture home occupies; - that operations belong to Railiance and security constitution to NetKingdom; - which §20 rules every Railiance consumer already owes; - which axis-to-layer mappings are **not** settled and must not be guessed; - which implementation work belongs here versus in `access-engine`, `approval-engine`, `secrets-engine`, `audit-core`, `glas-harness`, or a concrete rail/rapp/reef. ## Purpose fit **Strong fit.** `INTENT.md` already names this repository as the Railiance framework architecture home and, as of 2026-08-29, as the owner of the workload-operation axes. Statute §20 restates those definitions and asks this repository to assent to the boundary. Companion §9 is the operative form of the same paragraph. Aligning intent and scope with that boundary is this repository's job. Implementing engines, PEPs, or harness session semantics is not. ## Evidence reviewed - `net-kingdom/canon/standards/security-layer-model_v0.7.md` (accepted; §2–§6, §11, §16, §20) - `net-kingdom/SECURITY-COMPANION.md` v0.2 (operative form; §1–§2, §9) - `net-kingdom/docs/adr/ADR-0015` (per-engine rapp packaging; not a layer map) - `INTENT.md` and `SCOPE.md` before and after this review - `docs/adr/ADR-0001` through `ADR-0008` - `docs/repository-axes.md`, `docs/exposure-posture-contract.md`, `schemas/README.md` - Reference declarations: `ops-warden/layer.yaml`, `kings-guard/layer.yaml` - Open work: `RMASTER-WP-0020` (blocked OpenBao migration); finished `RMASTER-WP-0024`, `RMASTER-WP-0025` ## What the standard requires of this repository Statute §11: an estate-authored repository declares its layer in its own `INTENT.md`, in a machine-readable form. A catalog row or a review note about us is not a declaration. We are **not** in §4, so the declaration is an adoption of the model for the operations architecture home, answering the §16 question whether non-security repositories use the same constitution. Companion §2: frontmatter `layer:` plus prose in our own voice. Statute §20 / companion §9: consume, do not author: 1. decisions from `access-engine` only; 2. approvals as `approval-engine` objects consumed as claims; 3. credentials from `secrets-engine` after a decision; 4. evidence to `audit-core` under the alteration/truncation bound; 5. protected side effects are PEP-shaped. Statute §20.3: **do not assume** a mapping of the four axes onto the four layers. Raising the questions is welcome; guessing is a finding. Statute §20.4: changes to the interaction boundary require this repository's assent for axis definitions and `glas-harness` assent for the session seam. Companion §10: do not plan around observation-in-production or automatic containment. Both are at zero estate-wide. ## Layer chosen **Taxonomy**, `role: null`. The test in companion §1: this repository produces terms, semantic contracts, and standards for workload operations. It owns no runtime position and no state another layer depends on. Workplans and tasks exist here as coordination, not as the product of the framework. This is Railiance operations taxonomy, not NetKingdom security taxonomy. `info-tech-canon` remains ecosystem-wide semantics; `net-kingdom` remains NetKingdom standards of record; this repository remains the owner of `railiance-*` / `rail-*` / `rapp-*` / `reef-*`. Contest this layer if it is wrong — companion §2 asks for that correction rather than a polite label. This repository is **not PEP-shaped**. `validate-family-declarations.py` is a linter, not a runtime that causes a protected side effect. ## Scope versus intent | Intent (after this alignment) | Current evidenced scope | Gap | | --- | --- | --- | | Declare `layer: Taxonomy` in our own voice | Frontmatter now present in `INTENT.md` | Machine-readable `layer.yaml` and a conformance check, as in the `kings-guard` no-contact form, are missing | | Total account of non-Tooling clients | State Hub writes exist in practice | Not declared; §5 carve-out still requires listing so the check is total | | Consume §20.2 for every Railiance consumer | ADR-0001–0008 are silent on PDP, approval objects, credentials-after-decision, evidence bound, and PEP-shape | Framework consumption contract / ADR not written | | Admission and exposure stay Railiance axes and are not authorization decisions | ADR-0006 and ADR-0008 exist and do not mention `access-engine` | Vocabulary demarcation contract missing; risk that `production-approved` or `exposure: public` is read as a decision | | Do not map axes onto layers until assented | No mapping exists (correct restraint) | The five §20.3 questions have no tracked exploration; drift will invent them in implementation repos | | glas-harness / §3.4 seam is joint | INTENT names reins as adjacent | No joint contract; "tool availability is not permission" has no Railiance-side owner | | Assent to §20 restatement of our definitions | Not recorded as a decision | Needed so gate-house can cite something other than a review note | | Do not host a PDP, approval store, credential plane, or evidence archive | True: none of those surfaces exist here | Keep it; principle 13 now states it | | Do not claim observation or containment | True | Keep it; companion §10 | | Import NK constitution the way ITC is imported | SCOPE "How It Fits" previously omitted it | Corrected in this pass; remaining work is the consumption contract, not a second canon | ## What is already aligned - Workload = managed running deployable, with the ADR-0007 coverage rule. Statute §20.1 restates this; companion §9 copies it. No rewrite of the object of the architecture is required. - Four axes and the rein-is-not-a-fifth-axis rule. §20.1 matches the 2026-08-29 INTENT clarification. - This repo does not implement rails, rapps, reefs, cluster, or platform. - ADR-0008 private-by-default is an exposure rule, which can remain if it is explicitly *not* an authorization decision. - RMASTER-WP-0025 forbade inventing workload identity for non-workloads, which is why approvals must not become a Railiance axis. ## What must not be done here - Do not add `railiance-master` to NetKingdom §4. That catalog is `gate-house`'s. - Do not write a rail→Engine or rapp→PIP mapping in an ADR until §20.3 is actually decided with the other side. - Do not publish a PEP stance map from this repository. - Do not fold glas-harness session semantics into a Railiance family. - Do not treat RMASTER-WP-0020 (OpenBao migration) as the layer-alignment workplan. OpenBao is catalogued Tooling; operating it is a declared-gap question for the Staff repo that holds the client, not for this Taxonomy home. ## Necessities for the current implementation Ordered by what this repository can close without pretending to own an engine: 1. **Machine-readable declaration.** `layer.yaml` in the kings-guard no-contact shape: Taxonomy, empty `tooling_contacts`, State Hub listed under `non_tooling_clients`, no PEP stance path. Optional conformance script later; the file is the §11 surface. 2. **Recorded assent** to statute §20 as a restatement of our definitions and as the consumption rules our consumers owe. 3. **Framework consumption contract** (ADR or `docs/` contract cited by an ADR) that binds rails, rapps, and reefs to §20.2 without copying engine schemas. 4. **Vocabulary split** among admission (ADR-0006), exposure (ADR-0008), and authorization (`access-engine`). Three questions, three owners. 5. **Tracked exploration of §20.3**, five questions, no premature answers. The glas-harness seam is the highest-consequence of the five and needs that repository's assent. 6. **Notice to `gate-house` / `net-kingdom`** that this repository has declared Taxonomy in its own voice, so §14's "undeclared non-security repos" list can stop treating us as silent. ## Disposition **Accepted** as `RMASTER-WP-0026`. The work belongs here because it changes this architecture repository's own interfaces: layer declaration, consumption contract, and the operations side of an interaction boundary the statute already says we must assent to. Engine implementation, PEP stance maps of live runtimes, and harness session semantics are routed outward.