tegwick
38c450f4ab
Enforcement controls in this estate have been repo-wide booleans. ops-warden's flex-auth pre-sign gate was the first to become flippable, and flipping it would have made flex-auth a hard dependency of every warden sign — including the SSH certs the ops-bridge tunnels depend on, one of which carries the policy call. Uniform enforcement across an estate under deep refactor hardens exactly the access needed to perform the refactor. Deferred under ops-warden ADR-0006; this repo is what that ADR defers to. Seeded deliberately without a schema. ZONE-WP-0001 produces a model and a canon draft, not an API: an engine that ships a wire format before it has partitioned the real estate defines the model by accident. Whether a runtime is warranted is an output of the exception-lifecycle task, not an assumption. Invariants set now, because they are the ones easy to lose later: flex-auth stays the only PDP and receives membership by compilation, not a synchronous lookup in a latency-critical decision path; placement (reefs) is not posture; accuracy not altitude, per tenancy-posture v0.1 §6. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
7.3 KiB
| id | type | title | domain | repo | status | owner | topic_slug | planning_priority | created | updated |
|---|---|---|---|---|---|---|---|---|---|---|
| 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 |
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
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
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_posturemay 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
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
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
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
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
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.mdrepo-manager/docs/RailianceAppDeploymentGuide.md— reefs