Correct the subject: policy is about the workload, and a zone is an admission floor

Operator direction. The T02 analysis concluded "a zone is a property of the
lane", which mistook the corpus for the subject — ops-warden's catalog is a
credential surface with no workloads in it, so lane properties were the only
thing available to partition. Partitioning what is available is not the same as
finding what policy applies to.

Three roles: the repo providing the software SUGGESTS a posture for running it;
the workload and its responsible party DECLARE the scrutiny applied, and are the
policy subject; the zone REQUIRES a standard for admission. A workload is not
labelled with a zone, it qualifies to run in one.

This is canon's existing mechanism, not a new one. Decision 8.2 already splits
authority this way and joins tier minima by machine, precisely so a checkable
constraint does not depend on someone remembering a signature; Decision 5.6
already ruled stance behaves as a tier minimum under it. It also dissolves the
grade-versus-acceptance question raised for T03 — they are the two sides of that
join.

Consequence: the four bands survive as membership inputs, demoted from
conclusions, and the missing lane-to-workload join is not a tidy-up. It is the
model. M0-M3 already grades workloads, which is the side of the join that exists.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

INTENT.md

@@ -35,7 +35,30 @@ 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 a zone has to be, to be worth having
+## 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
 
 A classification that changes nothing is a label. A zone earns its keep only if
 it decides something, so the model must carry:
@@ -53,7 +76,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.
 
-## 4. The line this repo must not cross
+## 5. The line this repo must not cross
 
 `flex-auth` is the policy decision point. It stays the only one.
 
@@ -73,7 +96,7 @@ deciding; it just decided earlier.
 **Held to, in one line: membership is ours, stance is theirs, and the decision
 point is neither.**
 
-## 5. What success looks like from outside
+## 6. What success looks like from outside
 
 Someone who has never read this repo should be able to:
 
@@ -88,7 +111,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.
 
-## 6. What would make this repo wrong
+## 7. What would make this repo wrong
 
 Stated up front, because a repo created on a recommendation should say what
 would falsify it:
@@ -107,7 +130,7 @@ would falsify it:
   it would arrive as a small convenience — a stance compiled into membership
   "just for now".
 
-## 7. What this repo deliberately will not become
+## 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*
@@ -116,7 +139,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.
 
-## 8. Direction
+## 9. 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,9 +31,12 @@ and this repo is what that ADR defers to.
 
 ## In scope
 
-- **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.
+- **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.
 - **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,7 +105,16 @@ Two further gaps, less severe but structural:
 
 ### Is a zone a property of the actor, the lane, the workload, or the moment?
 
-**The lane**, on the evidence. Every field that discriminates —
+> **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 —
 `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.
@@ -151,3 +160,66 @@ 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.