docs: align intent and scope with NetKingdom security-layer v0.7
Declare this repository Taxonomy of Railiance workload operations, consume statute §20 without hosting a PDP, and open RMASTER-WP-0026 for the machine-readable declaration, consumption contract, and unsettled axis mapping. Assistant: grok Assistant-Session: 01a04c9f-cd6b-7741-bce0-f1d9d1b3c3bc
This commit is contained in:
codex
parent
22d88db056
commit
fb0c038eb6
5 changed files with 528 additions and 16 deletions
190
workplans/RMASTER-WP-0026-netkingdom-security-layer-alignment.md
Normal file
190
workplans/RMASTER-WP-0026-netkingdom-security-layer-alignment.md
Normal file
|
|
@ -0,0 +1,190 @@
|
|||
---
|
||||
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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue