INTENT.md

@@ -35,30 +35,7 @@ security and becomes an outage with good intentions** — and the reason it woul
 have was structural: there was nowhere to say *where* it applies. The decision
 is ops-warden's `ADR-0006`; this repo is what it defers to.
 
-## 3. What policy is about, and who decides
-
-**Security policy is always about the actual workload.** Not the repository, not
-the credential, not the lane — the running thing, and whoever answers for it.
-
-That splits authority three ways, and the split is the model:
-
-| Role | Who | Authority |
-| --- | --- | --- |
-| **Suggests** | The repo providing the software | Recommends a posture for running its software. It does not know where it will run, so it cannot determine |
-| **Declares** | The workload and its responsible party | Sets the scrutiny actually applied. **The policy subject** |
-| **Requires** | The zone | The standard a workload must meet to be admitted. A floor, not a label |
-
-A workload is not *labelled* with a zone. It **qualifies** to run in one.
-
-This is not a new prescription mechanism. `tenancy-posture_v0.1` Decision 8.2
-already splits authority this way — the consuming repo owns its workload
-requirements, a tier minimum is owned separately, and the two are **joined by
-machine**, because *"a machine-checkable constraint must not depend on somebody
-remembering to collect a signature."* Decision 5.6 then ruled that stance
-*"behaves like a tier minimum under Decision 8.2."* The zone model's job is to
-**be** that tier minimum, not to invent a second way of requiring things.
-
-## 4. What a zone has to be, to be worth having
+## 3. What a zone has to be, to be worth having
 
 A classification that changes nothing is a label. A zone earns its keep only if
 it decides something, so the model must carry:
@@ -76,7 +53,7 @@ is exactly how tenancy posture works. **A relaxation with an expiry is state**,
 and state wants an owner, an audit trail, and something other than good
 intentions enforcing the deadline.
 
-## 5. The line this repo must not cross
+## 4. The line this repo must not cross
 
 `flex-auth` is the policy decision point. It stays the only one.
 
@@ -96,7 +73,7 @@ deciding; it just decided earlier.
 **Held to, in one line: membership is ours, stance is theirs, and the decision
 point is neither.**
 
-## 6. What success looks like from outside
+## 5. What success looks like from outside
 
 Someone who has never read this repo should be able to:
 
@@ -111,7 +88,7 @@ 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.
 
-## 7. What would make this repo wrong
+## 6. What would make this repo wrong
 
 Stated up front, because a repo created on a recommendation should say what
 would falsify it:
@@ -130,7 +107,7 @@ would falsify it:
   it would arrive as a small convenience — a stance compiled into membership
   "just for now".
 
-## 8. What this repo deliberately will not become
+## 7. 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*
@@ -139,7 +116,7 @@ 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.
 
-## 9. Direction
+## 8. Direction
 
 Model first, from the real estate. Canon standard drafted here and published by
 `net-kingdom`, in the family of `tenancy-posture_v0.1`. Membership declared in

SCOPE.md

@@ -31,12 +31,9 @@ and this repo is what that ADR defers to.
 
 ## In scope
 
-- **Zone identity and admission standards.** What zones exist, and the standard
-  a **workload** must meet to be admitted to one. Security policy is about the
-  running workload and whoever answers for it — the repo providing the software
-  only *suggests*. A zone is a floor a workload qualifies against, not a label
-  applied to it, and it is the `tenancy-posture` Decision 8.2 tier-minimum
-  mechanism rather than a new one.
+- **Zone identity and membership.** What zones exist, and what puts a lane,
+  actor or workload in one — derived from posture already declared rather than
+  a fourth hand-maintained list.
 - **Time-boxed exception lifecycle.** A relaxation with an expiry enforced by
   something rather than intended, plus the record of who widened what, when,
   and until when. **This is the task that decides whether this repo needs a

docs/estate-partition-2026-08-19.md

@@ -105,16 +105,7 @@ Two further gaps, less severe but structural:
 
 ### Is a zone a property of the actor, the lane, the workload, or the moment?
 
-> **Corrected 2026-08-19 by operator direction, after this analysis was
-> written.** The answer below ("the lane") mistook the corpus for the subject.
-> **Security policy is always about the actual workload.** ops-warden's catalog
-> is a credential surface, not a workload inventory, so lane properties were the
-> only thing available to partition — and partitioning what is available is not
-> the same as finding the policy subject. The bands in §2 stand as an accurate
-> description of ops-warden's credential surface and remain useful membership
-> *inputs*; they are not zones. See §7.
-
-**The lane**, on the evidence available in this corpus. Every field that discriminates —
+**The lane**, on the evidence. Every field that discriminates —
 `delegation.mode`, `exec_capable`, `risk` — is a lane property. The actor
 inventory holds 4 actors mapping to a single lane and cannot carry a partition.
 No lane references a workload.
@@ -160,66 +151,3 @@ and it is canon's, tracked as `NK-WP-0027`.
   graded** (`RISK-F-0003`). `delegation.mode` is usable today and is a better
   predictor.
 - Membership must be computed from the loaded model, not read from raw YAML.
-
-
----
-
-## 7. Correction — the subject is the workload, and a zone is an admission standard
-
-Operator direction, 2026-08-19, after §1–§6 were written:
-
-> *Security policy is always about the actual workload. The repository providing
-> the software may suggest security policy for running workloads in different
-> situations, but the workload — and whoever is responsible for it — defines the
-> level of scrutiny. Some zones may well define standards that have to be met in
-> order to run as a workload in that zone.*
-
-This reverses the direction the analysis above assumed. It had zones as a
-**classification derived from** properties. They are **bands with admission
-standards**: a workload does not get labelled with a zone, it *qualifies* to run
-in one.
-
-### Three roles, not one
-
-| Role | Who | Authority |
-| --- | --- | --- |
-| **Suggests** | The repository providing the software | Recommends a posture for running its software in given situations. A recommendation, never a determination — it does not know where its software will run |
-| **Declares** | The workload and its responsible party | Sets the level of scrutiny actually applied. **This is the policy subject.** |
-| **Requires** | The zone | Defines the standard a workload must meet to be admitted. A floor, not a label |
-
-### This is canon's existing mechanism, not a new one
-
-`tenancy-posture_v0.1` **Decision 8.2 — split authority, machine-reconciled**
-already partitions authority this way: the package repo owns substrate numbers
-and enforcement, *"the consuming repo owns its workload requirements"*, and a
-tier minimum is owned separately and **joined by machine** at definition and
-whenever either side changes — because *"a machine-checkable constraint must not
-depend on somebody remembering to collect a signature."*
-
-And Decision 5.6, ruling on this very standard, already said stance *"behaves
-like a tier minimum under Decision 8.2 — asserted elsewhere, joined by machine."*
-
-So the zone model does not need a new prescription mechanism. It needs to **be**
-a tier minimum: the zone asserts a floor, the workload asserts its posture, and
-the join is mechanical. That also resolves the grade-versus-acceptance split
-raised for T03 — they are simply the two sides of the join.
-
-### What this does to the bands in §2
-
-They survive as *inputs*, demoted from conclusions. `Decided` / `Fronted` /
-`Covered` / `Signposted` accurately describe ops-warden's credential surface and
-still predict where danger concentrates. What they cannot do is name the entity
-policy applies to, because ops-warden's catalog contains no workloads.
-
-The missing join found in §4 is therefore not a tidy-up. **It is the model.**
-Until something declares which workload consumes which lane, there is no subject
-to attach a standard to — and `M0`–`M3` already grades workloads, which is the
-side of the join that exists.
-
-### Build stage
-
-The organization is in `build`. The default stance is therefore permissive, and
-that is a positional fact rather than a concession: `ADR-0006` deferred a global
-gate for exactly this reason. Zones tighten by **admission to a zone**, not by
-raising a global floor — which is what makes the model compatible with deep
-refactoring instead of hostile to it.

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

@@ -222,15 +222,6 @@ Answer explicitly:
 
 **Done 2026-08-19.** Full result: `docs/estate-partition-2026-08-19.md`.
 
-> **Corrected the same day by operator direction, recorded in §7 of that
-> document.** Policy is about the **workload**, not the lane; the software repo
-> only *suggests*; the workload and its responsible party declare the scrutiny;
-> and a zone **requires** a standard for admission — a workload qualifies to run
-> in a zone rather than being labelled with one. This is `tenancy-posture`
-> Decision 8.2's tier-minimum mechanism, which Decision 5.6 had already said
-> stance would behave as. The four bands below survive as membership *inputs*,
-> not as zones.
-
 Four bands, each of the 27 lanes in exactly one — **Decided** (1, the only lane
 ops-warden decides), **Fronted** (10, owner has a front door), **Covered** (12,
 ops-warden proxies what it does not own), **Signposted** (4, routed, nothing
@@ -321,23 +312,6 @@ field repeats the error net-kingdom rejected when it refused stance as a
 tenancy axis. Model them as two fields: grade (derived, defaultable) and
 acceptance (asserted, owned, expiring).
 
-**Resolved by the T02 correction.** Grade and acceptance are the two sides of a
-Decision 8.2 join: the zone asserts a floor, the workload asserts its posture,
-and the join is mechanical. Not two fields to invent — one join to implement.
-
-**And the join is now the critical path.** ops-warden's catalog contains no
-workloads, so there is no subject to attach an admission standard to. `M0`-`M3`
-already grades workloads, which is the side that exists; what is missing is
-anything declaring which workload consumes which lane. T03 cannot produce a
-usable stance model until that is answered, and the honest answer may be that it
-belongs to whatever declares workloads — not to this repo.
-
-**Build stage is a positional fact, not a concession.** The organization is in
-`build`; the default stance is permissive and zones tighten by *admission*,
-rather than by raising a global floor. That is what makes this model compatible
-with deep refactoring instead of hostile to it, and it is the same reasoning
-that produced `ADR-0006`.
-
 **Amended by flex-auth 2026-08-19 — split membership from stance.** ops-warden's
 option (c) ("zones as policy-package data") was rejected wholesale because the
 model must govern two controls flex-auth does not evaluate. flex-auth agrees with