risk-nexus/workplans/RISK-WP-0003-regulatory-intake.md
tegwick aeb56e3711 RISK-WP-0003 T02/T03: state the retention periods, and write the intake route
T02 applies the dependency rule to this repo's own work: rather than wait
on audit-core's co-residency horizon, RISK-REG-0001 now states target
periods per category with the reasoning — 12 months for operator and
agent security records, 3 years to year-end for counterparty transaction
evidence, 8 years for accounting vouchers (shortened by BEG IV, flagged
as worth confirming), 10 years for books, 6 for commercial letters,
delete for anything with no ground. Targets, not achievements: the estate
cannot demonstrate any of them while the real horizon is the maximum
across every co-resident on platform-pg, and that gap is stated so the
table cannot be read as a compliance claim.

T03 writes the intake route from what audit-core did correctly without
one: the question as a question, what already depends on it, what becomes
expensive if the answer is no, and what you are not asking for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 23:16:51 +02:00

4.2 KiB

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