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>

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.