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

docs: declare Engine/PIP under security-layer-model v0.7

Browse source 
Assent to ZONE-IN-0001 in this repository's own voice: layer Engine, role
PIP, offline reference remaining the catalogued surface. Align INTENT,
SCOPE, and GOAL with accepted statute v0.7 and companion v0.2. Record the
scope-against-intent review and open ZONE-WP-0003 for the mechanical
remainder. Do not reopen the no-runtime decision.

Assistant: grok
Assistant-Session: 01a04ceb-0745-7ae1-9e26-0d10e5d52b8b
This commit is contained in:
tegwick 2026-08-29 11:57:25 +02:00
parent 1b9a252fa3
commit a34bc194dc
6 changed files with 704 additions and 88 deletions
Download patch file Download diff file Expand all files Collapse all files

47
GOAL.md
View file

@ -17,21 +17,26 @@ expires on its own.
## Invariants
- **`flex-auth` remains the only policy decision point.** zone-engine is
authority over zone **identity and membership**; the **effect** of a zone on
any decision flex-auth renders is expressed in a flex-auth policy package.
- **`access-engine` remains the only policy decision point.** It is the ruled
name for the repository currently called `flex-auth`. zone-engine is the
Engine-layer **PIP** for zone **identity and membership**; the **effect** of
a zone on any decision `access-engine` renders is expressed in an
`access-engine` policy package or as a claim on the request (security layer
model v0.7 §6, §18).
The first draft of this invariant said "nothing this repo builds sits
synchronously in a decision path". flex-auth rejected that on review: it is a
*latency* guarantee, not an authority one. Compiled data that determines an
outcome is still deciding — it just decided earlier. Under the old wording
zone-engine could compile `enforced: false` for a lane, flip `warden sign`
from deny to allow with no flex-auth policy change, and be literally
compliant. Membership is ours; stance is theirs.
- **Compiled, not queried.** Membership reaches flex-auth by compilation into
the registry it already loads. This is a *consequence* of the invariant
above, not the invariant itself — flex-auth is `service_class:
latency-critical` and loads its registry once at process start.
from deny to allow with no policy-package change, and be literally
compliant. Membership is ours; stance is theirs; the decision point is
neither.
- **Compiled, not queried.** Membership reaches `access-engine` by compilation
into the registry it already loads, as a PIP fact, never as stance. This is
a *consequence* of the invariant above, not the invariant itself —
`access-engine` is `service_class: latency-critical` and loads its registry
once at process start.
- **A zone that can be quietly widened is not a boundary.** Every change of
stance is observable, and every exception has an enforced expiry.
- **Accuracy, not altitude** (`tenancy-posture_v0.1` §6). A repo declaring a
@ -64,15 +69,23 @@ runtime exists with an owner or the decision that none is needed is recorded.
It does not reopen the no-runtime decision; it makes the retained artifacts
truthful enough for an explicit archive-or-maintain decision.
`ZONE-WP-0003` is the owner-driven revision that follows from security layer
model v0.7 being accepted. It declares the Engine/PIP layer, records the
already-completed layer cut, and evolves the reference surface so zone facts
can be consumed as claims. It does not add a live API, a decision surface, or
a PEP.
## Retirement decision — 2026-08-23
Retain the repository as an offline reference-conformance repository while the
canonical v0.1 standard remains `proposed`. The maintainer is zone-engine; the
maintenance surface is limited to canon lineage, conformance fixtures, and
concrete owner-driven revisions. There is no service or routine delivery
backlog.
canonical `security-zones_v0.1` standard remains `proposed`. The maintainer is
zone-engine; the maintenance surface is limited to canon lineage, conformance
fixtures, and concrete owner-driven revisions. There is no service or routine
delivery backlog. The 2026-08-29 layer declaration is one such revision: the
security layer model is **accepted**; the zone standard is still **proposed**;
the catalogued form stays offline.
Reassess archival when net-kingdom accepts or supersedes v0.1, when the fixtures
are durably adopted by canon/control owners, or when no adopting control needs
the reference. An actual Forgejo archive or rename remains attended operator
work.
Reassess archival when net-kingdom accepts or supersedes `security-zones_v0.1`,
when the fixtures are durably adopted by canon/control owners, or when no
adopting control needs the reference. An actual Forgejo archive or rename
remains attended operator work.

175
INTENT.md
View file

@ -1,37 +1,74 @@
# INTENT
---
layer: Engine
role: PIP
standard: netkingdom-security-layer-model
standard_version: "0.7"
companion: net-kingdom/SECURITY-COMPANION.md
---
> **NetKingdom layering review — 2026-08-28.** This repository's role was reviewed
> against the NetKingdom IT-security layer model: **Taxonomy → Tooling → Engines →
> Staff**, layered by determinism and by the kind of artifact each layer produces.
> Findings and the argument behind them:
> `gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md`.
> The model is `net-kingdom/canon/standards/security-layer-model_v0.1.md` (proposed),
> ratified by `gate-house/decisions/decisions.md` GH-DEC-2026-001.
>
> The layer rule that binds every repository: **Staff never touches tooling
> directly. It acts only through engine APIs.**
>
> **This repository is Engine — currently retained as offline reference conformance.** No change to the 2026-08-23 disposition. Note that §5 of this file — *"flex-auth is the policy decision point. It stays the only one."* — is the precedent the whole review turned on, and it now generalizes: gate-house is Staff and is not a second decision point either. The falsifier in §7 ("it becomes a second decision point… it would arrive as a small convenience") is adopted estate-wide. References to flex-auth by name will need updating when the rename to access-engine lands.
>
> *This note records what should change. The body below is not yet adapted.*
# INTENT
> Why `zone-engine` exists and where it is going.
> What is true today is `SCOPE.md`. Checkable gates and the retirement
> condition are `GOAL.md`. This file is the argument, not the checklist.
> **Layer: Engine. Role: PIP.** This is the declaration required by NetKingdom
> Security Layer Model v0.7 §11 and working companion v0.2. It is this
> repository's own voice. A catalog row, a review note, or the 2026-08-28
> gate-house insert that used to sit here is not a declaration.
>
> The statute is
> `net-kingdom/canon/standards/security-layer-model_v0.7.md` (accepted
> 2026-08-29). The operative form is `net-kingdom/SECURITY-COMPANION.md` v0.2.
> On disagreement the statute governs, and a disagreement is a finding for
> `gate-house`.
>
> We produce a deterministic result for one modeled concept: zone identity and
> membership. Same authoritative inputs, same result. That is the Engine test.
> The PIP role means those facts reach a decision as **claims**, not as a
> verdict. We do not render, cache, or compile an authorization decision.
>
> The §4 catalog records the 2026-08-23 disposition rather than changing it:
> the current PIP surface is **offline reference conformance**, not a live API.
> Determinism does not require a network. A live Engine API, a decision
> surface, or stance compiled into membership would each be a layer change,
> and a layer change needs the six artifacts in statute §10, including a
> permission freeze. The 2026-08-23 cut already happened; it does not reopen
> by practice.
>
> **`access-engine` is the only PDP.** It is the ruled name for the repository
> currently called `flex-auth`. This file's original §5 — *"flex-auth is the
> policy decision point. It stays the only one."* — is the ruling the layer
> model generalizes as statute §6. The §7 falsifier — a second decision point
> arriving as a small convenience — is estate doctrine. Zone stance enters a
> decision as a claim on the request or a rule in a versioned policy package,
> never as compiled registry content (statute §18).
>
> We are not PEP-shaped: this repository causes no protected side effect and
> publishes no unreachable-engine stance map. We hold no Tooling-layer client.
> Staff never touches Tooling directly; we are not Staff, and we still do not
> hold a Tooling client, because a PIP that reaches into OpenBao would be
> deciding with someone else's state.
---
## Current disposition — 2026-08-23
## Current disposition — 2026-08-23, confirmed 2026-08-29
The argument below is retained as design history. Its desired sentence is now
sayable: the standard is in net-kingdom canon, ops-warden and flex-auth have
adopted it, the repo-wide switch is retired, and exception expiry is enforced
at each owning decision or enforcement point.
sayable: the zone standard is in net-kingdom canon, ops-warden and flex-auth
have adopted it, the repo-wide switch is retired, and exception expiry is
enforced at each owning decision or enforcement point.
The runtime hypothesis was falsified. zone-engine is retained only as an
offline reference-conformance repository while canon v0.1 remains proposed; it
is not an engine, PDP, exception service, or consumer policy owner. Current
capability is `SCOPE.md`, and the retain/archive triggers are in `GOAL.md`.
The runtime hypothesis was falsified. That was a layer change in practice
(statute §10 cites this case). zone-engine is retained as an Engine/PIP whose
surface is offline reference conformance while `security-zones_v0.1` remains
proposed. It is not a PDP, not a PEP, not an exception service, and not a
consumer policy owner. Current capability is `SCOPE.md`. Retain and archive
triggers are in `GOAL.md`.
The security-layer-model being accepted does not reverse that cut. It names
the cut: we are the PIP for zone identity and membership, in the form already
shipped.
## 1. The sentence this repo exists to make sayable
@ -39,10 +76,10 @@ capability is `SCOPE.md`, and the retain/archive triggers are in `GOAL.md`.
> band until Friday** — and all three of those are written down, reviewable, and
> expire on their own."*
At inception NetKingdom could not say that. It could say how exposed a workload was
(environment posture), how ready it is (`M0`–`M3`), and what state the
At inception NetKingdom could not say that. It could say how exposed a workload
was (environment posture), how ready it is (`M0`–`M3`), and what state the
organization is in (`organization_posture`). Every one of those **describes**.
None of them **decides**. So every enforcement control in the estate has been a
None of them **decides**. So every enforcement control in the estate was a
boolean over a whole repo.
## 2. Where that bit
@ -52,7 +89,7 @@ the gate verified clean. It was deliberately not switched on until the zone
model replaced its global scope.
`policy.enabled` is one boolean over the entire repo. With `fail_closed: true`
it makes flex-auth a hard dependency of *every* `warden sign` — including the
it makes the PDP a hard dependency of *every* `warden sign` — including the
SSH certificates the ops-bridge tunnels depend on, one of which carries the
policy call itself. Turning it on would have been correct for a settled
production lane and wrong for an estate in the middle of decommissioning one
@ -93,44 +130,54 @@ it decides something, so the model must carry:
- **Identity and membership** — an authoritative workload binding and its
responsible party's declared zone. Lanes, actors, paths and repositories are
inputs or caller context, never substitute policy subjects.
inputs or caller context, never substitute policy subjects. **This is the PIP
fact this repository owns.**
- **Admission** — a mechanical reconciliation of that declaration against the
zone floor and the workload posture. Missing identity, membership or evidence
remains `unknown`; it is never inferred into a permissive zone.
- **Stance per control** — enforced, advisory, or exempt.
remains `unknown`; it is never inferred into a permissive zone. Same
authoritative inputs, same result.
- **Stance per control** — enforced, advisory, or exempt. **Not ours.** The
effect of a zone on a decision belongs in a versioned `access-engine` policy
package, or as a claim on the request (statute §18).
- **Failure mode** — what happens when the control cannot run. This is where
the bite is; `fail_closed` is what turns a dead tunnel into an outage.
the bite is; `fail_closed` is what turns a dead tunnel into an outage. **The
PEP owner's**, declared ahead of time per statute §9.3.
- **Exceptions that expire without anyone remembering them.**
The last was the runtime hypothesis. A standing classification needs no engine
— canon plus a declaration file covers it, which is exactly how tenancy posture
works. The implementation proved that exception state can remain with the
control owner when `not_after` is evaluated where the effect occurs. That gives
it an owner, audit trail, and enforced deadline without a central service.
The last was the runtime hypothesis. A standing classification needs no live
engine — canon plus a declaration file covers it, which is exactly how tenancy
posture works. The implementation proved that exception state can remain with
the control owner when `not_after` is evaluated where the effect occurs. That
gives it an owner, audit trail, and enforced deadline without a central service.
## 5. The line this repo must not cross
`flex-auth` is the policy decision point. It stays the only one.
`access-engine` (currently `flex-auth`) is the policy decision point. It stays
the only one.
zone-engine is authority over zone **identity and membership**. The **effect**
of a zone on a decision flex-auth renders belongs in a flex-auth policy package,
because flex-auth's decision envelope stamps `matched_policy_version` and
`policy_package` — and registry content appears nowhere in that provenance. Put
stance in the registry and two decisions with the same policy version and the
same request can differ, with nothing in the audit trail explaining why.
of a zone on a decision `access-engine` renders belongs in an `access-engine`
policy package, because the decision envelope stamps `matched_policy_version`
and `policy_package` — and registry content appears nowhere in that provenance.
Put stance in the registry and two decisions with the same policy version and
the same request can differ, with nothing in the audit trail explaining why.
That boundary was drawn by flex-auth on review, against a first draft of ours
that got it wrong in an instructive way: the original invariant forbade sitting
*synchronously* in a decision path, which is a latency guarantee wearing an
authority guarantee's clothes. Compiled data that determines an outcome is still
deciding; it just decided earlier.
deciding; it just decided earlier. Statute §6.1 is that sentence, generalized.
**Held to, in one line: membership is ours, stance is theirs, and the decision
point is neither.**
A new engine is a PIP unless the statute is amended. We are already that PIP.
We will not become a second PDP by growing a convenient live lookup, a cached
verdict, or a profile that changes a live effect.
## 6. What success looks like from outside
These conditions are now met for the adopted v0.1 path:
These conditions are met for the adopted v0.1 path:
Someone who has never read this repo should be able to:
@ -145,6 +192,11 @@ Someone who has never read this repo should be able to:
If a reader has to come here to understand their own posture, the model has
failed at being a standard and has succeeded only at being a service.
Under the layer model, the same reader should also be able to say: zone
*facts* come from this PIP; zone *effect* lives in `access-engine` policy;
unreachable-engine *behaviour* is the PEP's declared stance. Three owners,
one reconstructable decision.
## 7. What would make this repo wrong
Stated up front, because a repo created on a recommendation should say what
@ -152,8 +204,9 @@ would falsify it:
- **The exception lifecycle turns out not to need a runtime.** This falsifier
triggered. Reviewed owner records plus decision-time expiry are sufficient.
The honest outcome is canon plus offline conformance tooling, not an engine.
Retention is bounded to the proposed-standard reference need in `GOAL.md`.
The honest outcome is canon plus offline conformance tooling, not a live
engine. Retention is bounded to the proposed-standard reference need in
`GOAL.md`.
- **The zones do not partition the real estate.** If the model needs a residue
of special cases to cover today's 27 routing lanes and actor inventory, it is
describing an aspiration, not a structure.
@ -161,16 +214,27 @@ would falsify it:
reading is the minimum evidence of a model rather than a preference.
- **It becomes a second decision point.** The failure would not announce itself;
it would arrive as a small convenience — a stance compiled into membership
"just for now".
"just for now", a live lookup "just for this consumer", a profile change that
alters a live effect with no policy-package revision. Statute §6 is this
falsifier, estate-wide.
## 8. What this repo deliberately will not become
Not a PDP. Not network segmentation — "zone" is overloaded and the routing sense
is someone else's word. Not a placement model: reefs answer *where a thing runs*
and are `repo-manager`'s, and the fact that `reef-railiance` caps availability
for everything bound to it is a canon composition problem (`NK-WP-0027`), not
ours. Not an owner of anyone's controls — the controls stay with the repos that
enforce them; this model only says where they bite.
Not a PDP. Not a PEP. Not network segmentation — "zone" is overloaded and the
routing sense is someone else's word. Not a placement model: reefs answer
*where a thing runs* and are Railiance's, and the fact that `reef-railiance`
caps availability for everything bound to it is a canon composition problem
(statute §20.3, originally `NK-WP-0027`), not ours. Not an owner of anyone's
controls — the controls stay with the repos that enforce them; this model only
says where they bite.
Not a live Engine API unless a later layer-change decision carries the six
§10 artifacts and obtains assent from the repositories whose boundaries move.
The catalogued offline form is the current Engine, not a temporary embarrassment.
Not an inventor of the estate request-claim schema. Statute §17 assigns that
artifact to Taxonomy. Until it exists, this PIP's resolver output is
reference-shaped membership, not a competing claim dialect.
## 9. Direction
@ -185,3 +249,8 @@ and the cheaper answer is a legitimate result, not a disappointment.
That direction is delivered. `ZONE-WP-0002` hardened the offline contracts and
made canon lineage, owner provenance, revision/delta evidence, and exception
fixtures executable without reopening the runtime decision.
What remains is to live inside the layer the estate has now named: declare the
PIP in a machine-readable form, keep the permission freeze, and evolve the
reference surface so zone facts can be consumed as claims when Taxonomy
publishes the schema — without growing a second decision point to get there.

83
SCOPE.md
View file

@ -8,24 +8,56 @@
## One-liner
`zone-engine` is the retained reference-conformance repository for NetKingdom
security-zone membership, admission, owner-provenanced control profiles, and
time-boxed exception semantics. It does **not** run an engine or make policy
decisions.
`zone-engine` is the Engine-layer **PIP** for NetKingdom zone identity and
membership, retained as an offline reference-conformance repository. It does
**not** run a live engine, render a policy decision, or cause a protected side
effect.
## Layer
Declared in `INTENT.md` frontmatter, in this repository's own voice:
| Key | Value |
| --- | --- |
| Layer | Engine |
| Role | PIP |
| Statute | `security-layer-model_v0.7` (accepted 2026-08-29) |
| Companion | `net-kingdom/SECURITY-COMPANION.md` v0.2 |
| Catalogued form | offline reference conformance (2026-08-23 disposition) |
| PEP-shaped | no |
| Tooling contacts | none |
| Conformance | conforming for Tooling contact; the live Engine API is not a missing capability this repository currently owes |
The machine-readable `layer.yaml` form and a conformance check that fails a
new Tooling client or a new decision surface are not yet evidenced here.
Until they are, the declaration is the `INTENT.md` frontmatter and the prose
in that file.
`access-engine` (currently `flex-auth`) is the only PDP. Zone stance and
failure mode remain owner policy and PEP configuration. This repository
projects only explicit versioned owner data and never changes a live effect.
## Lifecycle
`ZONE-WP-0001` delivered and proved the model. `ZONE-WP-0002` hardened the
retained reference boundary. Both are finished with `DoD-Ok`; no runtime is
needed and there is no continuing implementation backlog.
needed.
The repository is retained while `security-zones_v0.1` remains `proposed` in
net-kingdom canon, with zone-engine as maintainer of fixtures and reference
tooling. Retention is not service ownership. A future canon lifecycle change,
an owner-requested conformance revision, or evidence that an adopting control
cannot enforce the contract at its existing point are the only normal change
triggers. Archival remains an attended action once the reference artifacts are
durably handed off or no longer needed.
tooling. Retention is not service ownership. Acceptance of the security layer
model does not reopen the no-runtime decision; it names the retained form as
the Engine/PIP this repository already is.
Normal change triggers remain: a canon lifecycle or content change, an
owner-requested conformance revision, or evidence that an adopting control
cannot enforce the contract at its existing point. The layer declaration and
the PIP claim-mapping work that follow from v0.7 are owner-driven revisions
of that kind. Archival remains an attended action once the reference
artifacts are durably handed off or no longer needed.
A live Engine API, a decision surface, or stance compiled into membership
would be a layer change and is out of present scope.
## Capability actually present
@ -59,6 +91,10 @@ ambiguous join, read a live clock, or publish a consumer registry. Its profile
fixture records owner-approved v0.1 behavior; only the referenced owner policy
and PEP configuration can change a live effect.
The resolver output is a reference membership/admission record. It is not yet
a statute §17 request-claim. Taxonomy owns that schema and has not published
it. This repository must not ship a competing dialect.
## Authority boundary
| Concern | Authority | This repository's role |
@ -67,13 +103,17 @@ and PEP configuration can change a live effect.
| Managed workload tuple and applicability | Repo Manager / owning catalog | Consumes the explicit projection |
| Zone ids and admission standard | zone-engine model, published by net-kingdom | Maintains conformance fixtures and lineage |
| Canon publication and lifecycle | net-kingdom | Detects change; never promotes by inference |
| Control stance | Owner of the control | Projects only explicit versioned owner data |
| Layer model and engine roles | gate-house / net-kingdom canon | Declares Engine/PIP; does not author the statute |
| Request-claim schema | Taxonomy (statute §17, unassigned) | Will consume, not invent |
| Control stance | Owner of the control; effect in `access-engine` policy | Projects only explicit versioned owner data |
| Failure behavior | Owner of the PEP | Records provenance and semantics only |
| Authorization effect | Existing PDP or control owner | Makes no decision |
| Authorization effect | `access-engine` (currently `flex-auth`) | Makes no decision; supplies PIP facts |
| Exception grant and expiry | Designated control authority and enforcement point | Checks reusable fixtures offline |
| Reef placement vs zone floor | Railiance / canon composition (statute §20.3) | Keeps the axes separate; does not compose them |
The invariant remains: **membership is ours; stance is theirs; the decision
point is neither.** `flex-auth` remains the only PDP for decisions it renders.
point is neither.** `access-engine` remains the only PDP for decisions it
renders.
## Deliberately absent
@ -81,12 +121,15 @@ There is no:
- API, daemon, database, controller, scheduler, watch loop, or reload path;
- synchronous lookup in an authorization or enforcement path;
- authorization decision surface, cached verdict, or compiled stance;
- PEP, unreachable-engine stance map, or protected side effect;
- Tooling-layer client (OpenBao, key-cape, or a direct datastore);
- central exception store, grant workflow, clock, or expiry evaluator;
- live policy evaluation or implementation of another repository's control;
- fleet discovery, reference repair, registry publication, or workload
migration;
- network segmentation, reef placement, tenancy, identity, or secrets service;
or
- estate request-claim schema, or authority to publish one; or
- authority to publish canon or select a consumer's stance and failure mode.
Exception expiry remains enforced at decision or enforcement time by each
@ -99,16 +142,24 @@ decision point.
- Checking direct declarations or explicit Repo Manager projections offline.
- Verifying a versioned owner profile is total and fully attributed.
- Testing an owner exception implementation against the lifecycle boundaries.
- Reviewing a net-kingdom canon lifecycle/content change.
- Reviewing a net-kingdom canon lifecycle/content change, including the
security-layer-model.
- Declaring or checking this repository's Engine/PIP conformance.
- Auditing why no zone-engine runtime exists.
## Not relevant when
- Determining the published rule: read net-kingdom canon.
- Asking whether a request is allowed: use `flex-auth` or the owning control.
- Asking whether a request is allowed: use `access-engine` or the owning
control.
- Discovering or repairing managed workloads: use Repo Manager and the owning
catalog.
- Granting, applying, or expiring a live exception: use the control owner's
versioned policy or PEP configuration.
- Placing a workload, routing a network, managing identity/tenancy, or handling
secrets.
- Publishing an unreachable-engine stance, containing a workload, or observing
production: those are PEP, actuation, and `kings-guard`, and the last two
are held at zero by the statute.
- Mapping Railiance `reef-*` onto security zones: statute §20.3 leaves that
composition unwritten; guessing it here is out of scope.

221
history/2026-08-29-security-layer-model-scope-against-intent.md Normal file
View file

@ -0,0 +1,221 @@
---
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`.

16
intakes/intakes.md
View file

@ -7,7 +7,9 @@ id: ZONE-IN-0001
kind: intake
title: 'Declaration requested: state this repository''s layer in INTENT.md (security
layer model §11)'
status: open
status: closed
outcome: absorbed
promoted_to: ZONE-WP-0003
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.4 §11
priority: low
@ -34,5 +36,15 @@ description: 'A conformance sweep on 2026-08-28 found this repository has no lay
repository actually does, that is more useful to us than a label added to close
a checkbox. Standard: net-kingdom/canon/standards/security-layer-model_v0.4.md.'
created: '2026-08-28T21:02:13.994597Z'
updated: '2026-08-28T21:02:13.994597Z'
updated: '2026-08-29'
closed: '2026-08-29'
resolution: >-
Assent to the proposed Engine layer, with PIP as the role the v0.7 catalog
already recorded. Declaration is in INTENT.md frontmatter (layer: Engine,
role: PIP) and prose, against security-layer-model_v0.7 and companion v0.2,
in this repository's own voice. The 2026-08-23 offline reference form is the
catalogued PIP surface, not a contest of the layer. Mechanical remainder
(layer.yaml, conformance check, §10 freeze record, claim-boundary note) is
ZONE-WP-0003. Full review:
history/2026-08-29-security-layer-model-scope-against-intent.md.
```

250
workplans/ZONE-WP-0003-security-layer-model-alignment.md Normal file
View file

@ -0,0 +1,250 @@
---
id: ZONE-WP-0003
type: workplan
title: "Declare Engine/PIP and freeze the offline zone-membership surface"
domain: infotech
repo: zone-engine
status: ready
owner: zone-engine
assignee: grok
lane: yellow
topic_slug: netkingdom
planning_priority: P1
created: "2026-08-29"
updated: "2026-08-29"
origin: "history/2026-08-29-security-layer-model-scope-against-intent.md"
context_paths:
- "GOAL.md"
- "INTENT.md"
- "SCOPE.md"
- "README.md"
- "intakes/intakes.md"
- "history/2026-08-23-retain-reference-decision.md"
- "history/2026-08-29-security-layer-model-scope-against-intent.md"
quality_dor: DoR-Ok
quality_dor_at: "2026-08-29"
quality_dor_by: grok
quality_dor_note: "Gaps are evidenced against security-layer-model v0.7, companion v0.2, and the shipped offline resolver; owners, stop conditions, and the no-runtime freeze are explicit."
---
# ZONE-WP-0003 — Declare Engine/PIP and freeze the offline zone-membership surface
## Goal
Make this repository a conforming Engine-layer PIP under NetKingdom Security
Layer Model v0.7 without reversing the 2026-08-23 no-runtime decision. Declare
the layer in a machine-readable form, close the declaration intake, record the
already-completed layer cut, and map current membership output onto the facts
a future request-claim must carry.
Source review: `history/2026-08-29-security-layer-model-scope-against-intent.md`.
Statute: `net-kingdom/canon/standards/security-layer-model_v0.7.md`.
Companion: `net-kingdom/SECURITY-COMPANION.md` v0.2.
`INTENT.md` already declares `layer: Engine` and `role: PIP` in this
repository's own voice. This workplan makes that declaration checkable and
closes the remaining documentary gaps. It does not add a live API.
## Why these gaps are the relevant ones
| Priority | Gap | Why address it here |
| --- | --- | --- |
| P0 | No `layer.yaml` or conformance check | Statute §11 is mechanical; a new Tooling client or decision surface would land as the small convenience §6 warns about |
| P0 | `ZONE-IN-0001` still open after the declaration | gate-house asked for our voice; §14 still counts us among the silent nine |
| P1 | Statute §10 artifacts for the 2026-08-23 cut are incomplete | The procedure was written from this case; the freeze is the checkable piece |
| P1 | `README.md` still names only `flex-auth` | Consumer-facing docs must use the ruled PDP name |
| P1 | Resolver output is membership, not a claim | Statute §18 wants claims; §17 forbids inventing the schema here |
A live Engine API, a PEP stance map, compiled stance, reef/zone composition,
and the `flex-auth` repository rename are intentionally excluded.
## Authority and dependencies
- **gate-house / net-kingdom** own the statute and the §4 catalog. This plan
declares into that catalog; it does not edit it.
- **`access-engine` (currently `flex-auth`)** owns the PDP, policy packages,
and the governed rename. This plan uses the ruled name in prose and leaves
fixture owner identities as `flex-auth` until that rename lands.
- **Taxonomy** owns the request-claim schema (statute §17, unassigned). This
plan offers a field mapping, not a schema.
- **zone-engine** owns the declaration, the conformance check, the freeze
record, and the PIP mapping note.
- **Operator action** is not required. No archive, rename, or service
deployment is in this plan.
## Boundaries
- Do not add an API, daemon, database, controller, scheduler, or reload path.
- Do not expose an authorization decision surface or cache a verdict.
- Do not compile stance into membership or change a live effect from a local
profile edit.
- Do not publish a PEP stance map; this repository is not PEP-shaped.
- Do not invent the estate request-claim schema.
- Do not map `reef-*` onto security zones.
- Do not treat observation-in-production or automatic containment as available.
- Do not fold `ZONE-WP-0001` or `ZONE-WP-0002` back open.
- Leave fixture `policy_owner` / source identities as the actual repository
names they pin.
## T01 - Machine-readable layer declaration and conformance check
```task
id: ZONE-WP-0003-T01
status: todo
priority: high
```
Add `layer.yaml` in the kings-guard no-contact shape, pointing at security
layer model v0.7:
- `layer: engine`
- `role: pip`
- `tooling_contacts: []`
- `non_tooling_clients` lists any State Hub / work-record client, recorded
as not-catalogued
- no `pep_stance` path
- catalog note: §4 Engine / PIP; offline reference conformance per the
2026-08-23 disposition
Add `tools/check_layer_conformance.py` and a unit test. The check must fail
if:
- `layer.yaml` is missing, unparseable, or disagrees with `INTENT.md`
frontmatter;
- a Tooling-layer client import appears under `tools/` (OpenBao/Vault,
cluster, direct datastore);
- a new HTTP authorization decision surface appears.
Wire it into `make check`. Review dates, if any, are reported, never used as
a calendar-day build failure.
**Done when:** `layer.yaml` is committed, agrees with `INTENT.md`, `make check`
covers it, and a reviewer can see there are no Tooling contacts, no PEP
claim, and no decision surface.
## T02 - Close ZONE-IN-0001 and notify gate-house
```task
id: ZONE-WP-0003-T02
status: todo
priority: high
```
Close `ZONE-IN-0001` in `intakes/intakes.md` with outcome `absorbed` /
promoted to this workplan, recording that the proposed Engine layer is
assented in this repository's own voice and that the offline PIP form is the
catalogued surface, not a contest.
Notify `gate-house` (State Hub message or equivalent durable notice) that
zone-engine has declared Engine / PIP under v0.7 so statute §14 can stop
counting this repository among the undeclared nine.
**Done when:** the intake file is closed with a resolution that points at
`INTENT.md` and this workplan, and the notice to `gate-house` exists.
## T03 - Record the §10 artifacts for the 2026-08-23 layer cut
```task
id: ZONE-WP-0003-T03
status: todo
priority: medium
```
Write a short retrospective under `history/` (or a `docs/` note cited from
`INTENT.md`) that gathers the six statute §10 artifacts for the already
completed cut:
| Artifact | Source |
| --- | --- |
| before/after `INTENT.md` | 2026-08-23 retain text vs 2026-08-29 declaration |
| client inventory | none against Tooling; offline Python tools only |
| gap inventory | none as §5.3 contacts; live Engine API is not a gap this repo currently owes |
| assent list | flex-auth / ops-warden adoption already evidenced; no new boundary moves |
| state-migration decision | `history/2026-08-23-retain-reference-decision.md` |
| permission freeze | no live API, no decision surface, no compiled stance until a later cut carries its own six artifacts |
**Done when:** a reviewer can find all six artifacts without reconstructing
them from workplan history, and `INTENT.md` or `SCOPE.md` cites the note.
## T04 - Align remaining consumer-facing naming
```task
id: ZONE-WP-0003-T04
status: todo
priority: medium
```
Update `README.md` so a first-time reader sees Engine / PIP, offline
reference, and `access-engine` as the ruled PDP name (currently `flex-auth`).
Do not rewrite historical evidence, workplan files, or fixture owner
identities.
Confirm `GOAL.md` invariants already match; only patch if T01–T03 drift them.
**Done when:** `README.md`, `INTENT.md`, `SCOPE.md`, and `GOAL.md` agree on
layer, role, and PDP name, and `git grep access-engine README.md INTENT.md
SCOPE.md GOAL.md` is the consumer-facing surface.
## T05 - PIP claim-boundary note, without a schema
```task
id: ZONE-WP-0003-T05
status: todo
priority: medium
```
Write `docs/pip-claim-boundary.md` that:
1. lists the facts this PIP owns today (authoritative identity, declared and
effective zone, admission result and reason, membership revision, source
and source revision);
2. maps those fields onto what a future statute §17 request-claim must carry
(issuer, freshness, zone membership — not stance, not failure mode);
3. states that stance and failure mode remain owner policy and PEP
configuration, consumed by `access-engine` as a claim or a versioned rule
(statute §18);
4. marks the mapping as a contribution to Taxonomy, not a published schema;
5. forbids a competing claim dialect and forbids compiling those facts into
registry content that determines an outcome.
Offer the note to `gate-house` / `net-kingdom` and to `access-engine`. Do not
wait on their assent to keep the freeze.
**Done when:** the note is cited from `SCOPE.md`, tests still pass unchanged,
and no new wire format has shipped.
## Acceptance criteria
- [ ] `layer.yaml` declares Engine / PIP, no Tooling contacts, no PEP map.
- [ ] `make check` fails a new undeclared Tooling client or decision surface.
- [ ] `ZONE-IN-0001` is closed on the own-voice declaration.
- [ ] `gate-house` has been notified.
- [ ] Statute §10 artifacts for the 2026-08-23 cut are gathered in one place.
- [ ] Consumer-facing docs use `access-engine` as the ruled PDP name.
- [ ] PIP facts are mapped for a future claim schema without shipping one.
- [ ] No live API, daemon, decision surface, or compiled stance was added.
## Out of scope
- A zone-engine API, daemon, database, controller, scheduler, or synchronous
lookup.
- Publishing a PEP unreachable-engine stance map.
- Compiling stance into registry content or changing owner policy.
- Inventing or publishing the estate request-claim schema.
- Mapping Railiance reefs onto security zones.
- The `flex-auth` → `access-engine` repository rename.
- Promoting `security-zones_v0.1` out of `proposed`.
- Archiving or renaming this Forgejo repository.
- Estate-wide reference migration of unresolved catalog entries.
## Stop conditions
Stop and return to the relevant owner if implementation would require any of
the following:
- adding zone-engine to a live authorization or enforcement path;
- making a local profile authoritative over an owner policy package;
- inventing a claim schema and presenting it as estate canon;
- cataloguing this repository as PEP-shaped;
- reversing the 2026-08-23 retain / no-runtime decision without a new §10
layer-change record and assent from the repositories whose boundaries move.