railiance-master/workplans/RMASTER-WP-0026-netkingdom-security-layer-alignment.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
RMASTER-WP-0026	workplan	Align railiance-master with the NetKingdom security-layer model	financials	railiance-master	ready	grok	netkingdom-security-layer-alignment	2026-08-29	2026-08-29	256107a6-bf83-5e05-b2d5-1d75d790df5b

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

id: RMASTER-WP-0026-T01
status: todo
priority: high
state_hub_task_id: "fede9ca2-1c38-5e51-aa37-ff1abdfdfcd3"

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

id: RMASTER-WP-0026-T02
status: todo
priority: high
state_hub_task_id: "8c7baa43-0050-54ea-978e-6c58a2cb94e6"

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

id: RMASTER-WP-0026-T03
status: todo
priority: high
state_hub_task_id: "2ecaca39-c14e-567a-a667-d51babec749a"

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

id: RMASTER-WP-0026-T04
status: todo
priority: medium
state_hub_task_id: "73241688-9877-54e8-8498-507efc7a42f4"

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

id: RMASTER-WP-0026-T05
status: todo
priority: medium
state_hub_task_id: "7827d59b-66aa-5d8b-8cfc-57024a7e588c"

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

id: RMASTER-WP-0026-T06
status: todo
priority: low
state_hub_task_id: "6452ba15-0918-5907-a78d-b3d101e82060"

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.