railiance-master/history/260829-demand-netkingdom-security-layer-alignment.md

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