risk-nexus/workplans/RISK-WP-0003-regulatory-intake.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	depends_on_workplans
RISK-WP-0003	workplan	Make regulatory intake a working remit rather than one record	infotech	risk-nexus	proposed	the-custodian	risk-nexus	2026-08-20	2026-08-20	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

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

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

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

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.