--- id: RMASTER-WP-0026 type: workplan title: "Align railiance-master with the NetKingdom security-layer model" domain: financials repo: railiance-master status: ready owner: grok topic_slug: netkingdom-security-layer-alignment created: "2026-08-29" updated: "2026-08-29" --- # RMASTER-WP-0026 - Align railiance-master with the NetKingdom security-layer model ## Goal Make this repository a conforming Taxonomy home for Railiance workload operations under NetKingdom Security Layer Model v0.7: declare the layer in a machine-readable form, record assent to statute §20, bind Railiance consumers to the §20.2 consumption rules, split admission/exposure from authorization, and open the five unsettled axis-to-layer questions without guessing them. Source review: `history/260829-demand-netkingdom-security-layer-alignment.md`. Statute: `net-kingdom/canon/standards/security-layer-model_v0.7.md`. Companion: `net-kingdom/SECURITY-COMPANION.md` v0.2. ## Boundaries - Do not add this repository to the NetKingdom §4 catalog; that is `gate-house`. - Do not host a PDP, approval store, credential plane, or evidence archive. - Do not publish a PEP stance map from this repository; it is not PEP-shaped. - Do not invent a mapping of `rail-*` / `rapp-*` / `reef-*` / `railiance-*` onto Taxonomy, Tooling, Engine, or Staff. Statute §20.3 is unsettled. - Do not absorb `glas-harness` session or tool-policy semantics. - Do not treat observation-in-production or automatic containment as available. - Do not fold RMASTER-WP-0020 (OpenBao migration) into this workplan. - `info-tech-canon` remains the general semantic canon; this workplan does not redefine it. ## T01 - Machine-readable layer declaration ```task id: RMASTER-WP-0026-T01 status: todo priority: high ``` Add `layer.yaml` in the kings-guard no-contact shape, pointing at security layer model v0.7: - `layer: taxonomy` - `role` omitted - `tooling_contacts: []` - `non_tooling_clients` lists the State Hub progress/work-record client - no `pep_stance` path - catalog note: not a §4 row; operations Taxonomy, not NetKingdom security Taxonomy `INTENT.md` frontmatter already declares `layer: Taxonomy`. Keep the file and the frontmatter equal. A conformance script is optional in this task; the declaration file is the §11 surface. **Done when:** `layer.yaml` is committed, agrees with `INTENT.md`, and a reviewer can see there are no Tooling contacts and no PEP claim. ## T02 - Record assent to statute §20 ```task id: RMASTER-WP-0026-T02 status: todo priority: high ``` Record, in this repository's own voice, that: - statute §20.1 restates our axis and workload definitions and does not author them; - statute §20.2 is accepted as the consumption constitution for every Railiance consumer of NetKingdom security; - statute §20.3 remains unset, and this repository will not imply a mapping; - changes to §20 require our assent for the axis definitions. Form: a short accepted ADR, or a dated decision note under `docs/adr/` with publication-grade metadata. Notify `gate-house` / `net-kingdom` so §14 stops treating this repository as silent. **Done when:** the assent record exists, is cited from `INTENT.md` or `SCOPE.md`, and a State Hub message (or equivalent durable notice) has been sent to `gate-house`. ## T03 - Framework consumption contract ```task id: RMASTER-WP-0026-T03 status: todo priority: high ``` Write a framework contract, cited by the T02 ADR or a follow-on ADR, that Railiance rails, rapps, and reefs consume NetKingdom security as follows: 1. Authorization decisions come from `access-engine` only. 2. Approvals are `approval-engine` objects consumed as claims. 3. Credentials come from `secrets-engine` after a decision. 4. Evidence goes to `audit-core` under the alteration/truncation bound. 5. A runtime that causes a protected side effect is PEP-shaped and owes statute §6.4 in *its* repository, including a published stance map in the §13.1 register. Do not copy engine schemas. Point at the statute and at the owning repos. Distinguish this contract from ADR-0006 (admission) and ADR-0008 (exposure). **Done when:** the contract is in `docs/`, an ADR cites it, and SCOPE's "security consumption" gap no longer says the eight ADRs are silent on §20.2. ## T04 - Split admission, exposure, and authorization ```task id: RMASTER-WP-0026-T04 status: todo priority: medium ``` Add a short vocabulary note, preferably in the T03 contract rather than a fourth ADR, that these three questions stay distinct: | Question | Owner | | --- | --- | | May this binding run in production? | Railiance admission (ADR-0006) | | Who may reach the listener we control? | Railiance exposure (ADR-0008) | | May this actor perform this action on this resource? | `access-engine` | `production-approved` and `exposure: public` MUST NOT be read as authorization decisions. Compiled admission or exposure data that resolved whether an actor may act would be statute §6.1 (deciding early). **Done when:** ADR-0006, ADR-0008, and the T03 contract each point at the split, and no schema field is renamed unless a later ADR requires it. ## T05 - Track the five unsettled §20.3 questions ```task id: RMASTER-WP-0026-T05 status: todo priority: medium ``` Open a durable exploration record (demand files or a single `docs/` note cited by T02) for the five questions statute §20.3 names, without answering them: 1. Identity form of a `rapp-*` as a request-claim resource. 2. Whether a `rail-*` contract can carry PEP obligations, given that §6.4 attaches to repositories. 3. Composition of a `reef-*` with a security zone. 4. Relation of the `railiance-*` ownership axis to the principal a decision is rendered for. 5. The `glas-harness` / statute §3.4 seam: tool policy versus conduit-or-engine API, where "tool availability is not permission" is either enforced or lost. Question 5 requires `glas-harness` assent before any ADR. Questions 1–4 require `gate-house` / engine-owner review before they become framework decisions. Do not ship a mapping ADR in this workplan. **Done when:** each question has an owner, a next review date, and a stated non-answer, and SCOPE lists them as tracked rather than as missing architecture. ## T06 - Close the SCOPE gap for this alignment ```task id: RMASTER-WP-0026-T06 status: todo priority: low ``` After T01–T05, refresh `SCOPE.md` Current State and Gap to Intent so they describe evidenced artifacts rather than the 2026-08-29 starting deficit. Keep Intent aspirational. Do not mark this workplan finished while T02 and T03 are open. **Done when:** SCOPE's security-consumption and layer-declaration bullets match the files on disk, and this workplan can move to `finished` without leaving silent follow-on work. ## Sequencing T01 can proceed immediately. T02 and T03 are the load-bearing pair; T04 may land inside T03. T05 must not block T02. T06 is last.