Legal policy set: written before needed, dormant until a context activates

Operator ruling: no external determination in build mode, but keep the
set of legal policies for reuse when a work context needs one in place.

docs/regulatory/policies/ catalogues thirteen, keyed by activation
condition rather than by regime, with a retrieval table so a context
pulls a slice: first real user account pulls six of them; a
consumer-facing product in Germany pulls those plus accessibility. Two
are already active and nobody had noticed — commercial and tax retention,
and the e-invoicing receiving obligation that has been live since 2025
with no named owner in the estate. Four written in full; the rest carry
their trigger now and get their text when a context approaches, which is
the point.

RISK-POL-0011 is the argument for the whole catalogue: accessibility
cannot be retrofitted cheaply, so a policy retrieved at launch is a
rebuild while one read at design time is just a constraint.

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

docs/regulatory/policies/RISK-POL-0002-retention-and-erasure.md

@@ -0,0 +1,63 @@
+---
+id: RISK-POL-0002
+type: legal-policy
+title: "Retention and erasure"
+regime: "GDPR Arts 5(1)(e), 17; HGB §257; AO §147"
+status: part-active
+activates_when: "any personal data is held — the commercial half (RISK-POL-0009) is already live"
+owner: risk-nexus
+written: "2026-08-20"
+related: [RISK-POL-0009, RISK-REG-0001, RISK-F-0008]
+cadence: instant
+clean_streak: 0
+last_checked: "2026-08-20T21:30:00Z"
+next_check: "2026-08-20T21:30:00Z"
+---
+
+# RISK-POL-0002 — retention and erasure
+
+Two duties pulling opposite ways, which is why they are one policy. Storage
+limitation says keep it no longer than necessary; retention duties say keep it
+for a fixed term; erasure says delete on request. A system that satisfies one
+in isolation usually breaks another.
+
+## The order of operations
+
+1. **Is there a statutory retention duty?** (`RISK-POL-0009`.) If yes, the
+   record is kept for the term, and an erasure request does not defeat it —
+   Art 17(3)(b). The exemption is **per record**, not per system.
+2. **Is there a live purpose?** If not, storage limitation (Art 5(1)(e))
+   requires deletion regardless of whether anyone asked.
+3. **Has someone asked?** Then Art 17, minus whatever survives step 1 or an
+   Art 17(3) exemption, each of which must be identified per category rather
+   than claimed wholesale.
+
+The periods per category are in `RISK-REG-0001`, with the reasoning and the
+weak points named.
+
+## What it requires of systems
+
+- **Deletion must be possible.** Not scheduled, not intended — possible, and
+  demonstrated once. `RISK-F-0008` exists because `audit-core` established that
+  in their store it currently is not.
+- **The real horizon is the maximum across co-residents.** A service declaring
+  twelve months on shared infrastructure achieves the longest retention of
+  anything sharing that infrastructure, including backups. Declared periods are
+  claims until that is established.
+- **A commitment over cleartext defeats erasure.** A retained hash of a
+  low-entropy record is a confirmation oracle: destroying the key does not
+  erase content that can still be tested against a surviving commitment. Keyed
+  commitments (HMAC, per-subject salt) restore erasability — open with
+  `audit-core`.
+- **Minimisation beats exemption.** Operator ruling, 2026-08-20: opaque subject
+  ids, agent identifiers where possible, operator credentials only where
+  necessary, policy decisions tracked to the responsible party. Data that never
+  arrives needs no ground, no exemption and no argument.
+
+## Evidence that would show this is met
+
+A retention schedule per category; a demonstrated deletion at expiry; a stated
+and verified co-residency horizon; a demonstrated restore proving the retained
+side works too.
+
+None of those exist yet, and `RISK-F-0008` carries the gap.