coulomb/zone-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Correct T02's "no join key": the workload side exists in rapp declarations

Browse source 
T02 concluded no registry carries a lane-to-workload join key. 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 declares workload_identity with
data_classification, criticality, readiness_state and bound_reefs for nine
workloads. ops-warden's dataclass_floor already maps synthetic/internal/
confidential/restricted to M0-M3. So workload -> classification -> minimum
maturity is a shared vocabulary spanning two repos already, and it is the
operator's maturity-derived default half-implemented by accident. criticality
is the other half and no control reads it yet.

Three real defects replace the blocking unknown: the lane-to-workload key is
only derivable by parsing path_template, whose convention is inconsistent
(rapp-qonto/keycape-client parses a bundle as a workload) and whose names
disagree with workload_identity.name; rapps declare "public" which
dataclass_floor does not map; and nine declared workloads do not cover ~17
catalog path identities.

Consequence for ownership: zone-engine does not need to build a workload
registry. It consumes rapp declarations plus dataclass_floor, and asks
ops-warden for one explicit field.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-20 07:17:04 +02:00
parent e55a3afa44
commit 26e3490c9b
2 changed files with 53 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

13
docs/estate-partition-2026-08-19.md
View file

@ -212,9 +212,16 @@ 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.
> **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 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
> derivable by parsing `path_template`, whose convention is inconsistent. See
> `ZONE-WP-0001-T03`.
### Build stage