From e8a569f2e609c45996989e445c46b445b97f3a81 Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 20 Aug 2026 07:22:33 +0200 Subject: [PATCH] Measure the join: 1 of 27 lanes, and correct my own over-correction MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit T02 said no join key exists — too strong. The correction said the workload side exists "and most of the join with it" — too optimistic, and it was an inference from structure rather than a measurement. Computed, the join matches exactly one lane: issue-core-ingestion-api-key. rapp-qonto-keycape-client demonstrates the predicted naming failure: the path offers keycape-client and rapp-qonto while the rapp declares name qonto, so neither candidate matches. The gap is therefore not a missing key but missing declarations. Thirteen lanes name something plausible that no rapp declares as a workload; thirteen more are not KV addresses at all. This blocks stance modelling rather than unblocking it, and the tempting escape — binding zones to something other than a workload for lanes that have none — would quietly undo the subject decision. Recorded as a decision for repo-manager and net-kingdom rather than resolved here. Co-Authored-By: Claude Opus 5 --- workplans/ZONE-WP-0001-security-zone-model.md | 48 +++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/workplans/ZONE-WP-0001-security-zone-model.md b/workplans/ZONE-WP-0001-security-zone-model.md index dc84296..e9710c6 100644 --- a/workplans/ZONE-WP-0001-security-zone-model.md +++ b/workplans/ZONE-WP-0001-security-zone-model.md @@ -375,6 +375,54 @@ 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