coulomb/risk-nexus
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
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>
This commit is contained in:
tegwick 2026-08-20 23:36:22 +02:00
parent 3a0ba5d427
commit 7f135f9e0f
7 changed files with 332 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

73
docs/regulatory/policies/README.md Normal file
View file

@ -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.