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

id	type	title	status	reviewed	reviewer	source	consumer	resulting_workplan	standards
ZONE-REVIEW-2026-08-29-001	review	Scope against intent under NetKingdom security layer model v0.7	accepted	2026-08-29	grok	operator	zone-engine maintainers, gate-house, access-engine, ops-warden	ZONE-WP-0003	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.