zone-engine/history/2026-08-29-security-layer-model-scope-against-intent.md

---
id: ZONE-REVIEW-2026-08-29-001
type: review
title: "Scope against intent under NetKingdom security layer model v0.7"
status: accepted
reviewed: "2026-08-29"
reviewer: grok
source: operator
consumer: zone-engine maintainers, gate-house, access-engine, ops-warden
resulting_workplan: ZONE-WP-0003
standards:
  - net-kingdom/canon/standards/security-layer-model_v0.7.md
  - net-kingdom/SECURITY-COMPANION.md
  - net-kingdom/canon/standards/security-zones_v0.1.md
---

# Review: scope against intent under security layer model v0.7

## 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 consuming control owners need to tell, without reconstructing
context from the 2026-08-28 gate-house insert:

- which layer and engine role this repository occupies, in its own voice;
- that the 2026-08-23 offline disposition is the catalogued PIP form, not a
  temporary embarrassment;
- that `access-engine` (currently `flex-auth`) remains the only PDP;
- which v0.7 obligations this repository already meets, which it still owes,
  and which it must refuse.

## Purpose fit

**Strong fit.** Statute §4 already catalogs `zone-engine` as Engine / PIP for
zone identity and membership, "offline reference conformance per its
2026-08-23 disposition". Statute §6 generalizes this repository's original
INTENT §5. Statute §10 writes the layer-change procedure from this
repository's runtime-falsified case. Statute §18 restates the membership /
stance split this repository already shipped.

`ZONE-IN-0001` asked for a layer declaration in this repository's own voice.
Companion §2 requires `layer:` and `role:` in `INTENT.md` frontmatter plus
prose. That declaration is now written. Remaining work is to make the
declaration mechanically checkable and to evolve the reference surface
without reversing the no-runtime decision.

## Evidence reviewed

- `net-kingdom/canon/standards/security-layer-model_v0.7.md` (accepted; §2–§6,
  §10, §11, §14, §18, §20.3)
- `net-kingdom/SECURITY-COMPANION.md` v0.2 (operative form; §1–§3, §8)
- `net-kingdom/canon/standards/security-zones_v0.1.md` (still `proposed`)
- `INTENT.md` and `SCOPE.md` before and after this review
- `GOAL.md`, `history/2026-08-23-retain-reference-decision.md`,
  `history/2026-08-23-scope-against-intent.md`
- `docs/canon-lineage.yaml`, `tools/resolve_zones.py`,
  `profiles/netkingdom-build-v0.1.yaml`, `Makefile`
- `intakes/intakes.md` `ZONE-IN-0001`
- Reference declarations: `ops-warden/layer.yaml`, `kings-guard/layer.yaml`
- Prior work: `ZONE-WP-0001` and `ZONE-WP-0002`, both `finished` / `DoD-Ok`

MCP tools for the State Hub were not exposed in this session. The REST
surface at `http://127.0.0.1:8000` answered as primary (`railiance01`).

## 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** in §4, proposed layer Engine, role PIP.

Companion §2: frontmatter `layer:` plus `role:` for engines, and prose in our
own voice.

Statute §3.3 / §4: we own zone identity and membership as a PIP. A new engine
is a PIP unless the statute is amended. Outage of a PIP is input degradation
at `access-engine` (§9.3), not a Staff fallback.

Statute §6 / §18: `access-engine` is the only PDP. Zone stance enters a
decision as a claim or a versioned policy rule, never as compiled registry
content. Compiled data that determines an outcome is still deciding.

Statute §10: the 2026-08-23 runtime-falsified cut is a layer change and must
carry six artifacts. The procedure was written from this case after the fact;
the artifacts are incomplete.

Statute §5 / §11: no undeclared Tooling contact. We are Engine, not Staff, so
the three Staff shapes are not our lane; we still must not hold a Tooling
client, and we must record non-Tooling clients so the check is total.

Companion §5 / statute §6.4: PEP obligations attach to runtimes that cause a
protected side effect. This repository does not. No stance map is owed.

Statute §17: the request-claim schema is Taxonomy's and is unassigned. Until
it exists, every engine that invents its own claim shape is the drift §17
exists to prevent.

Statute §20.3: reef-versus-zone composition is unwritten. This repository
already recorded that as a canon composition problem and must not guess a
mapping.

Statute §14: as of 2026-08-29 this repository is one of the nine §4
repositories that have not declared in their own voice. `ZONE-IN-0001` is
that request.

## Intent-to-scope map (after the 2026-08-29 rewrite)

| Intent claim | Present scope | Implementation |
| --- | --- | --- |
| Engine / PIP for zone identity and membership | Declared in `INTENT.md` frontmatter and prose | No `layer.yaml`; no conformance check |
| Offline reference is the catalogued PIP form | SCOPE names it; retain decision unchanged | Resolver, lineage, fixtures, 29 tests — shipped |
| Same inputs, same result | Offline tools are deterministic | `make check` covers resolver, exceptions, tests |
| `access-engine` is the only PDP | SCOPE / GOAL name the ruled name; fixtures still say `flex-auth` | No decision surface in this repo |
| Stance in policy package or as a claim, never registry | Profile projection is optional, versioned, owner-provenanced | Profile fixture still uses `flex-auth` as the owner identity, which is correct until the rename |
| Not PEP-shaped | SCOPE says no stance map | Nothing to publish; do not add one |
| No Tooling contact | SCOPE claims none | True of `tools/` (stdlib + PyYAML); not mechanically checked |
| Layer change already happened; freeze holds | INTENT states the freeze | §10 artifact set is incomplete |
| Exception expiry at the owning control | Offline checker, explicit instant | Shipped in `ZONE-WP-0002` |
| Consumers understand posture without reading this repo | Canon + owner declarations | Still true for the adopted v0.1 path |
| Request-claim schema | Explicitly out of scope to invent | Resolver emits membership records, not claims |
| Reef / zone composition | Out of scope to guess | Unchanged; statute §20.3 agrees |

## Gaps that are this repository's to close

These are the relevant remaining requirements. They are owner-driven
revisions under the 2026-08-23 retain contract, not a reopening of the
runtime.

### 1. The declaration is prose-plus-frontmatter, not yet a check

Companion §2 and statute §11 treat `INTENT.md` frontmatter as the declaration
surface, and they also offer `layer.yaml` plus a conformance script as the
estate working reference. `ops-warden` and `kings-guard` already ship that
shape. Without it, a new OpenBao client or a new `/authorize`-shaped helper
would land as a small convenience and nothing in `make check` would fail.

**Necessary:** a `layer.yaml` in the kings-guard no-contact shape, with
`layer: engine`, `role: pip`, empty `tooling_contacts`, recorded non-Tooling
clients, no `pep_stance` path; plus a checker that fails undeclared Tooling
imports and any authorization decision surface.

### 2. `ZONE-IN-0001` is still open

The intake asked for a declaration in this repository's own voice, or a
contest. The declaration is now written and does not contest the proposed
Engine layer. The intake should close against that answer and against
`ZONE-WP-0003` for the mechanical remainder. `gate-house` should be told so
statute §14 stops counting this repository among the silent nine.

### 3. Statute §10 artifacts for the 2026-08-23 cut are incomplete

The layer-change procedure requires: before/after `INTENT.md`, client
inventory, gap inventory, assent list, state-migration decision, and
permission freeze. The retain decision covers state migration. The 2026-08-29
`INTENT.md` is the after-declaration. Client inventory, gap inventory, assent
list, and an explicit freeze record are not yet written as one set.

**Necessary:** a short retrospective note, not a new runtime. The freeze is
the checkable piece: no live API, no decision surface, no compiled stance.

### 4. Consumer-facing naming still says only `flex-auth`

`INTENT.md`, `SCOPE.md`, and `GOAL.md` now use `access-engine` as the ruled
name and `flex-auth` as the current repository identity. `README.md` and
older evidence still do not. Fixtures that pin the actual flex-auth
declaration must keep that identity until the governed rename lands — they
are evidence, not vocabulary.

**Necessary:** `README.md` naming; leave fixture owner ids alone.

### 5. PIP output is membership, not a claim

Statute §18 says zone facts enter a decision as a claim or a policy rule.
The resolver emits a canonical membership/admission record. That is the
right fact set and the wrong envelope, and inventing the envelope here would
violate statute §17.

**Necessary:** a short PIP claim-boundary note that maps current resolver
fields onto the facts a future claim must carry, marks the mapping as a
contribution to Taxonomy rather than a schema, and forbids a competing
dialect. Do not wait by growing a live API.

## Gaps that are not this repository's to close

| Gap | Owner | Why not here |
| --- | --- | --- |
| Live Engine API / daemon | — | Retain decision forbids it; catalog records the offline form; §10 freeze |
| Compiling stance into registry content | `access-engine` policy packages | Original invariant; statute §6.1 / §18 |
| Registry-snapshot digest in decision provenance | `access-engine` (self-declared in §13) | A PDP provenance gap, not a PIP one |
| Request-claim schema | Taxonomy (§17, unassigned) | Inventing it here is the defect §17 exists to prevent |
| PEP unreachable-engine stance maps | PEP-shaped consumers; §13.1 register | We cause no protected side effect |
| Reef / zone composition | `railiance-master` + net-kingdom canon (§20.3) | Placement is not posture |
| Observation in production | `kings-guard`; currently unstaffed | Statute §2 / §12; do not cite it |
| Actuation / containment | Engine concept held at zero (§9.2) | Not ours to own or to assume |
| `flex-auth` → `access-engine` repository rename | `access-engine` governed migration | Touches this repo's prose later; not a zone-engine workplan |
| `security-zones_v0.1` remaining `proposed` | net-kingdom | Lineage already pins it; do not promote by inference |
| Estate-wide reference migration | Workload and catalog owners | `ZONE-WP-0002` already excluded this |

## Recommendation

Keep the repository as the catalogued offline PIP. Declare, check, and freeze.
Do not grow a service to look more like the word "engine". Close `ZONE-IN-0001`
on the declaration already written. Open `ZONE-WP-0003` for the mechanical
and documentary remainder only.

## Disposition of `ZONE-IN-0001`

**Assent to the proposed layer, with a form clarification rather than a
contest.** Engine is correct. PIP is the role the catalog already recorded.
The 2026-08-23 offline disposition is the current surface, not a decline of
the layer. Contesting would have been appropriate if the catalog had required
a live API; it does not.

Closed against the 2026-08-29 `INTENT.md` declaration. Mechanical remainder
is `ZONE-WP-0003`.