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

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.