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 <noreply@anthropic.com>
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>
The lane-to-workload join moves from a noted gap to the critical path: with no
workloads in the corpus there is nothing to attach an admission standard to, and
the honest answer may be that the join belongs to whatever declares workloads
rather than to zone-engine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator direction: an ungraded lane inherits the default its maturity context
implies — accepted in experimental context, high or critical in production.
M0-M3 is the right ladder and already carries rank, phase, max_dataclass and
promotion gates; what it lacks is a join to lanes, which is T02's gap.
.repo-classification.yaml category cannot carry it: railiance-platform, which
runs production OpenBao and owns three of RISK-F-0003's five exposed lanes, is
category tooling, while net-kingdom, a canon docs repo, is product. It orders
work mode, not blast radius.
Also records that maturity must come from the lane's owner, not the repo holding
the catalog, and that 'accepted' is an acceptance rather than a grade — it needs
an owner and an expiry, so it is a second field, not a rung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Amended by net-kingdom as canon owner of tenancy-posture_v0.1.
T01: enforcement stance is a sibling canon standard, not a seventh axis (the six
ladders are monotone and stance is not; and a descriptive framework cannot carry
a prescriptive axis without handing out its own exemptions). Ownership confirmed;
the repo is not archived. Declaration surface is tenancy.yaml's reserved zones:
key, not a new root file.
T02: the reef question is struck — the unreconciled pair is reef vs P/V and it is
canon's defect (NK-WP-0027), not this model's scope. organization_posture: do not
fold in, consume as an input.
T05: carrier file settled; only the shape inside zones: remains open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reviewed as the only policy decision point. Four task amendments:
T01 - the 'only PDP' invariant guards latency, not authority. Compiled
data that determines an outcome still decides. Tightened wording:
zone-engine owns membership, flex-auth policy owns stance.
T03 - split membership from stance rather than rejecting option (c)
wholesale. Stance for the pre-sign gate belongs in the policy package
because registry content is absent from decision provenance. Also:
fail-open is a PEP property and no PDP can express it.
T05 - no registry schema change needed; metadata/attributes already
flatten into rego input. But trust_zone is a live name collision -
a hardcoded 'platform' constant no policy reads.
T04 - flex-auth loads registry and policy once at process start with
no reload path, so an inert compiled exception expires only by human
redeploy. Enforced expiry requires a not_after evaluated in rego.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Enforcement controls in this estate have been repo-wide booleans. ops-warden's
flex-auth pre-sign gate was the first to become flippable, and flipping it would
have made flex-auth a hard dependency of every warden sign — including the SSH
certs the ops-bridge tunnels depend on, one of which carries the policy call.
Uniform enforcement across an estate under deep refactor hardens exactly the
access needed to perform the refactor. Deferred under ops-warden ADR-0006; this
repo is what that ADR defers to.
Seeded deliberately without a schema. ZONE-WP-0001 produces a model and a canon
draft, not an API: an engine that ships a wire format before it has partitioned
the real estate defines the model by accident. Whether a runtime is warranted is
an output of the exception-lifecycle task, not an assumption.
Invariants set now, because they are the ones easy to lose later: flex-auth
stays the only PDP and receives membership by compilation, not a synchronous
lookup in a latency-critical decision path; placement (reefs) is not posture;
accuracy not altitude, per tenancy-posture v0.1 §6.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
