risk-nexus/notes/RISK-N-0004-zone-lookup-facility.md

---
id: RISK-N-0004
type: note
title: "No facility answers which zone a workload is in, or what applies there"
date: "2026-08-20"
source: "the-custodian, 2026-08-20; surfaced by RISK-F-0003 and RISK-F-0008"
floor_reason: "missing capability, not a defect — there is nothing to route to a fix owner, and the register does not file undone work"
revisit: "when the facility lands, or when a fourth finding turns on a zone answer nobody can give"
routed_to: zone-engine
ruling: RISK-RULING-2026-08-20
---

# RISK-N-0004 — nothing can answer "which zone, and what applies there"

The operator's requirement, 2026-08-20: there should be a facility that answers,
easily, **which zone a workload is in** and **which policies and guarantees
apply in that zone**.

**Ruled a note, not a finding.** Consistent with `RISK-N-0001`: what is missing
is capability, not a control. There is no defect, no owning repo carrying a
gap, and nothing for this register to route to a fix owner. Filing undone work
as a finding is how a register stops being readable.

Routed to `zone-engine` as the owner of the zone model. This repo records the
requirement and its consumers; it does not design or build it.

## Why the register cares — three findings already wait on it

Recorded because a note with a real dependency list is worth more than a
finding with none.

- **`RISK-F-0003`** — the operator directed that an absent lane `risk` grade
  should resolve from **maturity context**: tolerable in an early or
  experimental context, `high` or `critical` in a production one. `ops-warden`
  and this register both established that `.repo-classification.yaml`
  `category` cannot carry that signal — `railiance-platform` runs production
  OpenBao as `tooling`. The lookup is what would make that rule computable
  rather than aspirational. `ops-warden` is grading the five exposed lanes by
  hand in the meantime (`WARDEN-WP-0032-T05`) precisely because it does not
  exist.
- **`RISK-F-0008`** — the operator's ruling includes that zone-level privacy,
  pseudonymity or anonymity guarantees may raise the floor for what identity
  an audit record must carry. `audit-core` cannot honour a guarantee it cannot
  look up at accept time.
- **`RISK-F-0007`** — verification of a named consumer boundary is available on
  request. Scoping a request by zone is more useful than scoping it by repo,
  and only possible if zone membership is answerable.

## What this register would want from it, stated as needs and not as a design

Offered to `zone-engine` as consumer requirements. The design is theirs.

1. **Answerable about a workload, not only about a repo.** A repo can run
   several workloads at different maturities; `railiance-platform` is the
   standing proof.
2. **Authoritative, not inferred.** A lookup that guesses from labels or names
   reproduces the failure it exists to fix — `RISK-F-0003` is a finding about a
   field being optional, and a facility that silently returns "unknown, assumed
   low" would be the same defect at a higher altitude. Unknown must read as
   unknown.
3. **Guarantees, not only membership.** "Which zone" is half an answer. The
   consuming decisions are about what applies there.
4. **Machine-readable.** So that `make check` in this repo can eventually ask
   whether a finding's system sits in a zone whose guarantees change its grade,
   rather than a person remembering to.

## What this note is not

Not a request for a schedule, not a design, and not a claim that the absence is
currently causing harm. `RISK-F-0003`'s five lanes are being graded by hand and
`audit-core` can implement the operator's minimisation ruling today without
knowing any zone. The facility makes three existing decisions cheaper and one
future class of them possible; it does not unblock anything that is stuck.

It comes back as a finding only if a fourth finding turns on a zone answer that
nobody can give.