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
116
INTENT.md
116
INTENT.md
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
layer: Taxonomy
|
||||
role: null
|
||||
standard: netkingdom-security-layer-model
|
||||
standard_version: "0.7"
|
||||
companion: net-kingdom/SECURITY-COMPANION.md
|
||||
---
|
||||
|
||||
# INTENT
|
||||
|
||||
> This file captures **why this repository exists**,
|
||||
|
|
@ -5,6 +13,16 @@
|
|||
> the **kind of system it is meant to become**.
|
||||
> It is intentionally **aspirational and stable**, not a description of current implementation.
|
||||
|
||||
> **Layer: Taxonomy.** This is the declaration required by NetKingdom Security
|
||||
> Layer Model v0.7 §11 and the working companion v0.2. It is this
|
||||
> repository's own voice, not a catalog row about us. `railiance-master` is
|
||||
> **not** a member of the NetKingdom §4 security-estate catalog. Operations
|
||||
> belong to Railiance; NetKingdom provides the security and approval
|
||||
> framework those operations consume. The statute is
|
||||
> `net-kingdom/canon/standards/security-layer-model_v0.7.md`; the companion
|
||||
> is `net-kingdom/SECURITY-COMPANION.md`. On disagreement the statute
|
||||
> governs, and a disagreement is a finding for `gate-house`.
|
||||
|
||||
---
|
||||
|
||||
## One-liner
|
||||
|
|
@ -47,9 +65,10 @@ Railiance organizes **workload operations**, not merely repositories.
|
|||
A **workload**, in the Railiance-specific sense, is a managed running
|
||||
deployable. Human commands, credential patterns, broker actions, approvals,
|
||||
and infrastructure resources that are not themselves deployables are not
|
||||
workloads. InfoTechCanon supplies the general landscape vocabulary; this
|
||||
framework owns the Railiance application: every such workload is operated
|
||||
through four composable axes.
|
||||
workloads. That is why an approval object is a NetKingdom engine concept and
|
||||
never a Railiance axis. InfoTechCanon supplies the general landscape
|
||||
vocabulary; this framework owns the Railiance application: every such workload
|
||||
is operated through four composable axes.
|
||||
|
||||
| Prefix | Axis | Question |
|
||||
| --- | --- | --- |
|
||||
|
|
@ -72,6 +91,11 @@ This repository does not define a `rein-*` family. When a rein is installed
|
|||
and operated as a managed service, it is a workload like any other and is
|
||||
packaged, executed, and bound through `rapp-*`, `rail-*`, and `reef-*`.
|
||||
|
||||
NetKingdom Security Layer Model v0.7 §20 restates these definitions; it does
|
||||
not author them. Changes to that boundary require this repository's assent
|
||||
for the axis definitions and `glas-harness`'s assent for the session and
|
||||
tool-policy seam.
|
||||
|
||||
---
|
||||
|
||||
## Operating Context
|
||||
|
|
@ -97,19 +121,59 @@ organization. They shape how humans and agents coordinate responsibilities,
|
|||
reason about workload placement, and evolve operating models without losing the
|
||||
ability to scale into more mature security and delivery expectations.
|
||||
|
||||
Railiance also participates in two wider governance structures:
|
||||
Railiance also participates in three wider governance structures:
|
||||
|
||||
* **InfoTechCanon** owns the general semantic models, standards, and repository
|
||||
conventions that Railiance adopts. This repository imports those concepts and
|
||||
applies them to Railiance; it does not redefine the canon by local usage.
|
||||
* **NetKingdom** owns the security-layer constitution (`security-layer-model`
|
||||
v0.7 and its working companion). `gate-house` authors the layers, the one
|
||||
decision point, and the Staff/Engine/Tooling binding rules. This repository
|
||||
consumes that constitution for how workload operations use identity,
|
||||
authorization, approval, credential, and evidence services. It does not host
|
||||
a second decision point, an approval store, a credential plane, or an
|
||||
evidence archive.
|
||||
* **`policy-nexus`** owns permanent publication, addressing, history, and
|
||||
currency for estate policy. This repository remains the source and
|
||||
ratification home for its architecture decision records. Publication is
|
||||
generated downstream and never written back here.
|
||||
|
||||
That separation matters. Content authority, semantic canon, and publication
|
||||
infrastructure are related responsibilities, not one responsibility hidden in
|
||||
three repositories.
|
||||
That separation matters. Content authority, semantic canon, security-layer
|
||||
constitution, and publication infrastructure are related responsibilities, not
|
||||
one responsibility hidden in four repositories.
|
||||
|
||||
---
|
||||
|
||||
## How Railiance Consumes NetKingdom Security
|
||||
|
||||
For any Railiance consumer of NetKingdom security, without exception:
|
||||
|
||||
1. Authorization decisions come from `access-engine` and from nowhere else.
|
||||
2. Approvals are objects in `approval-engine`, consumed as claims.
|
||||
3. Credentials are materialized by `secrets-engine` **after** a decision, never
|
||||
as a substitute for one.
|
||||
4. Evidence goes to `audit-core` under the bound that an archive proves
|
||||
alteration and truncation after arrival, not omission at source.
|
||||
5. Anything causing a protected side effect is **PEP-shaped** and owes a
|
||||
decision record or a recorded unreachable-engine stance, a lifetime on every
|
||||
allow, and a published stance map.
|
||||
|
||||
This repository is **not PEP-shaped**. It defines contracts; it does not cause
|
||||
protected side effects. Implementation rails, rapps, and reefs that do cause
|
||||
them inherit those obligations in their own repositories.
|
||||
|
||||
**What is not settled**, and must not be guessed here: how the four axes map
|
||||
onto Taxonomy, Tooling, Engine, and Staff. A `rapp` is the most likely
|
||||
*resource* a decision is about; a `rail` is where PEP shape is most likely to
|
||||
live, but a rail is a contract and §6.4 obligations attach to repositories; a
|
||||
`reef` is adjacent to a security zone without being one; the ownership axis is
|
||||
adjacent to the principal a decision is rendered for without being equal to it;
|
||||
and the glas-harness / §3.4 seam is where "tool availability is not permission"
|
||||
is either enforced or lost. Those five questions need explicit decisions with
|
||||
the other side's assent. They are not implied by this file.
|
||||
|
||||
Admission (whether a binding may run in production) and exposure (who may
|
||||
reach a listener) remain Railiance axes. They are not authorization decisions.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -131,6 +195,8 @@ This means:
|
|||
**separate and composable**
|
||||
* Adjacent families such as glas-harness `rein-*` remain **named and bounded**,
|
||||
not absorbed as extra Railiance axes
|
||||
* NetKingdom security is **consumed through one decision point**, never
|
||||
re-implemented as a Railiance convenience
|
||||
* Explorations mature into **stable decisions** before they spread across the
|
||||
wider repo landscape
|
||||
* Governing ADRs carry enough ownership, revision, status, and review metadata
|
||||
|
|
@ -201,9 +267,11 @@ They should not be created merely because a named machine exists.
|
|||
|
||||
General concepts such as intent, scope, demand, task, governance, evidence,
|
||||
repository layout, and workload come from InfoTechCanon and estate conventions.
|
||||
This repo owns their Railiance-specific application: repo-family vocabulary,
|
||||
workload coverage, composition, admission, exposure, and cross-repo boundary
|
||||
decisions.
|
||||
The security-layer constitution — layers, one decision point, Staff/Engine
|
||||
binding, evidence bounds — comes from NetKingdom. This repo owns the
|
||||
Railiance-specific application: repo-family vocabulary, workload coverage,
|
||||
composition, admission, exposure, the interaction boundary with that security
|
||||
constitution, and cross-repo boundary decisions.
|
||||
|
||||
### 11. Author Here; Publish Downstream
|
||||
|
||||
|
|
@ -219,6 +287,13 @@ what the repository currently owns and achieves. Consumer requests and incoming
|
|||
proposals are demand signals until reviewed; they do not silently expand scope
|
||||
or become committed work.
|
||||
|
||||
### 13. Consume Security; Do Not Become A Second Decision Point
|
||||
|
||||
A registry, schema, cache, or admission rule that resolves whether an actor
|
||||
may act has decided early. Railiance may package, place, admit, and expose
|
||||
workloads. It may not render or cache authorization decisions, mint standing
|
||||
credentials in lieu of a decision, or treat audit silence as non-occurrence.
|
||||
|
||||
---
|
||||
|
||||
## What This Is (Conceptually)
|
||||
|
|
@ -226,12 +301,16 @@ or become committed work.
|
|||
This repository is:
|
||||
|
||||
* an **architecture-definition home**
|
||||
* **Taxonomy** of Railiance workload operations — terms, family contracts, and
|
||||
standards for how workloads are owned, executed, packaged, and bound
|
||||
* a **repository taxonomy authority**
|
||||
* a home for **framework-level ADRs and conceptual models**
|
||||
* the **source repository** for Railiance framework ADRs published through
|
||||
`policy-nexus`
|
||||
* a place to define how **workload operations compose** across ownership, rail,
|
||||
rapp, and reef
|
||||
* the **assenting owner** of the axis definitions NetKingdom restates at the
|
||||
operations/security interaction boundary
|
||||
* a **migration map** from current repo reality toward cleaner framework
|
||||
structure
|
||||
|
||||
|
|
@ -241,6 +320,9 @@ This repository is:
|
|||
|
||||
This repository is not:
|
||||
|
||||
* a member of the NetKingdom §4 security-estate catalog
|
||||
* an Engine, a PDP, a PIP, an evidence plane, or a credential lifecycle API
|
||||
* PEP-shaped — it causes no protected side effects
|
||||
* the infrastructure substrate
|
||||
* the Kubernetes runtime or workload execution layer
|
||||
* the shared platform-services layer
|
||||
|
|
@ -248,14 +330,20 @@ This repository is not:
|
|||
* the application release surface
|
||||
* the implementation of the ecosystem graph registry
|
||||
* the general semantic canon owned by InfoTechCanon
|
||||
* the NetKingdom security-layer constitution owned by `gate-house` and
|
||||
published as net-kingdom canon
|
||||
* the permanent policy publication surface owned by `policy-nexus`
|
||||
* a policy CMS or a second copy of published policy
|
||||
* a dumping ground for operational runbooks that belong elsewhere
|
||||
* the glas-harness `rein-*` family, or the owner of agentic session semantics
|
||||
* a place to invent a fifth repository family for LLM or agentic work
|
||||
* a place to guess how rails, rapps, reefs, and ownership map onto
|
||||
Taxonomy, Tooling, Engine, and Staff
|
||||
|
||||
A rein deployed as a managed service is a workload on the four Railiance axes.
|
||||
The harness contract is not this repository's.
|
||||
The harness contract is not this repository's. A mapping of those axes onto
|
||||
the NetKingdom layers is an open interaction-boundary question, not an implied
|
||||
taxonomy.
|
||||
|
||||
It is the **place where the framework explains itself**.
|
||||
|
||||
|
|
@ -270,6 +358,10 @@ This repository is expected to evolve toward:
|
|||
* stronger **boundary guidance** for new repos and migrations
|
||||
* a durable distinction between Railiance workload axes and adjacent harness
|
||||
families such as `rein-*`
|
||||
* a durable **interaction boundary** with the NetKingdom security-layer model:
|
||||
consume §20.2; settle §20.3 only by explicit, assented decisions
|
||||
* machine-readable layer declaration and a total account of non-Tooling
|
||||
clients, without acquiring Engine or PEP permissions by gradual practice
|
||||
* better linkage between architecture decisions and `railiance-fabric`
|
||||
declarations
|
||||
* publication-ready ADR lifecycle metadata and durable downstream policy links
|
||||
|
|
@ -282,4 +374,4 @@ This repository is expected to evolve toward:
|
|||
|
||||
## Guiding Question
|
||||
|
||||
> **How can Railiance organize the operation of workloads clearly enough that every new ownership boundary, rail, managed package, and substrate increases capability without increasing ambiguity, even as the ecosystem grows from exploratory operation into production-grade responsibility?**
|
||||
> **How can Railiance organize the operation of workloads clearly enough that every new ownership boundary, rail, managed package, and substrate increases capability without increasing ambiguity, and without becoming a second security decision point, even as the ecosystem grows from exploratory operation into production-grade responsibility?**
|
||||
|
|
|
|||
|
|
@ -9,6 +9,8 @@ recorded before they are spread across implementation repos.
|
|||
- [Intent and direction](INTENT.md)
|
||||
- [Current scope and authority boundaries](SCOPE.md)
|
||||
- [Reviewed architecture-demand intake](demand/README.md)
|
||||
- [NetKingdom security-layer alignment review](history/260829-demand-netkingdom-security-layer-alignment.md)
|
||||
- [RMASTER-WP-0026 — security-layer alignment](workplans/RMASTER-WP-0026-netkingdom-security-layer-alignment.md)
|
||||
|
||||
## Current Architecture Baseline
|
||||
|
||||
|
|
|
|||
56
SCOPE.md
56
SCOPE.md
|
|
@ -23,6 +23,12 @@ running deployable under rapp coverage (`ADR-0007`); human acts, credentials,
|
|||
broker actions, and non-deployable infrastructure resources remain outside
|
||||
that meaning.
|
||||
|
||||
This repository now **declares** itself Taxonomy of Railiance workload
|
||||
operations in `INTENT.md` frontmatter (`layer: Taxonomy`, NetKingdom
|
||||
security-layer-model v0.7). It is not a row in the NetKingdom §4 catalog.
|
||||
The machine-readable `layer.yaml` form, a total non-Tooling-client account,
|
||||
and a framework consumption contract for §20.2 are not yet evidenced here.
|
||||
|
||||
The current implementation includes:
|
||||
|
||||
- eight accepted framework ADRs covering repository families, rail composition,
|
||||
|
|
@ -48,6 +54,11 @@ not own every implementation implied by them.
|
|||
ownership or family repository
|
||||
- Source metadata and lifecycle decisions for this repo's publishable ADRs
|
||||
- Routing accepted architecture into repo-local implementation work
|
||||
- Declaring this repository's NetKingdom security layer and the operations
|
||||
side of the Railiance/NetKingdom interaction boundary
|
||||
- Framework-level consumption rules for how rails, rapps, and reefs use
|
||||
`access-engine`, `approval-engine`, `secrets-engine`, and `audit-core`
|
||||
without hosting those engines here
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -67,6 +78,17 @@ not own every implementation implied by them.
|
|||
implementation owned by their concrete repositories
|
||||
- glas-harness `rein-*` harness contracts and agentic session semantics; a
|
||||
deployed rein is a workload on the four axes, not a fifth Railiance family
|
||||
- The NetKingdom security-layer constitution owned by `gate-house` and
|
||||
published as net-kingdom canon
|
||||
- Authorization decisions (`access-engine`), approval objects
|
||||
(`approval-engine`), credential materialization (`secrets-engine`), and
|
||||
evidence custody (`audit-core`)
|
||||
- PEP stance maps and unreachable-engine behaviour of implementation
|
||||
repositories; this repo is not PEP-shaped
|
||||
- A guessed mapping of rail, rapp, reef, or ownership onto Taxonomy,
|
||||
Tooling, Engine, or Staff — statute §20.3 is unsettled
|
||||
- Automatic containment or production observation; both are estate-wide
|
||||
zeros, not this repository's gaps to close
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -75,10 +97,13 @@ not own every implementation implied by them.
|
|||
| Concern | Authority | Relationship to `railiance-master` |
|
||||
| --- | --- | --- |
|
||||
| General semantic models and repository-layout standard | `info-tech-canon` | Imported and applied; not redefined here |
|
||||
| Security-layer constitution (layers, one PDP, Staff/Engine binding, evidence bounds) | `gate-house` / net-kingdom canon, `security-layer-model` v0.7 | Imported as the consumption constitution; not redefined here |
|
||||
| Workload-operation axes and coverage | `railiance-master` | Owned here; restated, not authored, by NetKingdom §20 |
|
||||
| Railiance framework architecture and ADR lifecycle | `railiance-master` | Authored, reviewed, accepted, superseded, or withdrawn here |
|
||||
| Permanent publication of accepted ADRs | `policy-nexus` | Downstream read-only publication; never a second source of truth |
|
||||
| Work indexing and coordination | State Hub | Cache/index rebuilt from repo-local workplan files |
|
||||
| Work indexing and coordination | State Hub | Cache/index rebuilt from repo-local workplan files; a non-catalogued client, not a Tooling contact |
|
||||
| Runtime implementation | Concrete ownership, rail, rapp, or reef repo | Routed outward after the framework boundary is settled |
|
||||
| Agentic session and tool-policy seam | `glas-harness` | Adjacent; joint assent required for §20 changes that touch the seam |
|
||||
|
||||
The policy publication corpus from this repo is `docs/adr/*.md`. Workplans,
|
||||
evidence, runbooks, schemas, and general documentation are not policy merely
|
||||
|
|
@ -97,6 +122,8 @@ publication addressing are completed.
|
|||
rules
|
||||
- Planning a migration that spans multiple Railiance repositories
|
||||
- Recording or reviewing a Railiance framework ADR
|
||||
- Declaring or changing this repository's security layer, or the operations
|
||||
side of the NetKingdom interaction boundary
|
||||
|
||||
## Not Relevant When
|
||||
|
||||
|
|
@ -105,6 +132,10 @@ publication addressing are completed.
|
|||
- A workload-specific decision has no framework-wide consequence
|
||||
- The request is about glas-harness session, tool, or rein-backend semantics
|
||||
rather than how a deployed rein is packaged, executed, or bound as a workload
|
||||
- The request is to render an authorization decision, store an approval, mint
|
||||
a credential, or keep an evidence archive
|
||||
- The request assumes observation-in-production or automatic containment
|
||||
exists
|
||||
- The request is raw demand that has not yet been reviewed for purpose and scope
|
||||
fit
|
||||
|
||||
|
|
@ -115,6 +146,14 @@ publication addressing are completed.
|
|||
- Status: maintained and evolving
|
||||
- Architecture baseline: four repository axes are materialized and governed by
|
||||
accepted ADRs and contracts
|
||||
- Layer declaration: `INTENT.md` frontmatter declares `layer: Taxonomy`
|
||||
against security-layer-model v0.7; `layer.yaml` and a conformance check are
|
||||
not yet present
|
||||
- Security consumption: ADR-0001 through ADR-0008 do not yet encode the
|
||||
§20.2 rules (one PDP, approvals as claims, credentials after a decision,
|
||||
evidence bound, PEP-shape of implementation runtimes)
|
||||
- Admission (ADR-0006) and exposure (ADR-0008) are live Railiance axes and
|
||||
are not yet demarcated in-repo from authorization decisions
|
||||
- Validation: rail/rapp/reef schemas and declaration checks are implemented
|
||||
- Active cross-repo work: OpenBao migration closeout remains partially blocked;
|
||||
public-listener retraction is in progress while destructive source cleanup
|
||||
|
|
@ -153,7 +192,8 @@ Intentional deviations and omissions:
|
|||
## How It Fits
|
||||
|
||||
- Upstream standards: `info-tech-canon`, `the-custodian` canon, Custodian
|
||||
workplan conventions
|
||||
workplan conventions, NetKingdom `security-layer-model` v0.7 and
|
||||
`SECURITY-COMPANION.md` v0.2 (consumption constitution, not authored here)
|
||||
- Downstream policy publisher: `policy-nexus` (ADRs only, read-only)
|
||||
- Downstream architecture consumers: all `railiance-*`, `rail-*`, `rapp-*`, and
|
||||
`reef-*` repositories
|
||||
|
|
@ -168,6 +208,8 @@ Intentional deviations and omissions:
|
|||
- Start with: `README.md`, `INTENT.md`, `SCOPE.md`
|
||||
- Architecture entry points: `docs/repository-axes.md`,
|
||||
`docs/reef-substrate-model.md`, `docs/adr/`
|
||||
- NetKingdom alignment review:
|
||||
`history/260829-demand-netkingdom-security-layer-alignment.md`
|
||||
- Machine-readable contracts: `schemas/`,
|
||||
`tools/validate-family-declarations.py`
|
||||
- Active and historical coordination: `workplans/`, `WORK-RECORDS.md`
|
||||
|
|
@ -202,5 +244,11 @@ keywords: [schema, validation, declaration, rail, rapp, reef]
|
|||
## Gap to Intent
|
||||
|
||||
The remaining alignment work is to complete downstream ADR publication, cleanly
|
||||
archive completed work without breaking State Hub conventions, and retain a
|
||||
repeatable canon-consumer review packet as the architecture evolves.
|
||||
archive completed work without breaking State Hub conventions, retain a
|
||||
repeatable canon-consumer review packet as the architecture evolves, and close
|
||||
the NetKingdom security-layer gap recorded in
|
||||
`history/260829-demand-netkingdom-security-layer-alignment.md` and tracked by
|
||||
`RMASTER-WP-0026`: a machine-readable layer declaration, a §20.2 consumption
|
||||
contract, a vocabulary split between admission/exposure and authorization, and
|
||||
assented answers to the five unsettled axis-to-layer questions. Do not invent
|
||||
the mapping, host a PDP, or take PEP shape in this repository.
|
||||
|
|
|
|||
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.
|
||||
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