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/method/escalation.md

@@ -2,10 +2,12 @@
 id: RISK-METHOD-ESCALATION
 type: method
 title: "Escalation: what reaches the operator personally"
-status: proposed
+status: adopted
 owner: the-custodian
 drafted_by: risk-nexus
 drafted: "2026-08-19"
+adopted: "2026-08-20"
+adopted_by: the-custodian
 workplan: RISK-WP-0001-T03
 review_interval: 3m
 disclosure: restricted
@@ -18,9 +20,15 @@ restricted_reason: "names the operator's spend thresholds and describes when the
 operator personally rather than sitting in a register, and says the rule is not
 yet written. This is the rule, drafted by `risk-nexus`.
 
-**Status: `proposed`.** The custodian adopts it. It is not in force until the
-front-matter says `adopted`, and an unadopted rule is worse than an unwritten
-one because it looks like coverage.
+**Status: `adopted`, 2026-08-20, as written.** The thresholds in trigger 3 —
+€50/month recurring, €500 one-off — were this repo's proposal and are now the
+operator's numbers. They bound nothing yet: the one spend decision taken so far
+(`RISK-F-0006`) was approved without a figure being named.
+
+The rule governed four escalations before it was adopted, which is the state
+`RISK-WP-0001-T03` refused to leave open — a draft that quietly governs is
+worse than either an adopted rule or no rule, because it looks like coverage
+while nobody has agreed to it.
 
 Getting this wrong in either direction is a failure: escalating everything
 makes the operator the queue, escalating nothing makes the register a place

docs/regulatory/policies/README.md

@@ -0,0 +1,73 @@
+# Legal policy set
+
+A catalogue of legal positions the estate will need, **written before they are
+needed and dormant until a context activates one**.
+
+Operator ruling, 2026-08-20: the estate will not buy an external determination
+in build mode (`RISK-F-0008`). What it will do instead is keep this set, so
+that when a work context arrives which needs a specific legal position in
+place, the position is retrieved rather than researched from scratch.
+
+That is a direct answer to the failure `INTENT.md` names — regulation
+"consulted and discarded", the same question asked twice and the answer
+silently expiring.
+
+## How a policy works
+
+Each policy is dormant, active, or superseded, and carries an **activation
+condition**: the fact about the world that makes it apply. Nothing here is a
+compliance claim. A dormant policy asserts nothing about today; it states what
+would be required *if* its condition became true, so that the day it does, the
+work is retrieval rather than discovery.
+
+```yaml
+id: RISK-POL-0002
+regime: GDPR
+status: dormant
+activates_when: "the estate holds personal data of an identifiable natural person"
+requires_of_systems: [...]
+evidence: what would have to exist to show it is met
+```
+
+**A policy is not a plan and does not schedule work.** It is what the owning
+repo consults when its context changes. Deciding what to build in response is
+the owning repo's, as `INTENT.md` requires.
+
+## Retrieval by context
+
+The point of the set is that a context pulls a slice. Some worked examples:
+
+| A context like… | Pulls |
+| --- | --- |
+| First real user account, of any kind | `0001`, `0002`, `0003`, `0004`, `0005`, `0008` |
+| Consumer-facing product in Germany | the above plus `0011`, and `0010` if an agent talks to them |
+| A vendor processing our data | `0006`, and `0007` if outside the EU |
+| Selling to a business customer | `0009`, `0012`, and `0006` if we process for them |
+| Public-sector procurement | `0013` |
+
+## The set
+
+| ID | Regime | Policy | Status | Activates when |
+| --- | --- | --- | --- | --- |
+| `0001` | GDPR Art 6 | Lawful basis for processing | dormant | any processing of personal data begins |
+| `0002` | GDPR Arts 5(1)(e), 17 | Retention and erasure | **part-active** | any personal data is held — the commercial half is already live |
+| `0003` | GDPR Arts 15–22 | Data subject rights handling | dormant | a natural person can identify themselves to us |
+| `0004` | GDPR Art 32 | Security of processing | dormant | personal data is processed |
+| `0005` | GDPR Arts 33–34 | Breach notification, 72 hours | dormant | personal data is held; fires on the first breach, not before |
+| `0006` | GDPR Art 28 | Processors and sub-processors | dormant | a vendor processes personal data on our behalf |
+| `0007` | GDPR Arts 44+ | International transfers | dormant | personal data leaves the EEA, including to a vendor's support desk |
+| `0008` | GDPR Art 30 | Records of processing | dormant | processing begins and the small-scale exemption does not hold |
+| `0009` | HGB §257, AO §147 | Commercial and tax retention | **active** | already — the estate invoices and books |
+| `0010` | EU AI Act | AI transparency and deployer duties | dormant | an AI system interacts with a person, or is placed on the market |
+| `0011` | BFSG / EAA | Accessibility of digital services | dormant | a consumer-facing digital service is offered in Germany |
+| `0012` | UStG / ViDA | E-invoicing | **active** | already — a German business must be able to receive structured e-invoices |
+| `0013` | GWB / VgV / UVgO | Public procurement participation | dormant | the estate bids for public contracts |
+
+Written in full so far: `0002`, `0009`, `0011`, `0012` — the two that are
+already active, and the two most likely to activate next. The rest carry their
+activation condition here and are written when a context approaches, which is
+the point of the catalogue: **the trigger is recorded now, the text is written
+when it is needed.**
+
+Every entry is `risk-nexus`'s record of what a source says. None of it is legal
+advice, and this repo cannot make it into any.

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.

docs/regulatory/policies/RISK-POL-0009-commercial-and-tax-retention.md

@@ -0,0 +1,66 @@
+---
+id: RISK-POL-0009
+type: legal-policy
+title: "Commercial and tax retention"
+regime: "HGB §257, AO §147"
+status: active
+activates_when: "the estate keeps commercial books or issues and receives invoices — already true"
+owner: risk-nexus
+written: "2026-08-20"
+cadence: instant
+clean_streak: 0
+last_checked: "2026-08-20T21:30:00Z"
+next_check: "2026-08-20T21:30:00Z"
+---
+
+# RISK-POL-0009 — commercial and tax retention
+
+**Active now.** This is the one policy in the set that does not wait for a
+context: the estate already invoices, holds bank records and keeps books.
+
+## What the sources require
+
+| Class | Period | Source |
+| --- | --- | --- |
+| Books, inventories, opening balance sheets, annual accounts, management reports | 10 years | §257(1) no. 1, (4) HGB; §147(1) no. 1, (3) AO |
+| Accounting vouchers (*Buchungsbelege*) | **8 years** | §147(3) AO, shortened from ten by the Fourth Bureaucracy Relief Act with effect from 2025 |
+| Commercial and business letters received and sent | 6 years | §257(2), (4) HGB; §147(1) nos. 2–3 AO |
+
+Periods run from the **end of the calendar year** in which the last entry was
+made or the document created — not from the document's own date. That detail
+is the one most often got wrong, and it always extends the period rather than
+shortening it.
+
+**The eight-year figure is recent and this repo has not verified it against the
+current text.** Confirm before relying on it for a deletion decision; ten years
+is the safe reading if nobody has.
+
+## What it requires of systems
+
+- Records in these classes must be **retrievable for the whole period**, not
+  merely undeleted. A backup nobody can restore from does not satisfy a
+  retention duty — the same standard `RISK-F-0006` applies to `apps-pg`.
+- Immutability of content: they must not be silently rewritable.
+- Deletion must be **possible and deliberate** at the end of the period.
+  Retention duty is a floor, not a licence; `RISK-POL-0002` supplies the
+  ceiling.
+
+## Where it collides
+
+With erasure (`RISK-POL-0002`, `RISK-F-0008`). An erasure request touching a
+record inside a statutory retention period does not defeat the duty — Art
+17(3)(b) GDPR covers exactly this. But **the exemption is per record, not per
+system**: it covers the invoice, not the entire event log the invoice passed
+through.
+
+That distinction is where "we keep audit because it is audit" fails, and it is
+why `RISK-REG-0001` states periods per category rather than one figure.
+
+## Evidence that would show this is met
+
+A retention schedule per record class; a demonstrated restore from the oldest
+retained period; a deletion routine that actually runs at expiry.
+
+None of those exist yet. This policy is `active` in the sense that the duty
+applies, not in the sense that it is demonstrably satisfied — and the register
+says which.

docs/regulatory/policies/RISK-POL-0011-accessibility.md

@@ -0,0 +1,60 @@
+---
+id: RISK-POL-0011
+type: legal-policy
+title: "Accessibility of digital services"
+regime: "BFSG (European Accessibility Act, Directive 2019/882), EN 301 549 / WCAG"
+status: dormant
+activates_when: "a consumer-facing digital service or product is offered in Germany — e-commerce, banking, e-books, ticketing, or a consumer app"
+owner: risk-nexus
+written: "2026-08-20"
+cadence: instant
+clean_streak: 0
+last_checked: "2026-08-20T21:30:00Z"
+next_check: "2026-08-20T21:30:00Z"
+---
+
+# RISK-POL-0011 — accessibility
+
+**Dormant, and the most likely of the dormant set to activate.** The estate has
+a consumer domain and design work in it; the day any of that is offered to
+consumers in Germany, this applies in full and without a grace period for new
+services.
+
+## Why it is written before it is needed
+
+Accessibility cannot be retrofitted cheaply. It constrains component choice,
+colour, focus handling, form semantics and content structure — decisions taken
+early and expensively reversed. A policy retrieved at launch is a rebuild; a
+policy read at design time is a constraint like any other.
+
+That is the whole argument for this catalogue existing, and this is the entry
+that demonstrates it.
+
+## What it requires, in outline
+
+- Conformance to the harmonised standard (EN 301 549, which carries WCAG at
+  level AA) for the service's interface, and for its documentation and support.
+- An **accessibility statement**, published, saying what conforms and what does
+  not.
+- Accessibility considered in the product's own conformity assessment, with
+  records kept.
+
+Micro-enterprises providing services are outside scope, which is a real
+exemption and also a fragile one to build on — it disappears with headcount or
+turnover, and the product does not become accessible by growing.
+
+## What it requires of systems
+
+Design-time, not launch-time: semantic markup, keyboard operability, contrast
+and focus visibility, form labelling and error identification, no
+information-by-colour-alone, captions and alternatives for media. Plus a way to
+**test** these that runs before release rather than at it.
+
+## Evidence that would show this is met
+
+A conformance assessment against EN 301 549; a published accessibility
+statement; automated and manual test results in the release path.
+
+Nothing here binds any repo today. `whynot-design` and the consumer-domain
+repos are where it will land, and naming the owner is theirs, not the
+register's.

docs/regulatory/policies/RISK-POL-0012-e-invoicing.md

@@ -0,0 +1,55 @@
+---
+id: RISK-POL-0012
+type: legal-policy
+title: "E-invoicing"
+regime: "UStG §14 (as amended by the Wachstumschancengesetz), EN 16931, ViDA"
+status: active
+activates_when: "the estate is a German business receiving B2B invoices — already true"
+owner: risk-nexus
+written: "2026-08-20"
+cadence: instant
+clean_streak: 0
+last_checked: "2026-08-20T21:30:00Z"
+next_check: "2026-08-20T21:30:00Z"
+---
+
+# RISK-POL-0012 — e-invoicing
+
+**Active now, on the receiving side.** Since 1 January 2025 a German business
+must be **able to receive** a structured electronic invoice conforming to
+EN 16931 for domestic B2B transactions. That obligation had no transition
+period: the issuing obligations are phased, the receiving one was not.
+
+Issuing obligations phase in afterwards, with thresholds by turnover. The
+estate should assume it will be required to issue conformant invoices before it
+notices the deadline, because the receiving obligation arrived that way.
+
+## What it requires of systems
+
+- An inbox that accepts a structured invoice (XRechnung, or ZUGFeRD's hybrid
+  PDF/A-3 carrying the XML) and does not treat it as an attachment to be
+  eyeballed.
+- Storage of the **structured original**. A rendered PDF is not the invoice; a
+  human-readable copy alongside it is not sufficient by itself.
+- Retention per `RISK-POL-0009` — eight years for the voucher, in the original
+  format it was received in.
+
+## Where it bears on this estate
+
+`markitect` and `binect-js` handle document flows, and `rapp-qonto`/`fin-hub`
+touch payment and banking records. None of them is currently claimed to be the
+receiving point for statutory invoices, and **this policy does not assign that
+role** — naming the system that must satisfy this is the owning repo's
+decision, not the register's.
+
+What the register records is that the duty exists, is live, and currently has
+no named owner in the estate.
+
+## Evidence that would show this is met
+
+A demonstrated receipt and archival of an EN 16931 invoice, retained in its
+structured form, retrievable at eight years.
+
+Not established. If a supplier sends one tomorrow, nobody here can say what
+happens to it — which is a small, ordinary, entirely fixable gap, and exactly
+the kind that only becomes visible when it is written down.

workplans/RISK-WP-0001-make-the-register-decidable.md

@@ -4,18 +4,12 @@ type: workplan
 title: "Make the register decidable: severity, disclosure, escalation, expiry"
 domain: infotech
 repo: risk-nexus
-status: active
+status: finished
 owner: the-custodian
 topic_slug: risk-nexus
 created: "2026-08-19"
 updated: "2026-08-20"
 waiting_on:
-  - who: the-custodian
-    what: "adopt docs/method/escalation.md, which is producing decisions while still status: proposed"
-    since: "2026-08-19"
-    would_change: "the rule stops being a draft that looks like coverage; the spend thresholds become the operator's numbers rather than ours"
-    default: "recorded as de facto in force but unratified, and every escalation sent under it says so on its face"
-    default_at: "2026-09-17"
   - who: the-custodian
     what: "register finding / note / regulatory-record as canon work-record kinds, or rule that the register is a different ontology"
     since: "2026-08-20"
@@ -159,7 +153,7 @@ Completed 2026-08-19. `docs/method/disclosure.md`. The deferral was re-taken and
 
 ```task
 id: RISK-WP-0001-T03
-status: progress
+status: done
 priority: high
 ```
 
@@ -185,7 +179,7 @@ The custodian adopts the rule. Ask, do not assume.
 
 **Output:** `docs/method/escalation.md`.
 
-In progress 2026-08-19. `docs/method/escalation.md` is written and `status: proposed`. All five INTENT triggers settled — 1 adopted and bounded, 2 adopted unbounded, 3 bounded at EUR 50/month or EUR 500 one-off, 4 bounded by one failed routing exchange, 5 bounded at twice the review interval — plus trigger 6 (ordering hazard producing a false attestation), added because `RISK-F-0002` produced the case. Tested against all seven findings before proposing. **Not done until the custodian adopts it**, and the spend numbers are the operator's to overwrite.
+In progress 2026-08-19. `docs/method/escalation.md` is written and `status: proposed`. All five INTENT triggers settled — 1 adopted and bounded, 2 adopted unbounded, 3 bounded at EUR 50/month or EUR 500 one-off, 4 bounded by one failed routing exchange, 5 bounded at twice the review interval — plus trigger 6 (ordering hazard producing a false attestation), added because `RISK-F-0002` produced the case. Tested against all seven findings before proposing, and against nine by the time it was adopted. The €50/month and €500 thresholds are now the operator's numbers rather than ours — they bound nothing so far, since the only spend decision taken (`RISK-F-0006`) was approved without a figure.
 
 ### T04 — Review dates and expiry