risk-nexus/INTENT.md

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.