Publication handover (two findings ready, three tasks, one of which is a paragraph); regulatory intake as a working remit rather than one record, carrying RISK-REG-0001's open items; and running the register, where every task traces to something that actually went wrong in week one — grading before reading the inbox, a status the tooling did not know, an id collision, two gradings resting on file comparison because a token expired, and an on-request path nobody has walked. All three are status: proposed. The custodian decides which become active and in what order. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
125 lines
4.2 KiB
Markdown
125 lines
4.2 KiB
Markdown
---
|
|
id: RISK-WP-0003
|
|
type: workplan
|
|
title: "Make regulatory intake a working remit rather than one record"
|
|
domain: infotech
|
|
repo: risk-nexus
|
|
status: proposed
|
|
owner: the-custodian
|
|
topic_slug: risk-nexus
|
|
created: "2026-08-20"
|
|
updated: "2026-08-20"
|
|
depends_on_workplans:
|
|
- RISK-WP-0001
|
|
---
|
|
|
|
# RISK-WP-0003 — regulatory intake
|
|
|
|
**Draft.** The half of this repo's remit that `RISK-WP-0001` deliberately did
|
|
not touch.
|
|
|
|
## Goal
|
|
|
|
`INTENT.md` says regulation was previously "consulted and discarded" — the same
|
|
question asked twice and the answer silently expiring. `RISK-REG-0001` is one
|
|
record against that. Make it a remit: a format that expires, a way for repos to
|
|
ask, and the open items that record is carrying.
|
|
|
|
Done means: the retention question is answered as far as it can be without
|
|
buying advice, the trigger list for buying advice is ruled, and a repo with a
|
|
regulatory question knows where to put it.
|
|
|
|
## The open items this inherits
|
|
|
|
From `RISK-REG-0001` and `RISK-F-0008`, both already written down:
|
|
|
|
1. **A defensible retention period per category.** The determination names this
|
|
as the weakest point in the estate's whole position: supervisory practice
|
|
accepts audit logging under legitimate interest and then asks how long, and
|
|
"we keep audit because it is audit" is the form that fails.
|
|
2. **`audit-core`'s co-residency horizon.** At `P1` the real erasure horizon is
|
|
the maximum across every co-resident on `platform-pg`, not the declared
|
|
value. An infrastructure fact is doing load-bearing work in a legal position,
|
|
which is an uncomfortable place for it to be. Blocked on `audit-core`.
|
|
3. **The trigger list.** First real person's data, first counterparty contract
|
|
requiring a stated position, first Art 17 request. Proposed 2026-08-19, not
|
|
ruled.
|
|
|
|
## Tasks
|
|
|
|
### T01 — Rule the trigger list
|
|
|
|
```task
|
|
id: RISK-WP-0003-T01
|
|
status: todo
|
|
priority: high
|
|
```
|
|
|
|
Custodian decision. Cheap, and it is what stops the estate either buying advice
|
|
it does not need or discovering it needed it. Until it is ruled, `RISK-F-0008`
|
|
stays escalated as `partially-answered`.
|
|
|
|
### T02 — Retention periods per category
|
|
|
|
```task
|
|
id: RISK-WP-0003-T02
|
|
status: todo
|
|
priority: high
|
|
```
|
|
|
|
State a period and a reason per category in `RISK-REG-0001`, or state plainly
|
|
that the estate cannot yet and why. The second is an acceptable outcome and a
|
|
better record than a number nobody can defend.
|
|
|
|
Depends on `audit-core` answering the co-residency horizon, which has been
|
|
asked for. If they cannot, that dependency is itself the answer to record.
|
|
|
|
### T03 — Intake route for regulatory questions
|
|
|
|
```task
|
|
id: RISK-WP-0003-T03
|
|
status: todo
|
|
priority: medium
|
|
```
|
|
|
|
`audit-core` routed theirs by messaging this repo and asking for an owner,
|
|
which worked. Write that down as the route rather than leaving it as one repo's
|
|
good instinct: what a regulatory question needs when it arrives, what it gets
|
|
back, and what this repo will not answer (legal advice, and what the owning
|
|
repo must therefore do).
|
|
|
|
Extend `findings/README.md` or give `docs/regulatory/README.md` the reporter's
|
|
half. Do not invent an intake system.
|
|
|
|
### T04 — Expiry
|
|
|
|
```task
|
|
id: RISK-WP-0003-T04
|
|
status: todo
|
|
priority: medium
|
|
```
|
|
|
|
Regulatory records expire; that is why the remit moved here. Put them on the
|
|
same cadence ladder as findings (`docs/method/review.md`) rather than inventing
|
|
a second review mechanism — a record that has held still for a quarter is
|
|
making the same statement a finding at `1q` makes.
|
|
|
|
`make check` should report a regulatory record due for a check exactly as it
|
|
reports a finding.
|
|
|
|
## Non-goals
|
|
|
|
- **No legal advice.** `INTENT.md`, and the records say so in their own text.
|
|
- **No survey of every regime that might apply.** Regulation is scoped to rules
|
|
bearing on data the estate holds, markets it sells into, or obligations it has
|
|
taken on. A general compliance programme is not this.
|
|
- **No answering what a repo must therefore do.** That is the owning repo's.
|
|
|
|
## Risks
|
|
|
|
**The remit becomes a compliance function.** Mitigation: records answer
|
|
questions that were actually asked, by a repo, with a date.
|
|
|
|
**A record states a legal conclusion with false confidence.** Mitigation: every
|
|
record names where it is weak, and `external_review: none` is a required field
|
|
rather than an omission.
|