diff --git a/docs/estate-partition-2026-08-19.md b/docs/estate-partition-2026-08-19.md
index 38b15e2..d46646f 100644
--- a/docs/estate-partition-2026-08-19.md
+++ b/docs/estate-partition-2026-08-19.md
@@ -216,7 +216,7 @@ The missing join found in §4 is therefore not a tidy-up. **It is the model.**
 > **Corrected 2026-08-20.** "No registry carries a join key" was too strong — it
 > was concluded from ops-warden's catalog alone, the one place a *workload*
 > declaration would not live. `rapp-*/declarations/rapp.yaml` declares
-> `workload_identity` with `data_classification` and `criticality` for eight
+> `workload_identity` with `data_classification` and `criticality` for nine
 > workloads, and ops-warden's `dataclass_floor` already maps classification to
 > `M0`–`M3`. The chain exists and spans two repos. What is genuinely missing is
 > an explicit `workload:` field on catalog entries — the key is currently only
diff --git a/workplans/ZONE-WP-0001-security-zone-model.md b/workplans/ZONE-WP-0001-security-zone-model.md
index e9710c6..0d79012 100644
--- a/workplans/ZONE-WP-0001-security-zone-model.md
+++ b/workplans/ZONE-WP-0001-security-zone-model.md
@@ -337,7 +337,7 @@ it.** T02 concluded no registry carries a join key. That was too strong; it was
 derived from ops-warden's catalog alone, which is the one place a workload
 declaration would *not* live.
 
-`rapp-*/declarations/rapp.yaml` is the workload declaration surface. **Eight**
+`rapp-*/declarations/rapp.yaml` is the workload declaration surface. **Nine**
 rapps declare `workload_identity` (`name`, `principal`, `service_account`,
 `tenant`) together with `data_classification`, `criticality`
 (`low`/`medium`/`high`/`critical`), `readiness_state`, and `bound_reefs`.
@@ -366,7 +366,7 @@ blocking unknown:
 2. **Vocabulary mismatch.** rapps declare `public`, which `dataclass_floor` does
    not map. `rapp-policy-nexus` is `public` today, so the floor cannot grade it.
    One of the two vocabularies must move; canon owns `DataClassification`.
-3. **Coverage is partial.** Eight workloads are declared; ops-warden's catalog
+3. **Coverage is partial.** Nine workloads are declared; ops-warden's catalog
    yields ~17 distinct path identities. The unmatched remainder is the
    interesting set — it is where a lane exists for something that is not a
    declared workload at all.
@@ -375,54 +375,6 @@ This reopens the ownership question favourably: zone-engine does **not** need to
 build a workload registry. It needs to consume `rapp` declarations and ops-warden's
 `dataclass_floor`, and to ask ops-warden for one explicit field.
 
-### Measured 2026-08-20 — the join covers one lane in twenty-seven
-
-The correction above was itself too optimistic. Saying "the workload side exists,
-and most of the join with it" was an inference from structure; computing it gives
-a different answer. `ops-warden/scripts/report_workload_join.py`:
-
-```
-declared workloads (rapp-*):  8
-lanes matched to a workload:  1
-lanes unmatched:             13
-lanes with no usable path:   13
-```
-
-The single match is `issue-core-ingestion-api-key` → workload `issue-core`,
-`confidential`, `criticality: high`, floor `M2`.
-
-`rapp-qonto-keycape-client` does **not** match, and demonstrates the predicted
-failure exactly: the path offers `keycache-client` and `rapp-qonto`, while the
-rapp declares `workload_identity.name: qonto`. Neither candidate is the declared
-name.
-
-**So the gap is not a missing key. It is missing declarations.** Thirteen lanes
-name something plausible — `whynot-design`, `llm-connect`, `forgejo-admin`,
-`audit-core`, `email-connect`, `company-email` — that no rapp declares as a
-workload. Those are real running things holding real credentials, and the
-workload registry does not know they exist. Thirteen more lanes have no usable
-path at all: SSH, policy checks, tunnels, broker grants and pattern lanes, which
-are not KV addresses and never will be.
-
-**Consequence for the model, and it is a hard one.** A zone whose subject is the
-workload cannot govern a credential estate in which 26 of 27 lanes have no
-identifiable workload. T03 cannot proceed to stance modelling on this basis.
-Either:
-
-- **the declaration surface must grow** to cover what actually holds credentials
-  — which is `rapp`/`repo-manager` work, not zone-engine's, and is a far larger
-  ask than "add one field"; or
-- **zones bind to something other than a workload for the lanes that have none**
-  — which reopens the subject question that the operator's direction settled, and
-  should not be done quietly to make the model fit.
-
-The second is the tempting one and is how a model quietly becomes wrong. Take the
-first to `repo-manager` and `net-kingdom` before modelling further.
-
-The three defects listed above stand, but they are second-order next to this: an
-explicit `workload:` field on catalog entries is still worth having, and it does
-not help until there are workloads to point it at.
-
 **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