coulomb/railiance-master
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: align intent and scope with NetKingdom security-layer v0.7

Browse source 
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 2026-08-29 11:47:56 +02:00
parent 22d88db056
commit fb0c038eb6
5 changed files with 528 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

116
INTENT.md
View file

@ -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?**