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

id	type	status	received	reviewed	reviewer	source	consumer	resulting_workplan	standards
RMASTER-DEMAND-2026-08-29-001	demand-review	accepted	2026-08-29	2026-08-29	grok	operator	railiance-master maintainers, rail/rapp/reef implementation repos, gate-house, glas-harness	RMASTER-WP-0026	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.