Seed INTENT: risk register, regulatory intake, escalation duty

Owned by the-custodian alongside policy-nexus, with the duty of deciding what
must reach the operator personally.

Three things had nowhere to live. Findings landed in whichever document
discovered them - the estate's largest known gap is currently open question 3
in an unratified draft, with no owner, severity or date. Disclosure had no
mechanism, only publish-now or forget, which is fine in build mode and wrong at
production. And regulation was researched at the moment it was needed and never
retained.

Regulatory intake moves here from policy-nexus T06: deciding what a rule
demands of us is a judgement about risk, not an act of publishing. That also
leaves policy-nexus doing one thing, which was the point.

Two constraints written in deliberately. This repo does not fix - findings
route to the repo owning the defect, because a risk service that fixes becomes
a second engineering team with no boundary. And it does not block delivery in
build mode; if that changes it will be a decision recorded here, not a habit
that accretes.

The escalation rule is named as unwritten rather than invented. Getting it
wrong in either direction fails: escalate everything and the operator becomes
the queue, escalate nothing and the register is where serious things go quiet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

INTENT.md

@@ -0,0 +1,113 @@
+# INTENT — risk-nexus
+
+## Why this repo exists
+
+`risk-nexus` is where the estate holds what it knows is wrong, what might be
+wrong, and what the outside world requires of it — with a severity, an owner,
+and a date. It serves `risk.coulomb.social`.
+
+**Owned by `the-custodian`**, alongside `policy-nexus`. One of its duties is
+deciding what must reach the operator personally rather than sitting in a
+register.
+
+Before this repo existed, three things had nowhere to live.
+
+**Findings landed in whichever document was open.** The estate's largest known
+gap — that no consumer's tenant boundary is verified anywhere, which is
+Broken Object Level Authorization, top of the OWASP API Security Top 10 since
+that list launched — is currently open question 3 in an unratified draft
+standard. It was found by research, it has no owner, no severity, and no date.
+A finding recorded in the document that happened to discover it is a finding
+that disappears when that document is superseded.
+
+**Disclosure had no mechanism.** In build mode the estate publishes everything,
+which is right: there are no users to expose. That stops being right at
+production, when the same architecture disclosure a consumer must read becomes
+a map for an attacker. There is currently no way to hold a finding while it is
+fixed and publish it once it is — only publish-now or forget.
+
+**Regulation was consulted and discarded.** Whether key destruction satisfies
+an erasure obligation, whether the estate is an in-scope entity under a given
+regime, what a procurement rule requires — each was researched at the moment
+someone needed it and never retained. The same question gets asked twice and
+the answer silently expires.
+
+## What it owns
+
+- **Finding intake.** Security, architecture, operational and compliance
+  findings, from any source: research, review, incident, external report.
+- **Severity and triage.** What this actually risks, how likely, how bad.
+- **Remediation tracking** — not remediation. Who owns the fix, what state it
+  is in, and whether it has stalled.
+- **Disclosure timing.** Whether a finding is publishable now, embargoed until
+  fixed, or permanently restricted; and the record that a delay was deliberate
+  rather than a document quietly going missing.
+- **Regulatory intake**, scoped to regulation bearing on the estate — rules
+  constraining data it holds, markets it sells into, or obligations it has
+  taken on. Moved here from `policy-nexus`, because deciding what a rule
+  demands of us is a judgement about risk, not an act of publishing.
+- **The escalation rule.** What must be discussed with the operator personally
+  rather than recorded and routed. This is the duty `the-custodian` carries as
+  owner, and the rule itself must be written down rather than exercised by
+  instinct.
+
+## What it does not own
+
+- **Fixing anything.** A finding is routed to the repo that owns the defect,
+  which fixes it under its own workplan. A risk service that fixes things
+  becomes a second engineering team with no boundary.
+- **Publication.** `policy-nexus` is the publication surface. This repo decides
+  *whether and when* something is published; it does not host it.
+- **Blocking delivery.** In build mode a finding is information, not a gate.
+  If that changes it will be a deliberate decision recorded here, not a habit
+  that accretes.
+- **Legal advice.** A regulatory record states what a source said and when.
+  What the estate must therefore do is the owning repo's decision.
+- **Deciding what canon says.** Canon is `the-custodian`'s and NetKingdom's. A
+  finding may say a standard is wrong; it cannot amend one.
+
+## The failure this repo must avoid
+
+A risk register nobody reads is worse than no register, because it converts
+"we did not know" into "we knew and did nothing" while changing no behaviour.
+Two consequences for design:
+
+- **Findings must expire or escalate.** A finding that has sat untouched past
+  its review date is itself a finding. Silence is not resolution.
+- **The register must be small enough to read.** Recording everything makes
+  nothing legible. If a finding would not change anyone's decision, it is a
+  note, not a risk.
+
+## The escalation duty
+
+Most findings should be routed and tracked without the operator's attention.
+Some must not be. Deciding which is the substance of the oversight `the-
+custodian` holds here, and getting it wrong in either direction is a failure:
+escalating everything makes the operator the queue, escalating nothing makes
+the register a place where serious things go quiet.
+
+The rule is not yet written. Candidate triggers, to be settled rather than
+assumed: anything exposing real tenant data; anything creating a legal or
+regulatory obligation; anything requiring spend; anything where two repos
+disagree about who owns the fix; and any finding whose remediation has stalled
+past a stated interval.
+
+## Relationship to the rest of the estate
+
+`risk-nexus` reads from everywhere, decides severity and timing, and routes
+work to the repo that owns it. It publishes through `policy-nexus` and never
+directly. Like that repo, it is downstream by construction and must not become
+a second source of truth — a finding is a claim about a system, and the system
+remains authoritative about itself.
+
+The first content is already waiting: the unverified tenant boundary, the
+absent noisy-neighbour characterisation, the missing quality-of-service
+vocabulary, and the erasure-versus-audit tension — all currently open questions
+in NetKingdom's *Tenancy Posture* standard, which is a draft and not a register.
+
+## What good looks like
+
+Nobody is surprised. A gap that was known is recorded with a severity and an
+owner, a regulation that applies was found before it was needed, a fix that
+stalled was visible while it stalled, and the things that genuinely needed the
+operator's judgement reached them without the things that did not.

README.md

@@ -1,3 +1,14 @@
 # risk-nexus
 
-A risk management service.
+Risk register and regulatory intake for the estate. Serves
+`risk.coulomb.social`. Owned by `the-custodian`.
+
+Holds findings — security, architecture, operational, compliance — with a
+severity, an owner and a date; decides whether and when each is published; and
+decides which must reach the operator personally rather than sitting in a
+register.
+
+It does not fix things: findings route to the repo that owns the defect. It
+does not host: `policy-nexus` is the publication surface.
+
+- Intent: `INTENT.md`