Owner is the-custodian; regulatory intake leaves for risk-nexus

Authority is three-way and stated rather than held by one repo: policy-nexus
owns the surface, the-custodian owns what counts as canon and when it is
ratified, railiance-platform owns the substrate. The middle one is the guard
against the real hazard here - a repo that reads every other repo is one step
from becoming the place where "what is current" is decided, and this says
plainly that it renders that judgement rather than making it.

The tell that the split is right is that T01 and T04 need different
competences. T01 asks what supersession means and what a permanent URL
promises; T04 is DNS and ingress. One owner would be weak at one of them.

T06 withdrawn. Regulatory intake is risk work, not publishing work, and it
wanted a different owner and a different skill from everything else in this
workplan. risk-nexus publishes through here, arriving as another manifest
source rather than as a second content type this repo curates.

The consequence is the point: this repo now does one thing, which is what made
its ownership answerable.

Domain corrected from government, a leftover from when this looked like a civic
policy site.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-17 15:56:05 +02:00
parent 54779f5eb7
commit cac0301866
2 changed files with 38 additions and 79 deletions

View file

@ -2,10 +2,10 @@
id: POLICY-NEXUS-WP-0001
type: workplan
title: "Stand up policy.coulomb.social as the permanent publication surface"
domain: government
domain: infotech
repo: policy-nexus
status: proposed
owner: unassigned
owner: the-custodian
topic_slug: policy-nexus
created: "2026-08-17"
updated: "2026-08-17"
@ -154,56 +154,19 @@ is quietly out of date is worse than no document.
unratified since 2026-08-10; that fact should be visible on the site, because
invisibility is precisely why it stalled.
### T06 — Regulatory intake
### T06 — withdrawn
The information-gathering half, scoped to **regulation bearing on the estate**.
Deliberately last: the publication path must work before a second content type
is added.
Regulatory intake moved to `risk-nexus` on 2026-08-17. Deciding what a rule
demands of the estate is a judgement about risk, not an act of publishing, and
it wanted a different owner and a different skill from everything above.
**Inclusion test.** A rule is in scope when it constrains something the estate
actually does — governs data it holds, a market it sells into, or an obligation
it has taken on. Public policy that is merely interesting is out. This is a
compliance surface, not a civic-information corpus.
`risk-nexus` publishes *through* this repo. When it has records to publish they
arrive as another source in the T03 manifest, not as a second content type this
repo curates.
**Record format.** What the source says; the source URL; the date retrieved;
the jurisdiction; the instrument and article or section; which internal
document or decision it bears on; who recorded it; when it should next be
checked.
**The hard rule, written into the format itself:** a record states what a
source said and when it said it. It does **not** state what the estate must
therefore do. Interpretation belongs to the repo making the decision, and a
record that reads as a ruling has failed. The estate has no legal function and
this repo must not grow one by accident.
**Staleness is sharper here than for internal documents.** External policy
changes without telling us, so a record is a dated snapshot, never current law.
The retrieval date is displayed as prominently as the content, and a record
past its check date is visibly stale rather than quietly wrong.
**Candidate register, to confirm rather than assume.** These are the domains
the estate's own activity implies; T06 should verify which actually apply
before treating any as in scope:
| Area | Why the estate touches it | Already live in |
|---|---|---|
| Data protection / erasure and retention | Tenant personal data, the erasure horizon, whether key destruction satisfies an erasure obligation | Tenancy Posture axis R; `rapp-postgres` ADR-0002 |
| Data residency | The `P4` placement level exists for exactly this and has no occupants yet | Tenancy Posture axis P |
| Public procurement | `vergabe-teilnahme` is a procurement-participation app and the delivery-lane reference implementation | `business-app-service-contract` |
| Identity assurance | The IAM Profile's `aal2` class drives live re-query rather than cached claims | `iam-profile_v0.3`; Tenancy Posture axis I |
| Sector and cybersecurity obligations | Whether the estate is an in-scope entity at all is itself an open question worth recording once | — |
| AI and agentic entities | The tenant taxonomy has an `agentic` grouping for financially enabled AI entities | ADR-0013 |
**Worked example already in hand.** The Tenancy Posture retention research holds a
finding of exactly this shape: data protection authorities have accepted key
destruction as erasure where physical deletion is disproportionate, under
conditions, and the EDPB has not formally endorsed it. True as recorded, likely
to move, and dangerous if ever restated as settled. Migrating that finding into
the T06 format is the acceptance test for the format.
**Acceptance:** the format holds that finding without distortion; the record
displays its retrieval date as prominently as its content; and a reader can get
from a record to the internal document it bears on, and back.
The consequence is the point: **this repo now does one thing.** Publication,
permanence, currency. That makes its ownership answerable and its boundary
defensible.
## Sequencing
@ -236,9 +199,20 @@ criterion on T02, not a preference.
- **Publication scope is canon and ADRs.** Not workplans, evidence, runbooks or
general documentation. Folded into T03 and INTENT.
- **Intake scope is regulation bearing on the estate.** Not a broader
public-interest corpus. T06 is specified accordingly, with an inclusion test
and a candidate register to confirm.
- **Owner is `the-custodian`**, which owns both policy and risk, and carries
the duty of deciding what must be discussed with the operator personally.
- **Regulatory intake left the repo.** It is `risk-nexus`'s (T06, withdrawn).
**Authority is three-way and stated, not held by one repo.** `policy-nexus`
owns the surface — addressing, permanence, rendering, currency.
`the-custodian` owns what counts as canon and when it is ratified; this repo
renders that judgement and never makes it, which is the guard against a
cross-repo reader accreting authority over "what is current".
`railiance-platform` owns the substrate — DNS, TLS, ingress, hosting.
The tell that the split is right: **T01 and T04 need different competences.**
T01 is a canon-process question — what supersession means, what a permanent URL
promises. T04 is infrastructure. A single owner would be weak at one.
The README's one-line description — "a convergence and publication point for
government policies" — reads broader than this. Worth updating so the repo does
@ -246,9 +220,7 @@ not attract the wrong contributions.
## Open questions for the operator
1. **Owner.** This workplan is `unassigned`. It spans infrastructure and canon
process and does not obviously belong to an existing repo's agent.
2. **Canon subdirectory scope.** `standards` and `architecture` are clearly
1. **Canon subdirectory scope.** `standards` and `architecture` are clearly
policy. Are `constitution`, `values`, `tpsc` and `projects` in or out? T03
needs a yes or no per directory rather than a wildcard.