Consume authoritative workload reference contract

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0291a-1e87-7151-9934-fcbfe3f65eb1

docs/security-zones_v0.1.md

@@ -37,12 +37,13 @@ Conformance is **accuracy, not altitude**. A lower zone declared with evidence
 is conformant. A stricter zone that the workload cannot evidence is not.
 Changing membership to evade a control is not an exception mechanism.
 
-The workload is the sole policy subject. It includes independently governed
-application, automation, maintenance, and operational/control-plane execution
-units. SSH access, tunnel operation, credential brokering, policy machinery,
-and maintenance work therefore require workload identities even when they have
-no `rapp`. Human and agent identities remain caller context and cannot be the
-sole workload binding.
+The workload is the sole **zone** policy subject. It includes independently
+governed application, automation, maintenance, and operational/control-plane
+execution units. The workload executing a tunnel, credential broker, policy
+service, or maintenance operation requires identity; the tunnel, grant, lane,
+pattern, action, human, or agent does not become a workload merely because a
+control observes it. Those retain native typed identity and caller/resource
+context.
 
 ## 3. Resolution is authoritative
 
@@ -52,14 +53,20 @@ MUST NOT infer membership from repository ownership, paths, lane types, actor
 classes, environment, criticality, reefs, organization posture, or naming
 conventions.
 
-Resolution returns both the declaration and its admission result:
+For a managed deployable, the authoritative cross-repository reference is the
+Repo Manager v1 tuple `(rapp_id, workload_identity.name)`, optionally narrowed
+by `deployable`. A catalog also declares whether its subject is workload
+applicable. Resolution returns both the reference result and admission result:
 
 - `satisfied` — the workload has an authoritative identity and evidence meeting
   the declared zone's floor; `effective_zone` is the declared zone;
 - `unsatisfied` — identity and membership are declared, but evidence is below
   the admission floor; `effective_zone` is `unknown`;
 - `unknown` — identity, membership, or a required floor/evidence input cannot be
-  resolved; `effective_zone` is `unknown`.
+  resolved for a workload-applicable subject; `effective_zone` is `unknown`;
+- `not-applicable` — the owning catalog explicitly establishes that the subject
+  is an action, actor, lane, pattern, or resource rather than a workload; no
+  zone is resolved and the control uses that subject's native identity.
 
 `unknown` is a result, not a zone. A control MUST declare an explicit treatment
 for it. That treatment may deny, escalate, or use a reviewed build-stage rule;
@@ -166,6 +173,15 @@ For a single-service declaration, `zones:` is a sibling of `tenancy:` and
 `zones` occur inside the same service entry. A multi-service file MUST NOT use a
 top-level `zones:` block.
 
+Every managed running deployable has an authoritative
+`rapp-*/declarations/rapp.yaml`. Its `workload_identity.declaration_ref` points
+to that declaration, and consuming catalogs reference it using the Repo Manager
+v1 tuple. A pre-rapp deployable is migration debt and resolves `unknown`. An
+independently governed operational execution unit that is not a managed
+deployable may declare directly in its responsible repo's `tenancy.yaml`; this
+does not turn a human action or infrastructure resource into a fictional rapp or
+workload.
+
 ```yaml
 schema_version: "0.1"
 framework: netkingdom-tenancy-posture
@@ -218,6 +234,11 @@ contains:
 
 ```yaml
 workload_id: ops-bridge-tunnel
+workload_ref:
+  applicability: applicable
+  rapp_id: null                 # required for a managed deployable
+  name: ops-bridge-tunnel
+  deployable: null              # optional for a managed deployable
 identity_binding: ssh-certificate/ops-warden/agt-ops-bridge
 declared_zone: z3-continuity
 admission: satisfied
@@ -243,6 +264,22 @@ and any active exception id and expiry. This is the machine-readable answer to
 “which zone is this workload in, and what applies there?” It may be compiled
 into existing consumer artifacts; it is not a synchronous zone-engine lookup.
 
+For managed deployables, compilation consumes the exact Repo Manager reference
+projection:
+
+```yaml
+workload_ref:
+  applicability: applicable
+  rapp_id: rapp-issue-core
+  name: issue-core
+  deployable: issue-core  # optional
+```
+
+The owning catalog uses `applicability: not-applicable` for a native non-workload
+subject. Absence of either applicability or an expected reference is `unknown`,
+not `not-applicable`. Zone-engine consumes these outcomes; it does not parse a
+path or repository name to repair them.
+
 For flex-auth's pre-sign control, the governed workload is the target of the
 certificate or grant, so the compiler writes `workload_id`, `security_zone`,
 `security_zone_admission`, and `security_zone_revision` on the resource

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

@@ -302,6 +302,15 @@ returns `unknown` without manufacturing a zone. The unresolved `public`
 DataClassification floor is handled honestly as `unknown` pending
 info-tech-canon's ruling; it no longer blocks the model.
 
+Repo-manager subsequently accepted `RMGR-ADR-004` and the v1 workload-reference
+contract. Managed deployables resolve through the explicit
+`(rapp_id, workload_identity.name)` pair with optional `deployable`; catalog
+owners distinguish workload-applicable subjects from native `not-applicable`
+actors, actions, lanes, patterns, and resources. This sharpens rather than
+reopens canon's ruling: the executing unit is the workload, while the action or
+resource it handles is not. All omitted or unresolved applicable references
+remain `unknown`.
+
 **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
@@ -661,6 +670,11 @@ flex-auth was asked to accept or amend the pre-sign stance rows before adding
 them to a policy package. Adoption evidence, implementation, and the required
 fresh caller-identity check remain open.
 
+Repo-manager adoption/proof is linked as `RMGR-WP-0010-T07` to this task
+(`ZONE-WP-0001-T07`, State Hub task
+`c7ea24df-8aa9-4ead-ba3a-033aa5201c21`). Its accepted v1 tuple and explicit
+`unknown`/`not-applicable` distinction are now consumed by the draft.
+
 ## Related
 
 - ops-warden `ADR-0006` — enforcement is zone-scoped, never a global flag