zone-engine/workplans/ZONE-WP-0001-security-zone-model.md

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	created	updated	state_hub_workstream_id
ZONE-WP-0001	workplan	The security zone model — derive it from the estate, draft it as canon	infotech	zone-engine	proposed	zone-engine	netkingdom	P1	2026-08-19	2026-08-19	a75c8c9c-c108-4831-8d72-4343cce49879

ZONE-WP-0001 — The security zone model

Ported from WARDEN-WP-0032 (ops-warden), which deferred policy.enabled: true under ADR-0006 and named this repo as its successor. ops-warden keeps only its consumer-side task.

This workplan produces a model and a canon draft. It does not produce an API, a schema, or storage. An engine that ships a schema before it has partitioned the real estate defines the model by accident, through whatever its first wire format happened to be. Whether a runtime is warranted is an output of T02–T03, not an assumption of T01.

The gap in one table

Axis	Shipped	Answers
Environment posture (dev/test/prod)	ops-warden WP-0015	Where does this run?
Workload maturity (M0–M3)	ops-warden WP-0015	How ready is this workload?
organization_posture: build	ops-warden WP-0029	What state is the org in?
Enforcement stance	missing	Is this control enforced here, and what happens when it fails?

The first three describe. Nothing decides. That is why policy.enabled is a repo-wide boolean, and why turning it on would have hardened the access needed to perform the refactors currently underway.

Do not reinvent these

net-kingdom/canon/standards/tenancy-posture_v0.1.md — the structural model to follow: orthogonal axes, graduated levels, a per-repo declaration (tenancy.yaml) with current/implemented/target vectors, evidence, and a review date; §6 conformance is accuracy, not altitude; §14 adoption stance structure, not tooling. That last one is why this workplan is shaped as it is.

Reefs (repo-manager/docs/RailianceAppDeploymentGuide.md) — reef-railiance carries a single-node/shared-control-plane residual risk requiring explicit acceptance. Substrate placement with risk attached is adjacent to a zone and must be reconciled with it, not duplicated. repo-manager's own rule — topology is not readiness — restates here as placement is not posture.

flex-auth — the PDP, service_class: latency-critical, already consuming a compiled registry snapshot built by ops-warden/scripts/build_flex_auth_registry.py. Zone membership reaches the decision point by compilation. A synchronous zone lookup in the decision path would be a regression dressed as an architecture.

warden plan (ops-warden WP-0029) — already returns autonomous/founder_required/unroutable from properties of the thing, with the reasons that produced the verdict. Zone-aware enforcement extends that machinery; it does not grow a second vocabulary beside it.

Tasks

id: ZONE-WP-0001-T01
status: todo
priority: high
state_hub_task_id: "ea74316e-b711-4888-9b38-553ebc9ad856"

Confirm ownership on the record, and say what publishes where. This repo was seeded on a recommendation, not yet on agreement. Take to net-kingdom (canon) and flex-auth (the enforcing PDP): zone-engine owns the model and the exception lifecycle; canon publishes the standard, in the family of tenancy-posture_v0.1 and the *-engine boundary contracts; flex-auth stays the only PDP and consumes compiled membership.

If either disagrees, the model moves and this repo is archived rather than kept for its own sake. Record the outcome either way.

id: ZONE-WP-0001-T02
status: todo
priority: high
state_hub_task_id: "f1016c71-ccb0-46a7-9143-e81c7ac34cad"

Derive the zones from the real estate. Walk ops-warden's 27 catalog lanes, the adm/agt/atm actor inventory, and the workloads carrying posture descriptors. The model's test is that it partitions what exists without a residue of unexplained exceptions — and the exceptions found are the most informative output, not noise to tidy away.

Answer explicitly:

• Is a zone a property of the actor, the lane, the workload, or the moment? The CoulombCore decommission and the issue-core move show the last is real and hardest to model. A time-boxed relaxation is a different object from a standing zone; conflating them yields a permanent hole with a temporary-sounding name.
• Do zones compose with or fold in the three existing axes? A fourth independent axis multiplies states; absorbing organization_posture may be the honest move.
• How do zones relate to reefs? State it in the model rather than leaving readers to guess.

id: ZONE-WP-0001-T03
status: todo
priority: high
state_hub_task_id: "7f47b750-1ae4-467d-b3c4-064f4ec07dbd"

Model stance and failure mode, per control per zone. Enforced / advisory / exempt, and fail-closed or fail-open. The failure mode is where the bite is: fail_closed is what turns a dead tunnel into an outage, and is precisely why the ops-warden flip was deferred.

Controls in scope at minimum: the flex-auth pre-sign gate (policy.enabled, fail_closed), the agent read-boundary on risk: high lanes (ops-warden ADR-0004), and the warden plan escalation verdicts.

id: ZONE-WP-0001-T04
status: todo
priority: high
state_hub_task_id: "1c542ca5-2b82-4778-a3e4-c76e932423c9"

Design the time-boxed exception — this is the load-bearing task. A standing classification needs no engine; canon plus a declaration file covers it. An exception with an expiry is state, and state wants an owner. Whether this repo earns a runtime is decided here.

Must specify: who may grant, against which zone and control, for how long, with what recorded justification; how expiry is enforced rather than intended; how an active exception is visible to someone who did not grant it; and what happens at expiry — auto-revert, or block until renewed.

If T04 concludes the lifecycle can live as reviewed declarations in git, say so plainly and drop the runtime. That is a valid and cheaper outcome.

id: ZONE-WP-0001-T05
status: todo
priority: medium
state_hub_task_id: "f4556ca0-cb26-46ed-9351-d00270bd2309"

Declaration format and conformance rule. Follow tenancy.yaml: per-repo, with evidence, reviewed, and review_due; carry over accuracy, not altitude. Include how a zone assignment changes and how that change is observed — a zone that can be quietly widened is not a boundary.

id: ZONE-WP-0001-T06
status: todo
priority: medium
state_hub_task_id: "8a000c18-6ee7-4328-99c7-53c490435316"

Draft the canon standard and offer it. security-zones_v0.1.md for net-kingdom/canon/standards/, drafted here, published there. Owner-driven landing, as ops-warden's WP-0015 maturity model was.

id: ZONE-WP-0001-T07
status: todo
priority: medium
state_hub_task_id: "c7ea24df-8aa9-4ead-ba3a-033aa5201c21"

Prove it on two consumers. A model only its author honours is not adopted. The first is ops-warden: retire policy.enabled for a zone-aware control, closing WARDEN-WP-0031-T05. Re-run ops-warden/scripts/check_policy_caller_identity.py first — the 2026-08-19 evidence (decision:f3f7c88f9585582a) will be stale, and re-establishing it is cheap by design. The second consumer comes from T01.

Related

• ops-warden ADR-0006 — enforcement is zone-scoped, never a global flag
• ops-warden WARDEN-WP-0032 — the ops-warden-side stub this was ported from
• ops-warden WARDEN-WP-0031 — the deferred flip, and the readiness evidence
• flex-auth FLEX-WP-0016 — the enforcing pin with no enforcing consumer
• net-kingdom/canon/standards/tenancy-posture_v0.1.md
• repo-manager/docs/RailianceAppDeploymentGuide.md — reefs