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
180
history/260829-demand-netkingdom-security-layer-alignment.md
Normal file
180
history/260829-demand-netkingdom-security-layer-alignment.md
Normal file
|
|
@ -0,0 +1,180 @@
|
|||
---
|
||||
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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue