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>
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>
Four bands, derived rather than invented, each of the 27 catalog lanes in
exactly one: Decided (1), Fronted (10), Covered (12), Signposted (4).
The finding is that delegation.mode — introduced by ops-warden WP-0030 to answer
a governance question — predicts operational danger better than the field named
risk. Ten of eleven high-risk lanes are interim, eight of those exec_capable.
Two results that constrain T03 and T04. The three existing controls each cut the
estate differently (1, 13 and 11 lanes) with only 8 in the overlap, so stance is
per control per zone and never per zone alone. And the posture registry shares no
join key with the catalog, so environment posture and M0-M3 compose in principle
but cannot be joined today without inventing a mapping — fabrication under §6.
The residue is the most valuable output: 14 of 27 lanes carry no risk value, and
is_high_risk is risk == "high", so the agent read-boundary never fires for them.
Five are exec_capable. Routed to risk-nexus as RISK-F-0003.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
