ZONE-WP-0001-T03: maturity-derived risk defaults, and what they can attach to

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>

workplans/ZONE-WP-0001-security-zone-model.md

@@ -268,6 +268,50 @@ Controls in scope at minimum: the flex-auth pre-sign gate (`policy.enabled`,
 `fail_closed`), the agent read-boundary on `risk: high` lanes (ops-warden
 `ADR-0004`), and the `warden plan` escalation verdicts.
 
+**Operator direction 2026-08-19 — defaults derive from maturity, not from
+nothing.** An ungraded lane must not inherit the safest-for-the-tool default; it
+should inherit the default its *maturity context* implies. Early or experimental
+context: an absent grade is tolerable and explicitly accepted. Production
+context: an absent grade is `high`, or `critical` where the context is critical.
+This is the same rule `RISK-F-0003` needs and is why that finding's fix is a
+model question, not a cleanup.
+
+Three things established while checking what this can attach to:
+
+- **The right ladder already exists: `M0`–`M3`** in ops-warden's
+  `registry/policy/security-posture.yaml`. It is ordered (`rank`), phased
+  (`experimental-poc` → `alpha-early-access` → …), and already carries a data
+  ceiling per rung (`max_dataclass`: `synthetic` → `internal` → …) plus
+  `promotion_gate`. It is exactly the shape this rule needs. What it lacks is a
+  **join** to lanes or repos — the gap T02 found.
+- **`.repo-classification.yaml` `category` cannot carry it.** It is populated
+  estate-wide (54 `project`, 23 `tooling`, 14 `product`, 7 `research`, 4
+  `experimental`) and canon calls it "work mode, maturity, or organizational
+  purpose" — but it is unordered, and the actual values invert the property we
+  need: `railiance-platform`, which runs production OpenBao and owns three of
+  the five lanes `RISK-F-0003` exposes, is `tooling`; `ops-warden`, a production
+  SSH CA, is `tooling`; `net-kingdom`, a canon-documentation repo, is `product`.
+  Deriving a safety default from it would grade production credential
+  infrastructure below a documentation repo. `criticality` exists in the rapp
+  vocabulary (`low`/`medium`/`high`/`critical`) but is unset on every repo
+  checked.
+- **Whose maturity — the owner's, not the holder's.** All 27 lanes live in
+  ops-warden's catalog, but their `owner_repo` is elsewhere. Deriving from the
+  repo that holds the pointer would give every lane ops-warden's classification,
+  which says nothing about the credential. Membership must derive from the lane's
+  owner or the workload it serves.
+
+**The principle validates against the data:** all five lanes `RISK-F-0003`
+exposes are owned by production-serving components, so "unclassified in a
+production context → high" would have caught every one.
+
+**One vocabulary caution for T05.** `accepted` is not a grade. A grade says how
+dangerous a lane is; an acceptance says who agreed to carry that danger, and
+therefore needs an owner and a date. Putting an acceptance in a descriptive
+field repeats the error net-kingdom rejected when it refused stance as a
+tenancy axis. Model them as two fields: grade (derived, defaultable) and
+acceptance (asserted, owned, expiring).
+
 **Amended by flex-auth 2026-08-19 — split membership from stance.** ops-warden's
 option (c) ("zones as policy-package data") was rejected wholesale because the
 model must govern two controls flex-auth does not evaluate. flex-auth agrees with