RISK-REG-0001: write down the retention basis, and open regulatory intake

The outstanding half of RISK-F-0008 that needed no authorisation. Grounds
stated per category rather than as a blanket exemption: Art 6(1)(f) with
Art 32 for operator and agent records, Art 17(3)(e) for counterparty
transaction evidence, Art 17(3)(b) only where a commercial or tax duty
independently applies. The weak part is named as duration rather than
existence, and audit-core's co-residency horizon is identified as the
most likely point of failure in the whole position. Not legal advice, and
the record says so.

Also opens docs/regulatory/ with the record format — dated, sourced, and
reviewed, because a regulatory answer expires.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

REGISTER.md

@@ -2,7 +2,7 @@
 
 Generated by `tools/register_index.py` from `findings/`. Do not edit by hand. Last built 2026-08-20.
 
-6 open of 9 findings; 2 notes below the floor.
+6 open of 9 findings; 3 notes below the floor.
 
 ## Findings
 
@@ -45,6 +45,7 @@ Seen, deliberately not findings. Not graded, not reviewed, not published.
 
 | ID | Note | Why below the floor |
 | --- | --- | --- |
+| [RISK-N-0004](notes/RISK-N-0004-zone-lookup-facility.md) | No facility answers which zone a workload is in, or what applies there | missing capability, not a defect — there is nothing to route to a fix owner, and the register does not file undone work |
 | [RISK-N-0003](notes/RISK-N-0003-defects-found-by-reading-not-monitoring.md) | Every defect in this register was found by reading, none by monitoring | no owner and no defect — it is an argument about where to invest detection, and the register cannot route an argument |
 | [RISK-N-0001](notes/RISK-N-0001-noisy-neighbour-uncharacterised.md) | Noisy-neighbour behaviour is uncharacterised | no decision changes today — no tenant shares a saturating workload, and what is missing is measurement work, not a defect to route |
 

docs/regulatory/README.md

@@ -0,0 +1,20 @@
+# Regulatory intake
+
+Moved here from `policy-nexus` on 2026-08-17: deciding what an external rule
+demands of the estate is a judgement about risk, not an act of publishing.
+
+One file per question. Each record states **what a source says and when**, and
+what the estate therefore relies on. What the estate must consequently *do* is
+the owning repo's decision, not this repo's — `INTENT.md`.
+
+A record carries `sources_read`, `determined`, `external_review` (usually
+`none`, and it must say so rather than implying otherwise), and `review_by`.
+A regulatory answer expires; that is why it is dated and reviewed rather than
+consulted once and discarded, which is the failure that moved this remit here.
+
+**These records are not legal advice** and this repo cannot make them into any.
+Where a position is weak, the record says which part and why.
+
+| Record | Question | Finding |
+| --- | --- | --- |
+| `audit-retention-basis.md` | On what basis are audit records retained against an erasure request? | `RISK-F-0008` |

docs/regulatory/audit-retention-basis.md

@@ -0,0 +1,112 @@
+---
+id: RISK-REG-0001
+type: regulatory-record
+title: "On what basis the estate retains personal data inside audit records"
+status: determined-internally
+owner: risk-nexus
+determined: "2026-08-20"
+finding: RISK-F-0008
+sources_read: "GDPR Arts 5, 6, 17, 21, 32; Recitals 49, 65; HGB §257; AO §147"
+external_review: none
+review_by: "2026-11-17"
+---
+
+# RISK-REG-0001 — the retention basis, written down
+
+The first record of this repo's regulatory-intake remit, and the outstanding
+half of `RISK-F-0008`. `audit-core` asked for an owner and an eventual answer;
+this is the answer as far as it can honestly be given without buying one.
+
+**What this is.** A statement of what the sources say, which ground the estate
+relies on for which category of data, and for how long. It is a position that
+can be argued with, which is the whole point — `RISK-F-0008` exists because the
+estate had been assuming one without writing it down.
+
+**What this is not.** Legal advice. `INTENT.md` is explicit that this repo does
+not give it, and nothing here has been reviewed by anyone qualified. Where the
+position is weak, this record says so rather than sounding confident.
+
+## The question
+
+`audit-core` holds audit evidence across tenants, targets `R2` on the Tenancy
+Posture retention ladder, and has declared `R4` (verified erasure) unreachable
+by design — crypto-shredding would destroy the evidence the service exists to
+hold, and their `SHA-256`-over-cleartext commitment survives key destruction as
+a confirmation oracle against low-entropy records.
+
+So if an Art 17 request names a data subject appearing in the audit trail,
+there is no mechanism. The position rests on the record being exempt.
+
+## The grounds, per category
+
+The exemption is **never blanket**. It is per category of data and per purpose,
+and the estate's position has to be stated that way or it is not a position.
+
+| Category | Ground relied on | Strength |
+| --- | --- | --- |
+| Operator and agent identifiers, actions, timestamps | Art 6(1)(f) legitimate interest in the security of processing, reinforced by Art 32's obligation to ensure it; Recital 49 names network and information security as a legitimate interest | **Strong.** This is the ordinary, widely accepted case. |
+| Counterparty or end-user identifiers appearing in event payloads | Art 17(3)(e) — establishment, exercise or defence of legal claims — with Art 6(1)(f) for the processing itself | **Adequate on existence, weak on duration.** See below. |
+| Records that are commercial books, invoices or tax-relevant documents passing through audit | Art 17(3)(b) legal obligation, given HGB §257 (6/10 years) and AO §147 | **Strong but narrow.** These duties cover books and invoices. They do not convert an application audit log into a retained commercial record. |
+
+## Where this position is weak, stated plainly
+
+**Duration, not existence.** Supervisory practice tends to accept security and
+audit logging under legitimate interest and then ask how long. "We keep audit
+forever because it is audit" is the form that fails. A defensible answer names
+a period per category and a reason for it, and the estate does not have one
+yet — `audit-core` declares a horizon, and their own question 2 points out that
+at `P1` the real horizon is the maximum across every co-resident on
+`platform-pg`, not the declared value. **That gap is the most likely point of
+failure in this entire position**, and it is an infrastructure fact rather than
+a legal one.
+
+**Art 21 objection.** Legitimate interest carries a right to object. The estate
+would have to show compelling legitimate grounds overriding the subject's
+interests. For security and fraud-investigation evidence that is a normal
+argument to win, but it is an argument, not an exemption that applies
+automatically.
+
+**Art 5(1)(e) storage limitation** applies regardless of the erasure exemption.
+An exemption from erasure on request is not a licence to retain indefinitely.
+
+## What the operator's ruling of 2026-08-20 does to this
+
+It shrinks the second row of the table, which is the weak one.
+
+Opaque subject identifiers, agent identifiers where possible, operator
+credentials only where necessary, and policy decisions tracked to the
+responsible party — the effect is that most audit records stop containing the
+category whose retention is hardest to justify. What remains is the first row,
+where the position is strong.
+
+This is the most useful thing that has happened to this question. A weak legal
+argument avoided by holding less data is better than a strong one relied upon.
+
+## The estate's position, as recorded today
+
+1. The estate relies on **Art 6(1)(f) with Art 32** for operator and agent
+   audit records, and on **Art 17(3)(e)** for records evidencing a transaction
+   with a counterparty.
+2. It relies on **Art 17(3)(b)** only for records that are independently
+   subject to a commercial or tax retention duty, and does not extend that
+   duty to application logs generally.
+3. It **does not yet have a defensible retention period** per category. This
+   is the open item, and it is `audit-core`'s co-residency horizon that must be
+   settled before a period can be stated honestly.
+4. It holds that the operator's minimisation ruling is the primary control, and
+   the exemption the fallback — in that order.
+
+## What would change this record
+
+- `audit-core` answering whether a keyed commitment restores erasability. If it
+  does, the estate stops relying on an exemption for anything it could instead
+  erase, and this record narrows to the retained-by-obligation categories only.
+- A stated retention period per category, once the co-residency horizon is
+  known.
+- Any of the three triggers for buying an external determination: the estate
+  first holding a real person's data, a counterparty contract requiring a
+  stated position, or an actual Art 17 request. **This record is explicitly not
+  a substitute for that** — it is what the estate says while none of them has
+  happened.
+
+Reviewed every 90 days with `RISK-F-0008`, or immediately on any trigger.

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

@@ -0,0 +1,76 @@
+---
+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.