risk-nexus/SCOPE.md

# SCOPE — risk-nexus

Updated 2026-10-04 (Europe/Berlin), including the dependency audit under RISK-WP-0005 and RISK-WP-0007. This describes the checked-in capabilities;
[INTENT.md](INTENT.md) remains the intended remit. Evidence and remaining gaps
are in the [dated assessment](history/2026-09-05-014333-scope-intent-assessment.md).

`risk-nexus` is a file-based risk register and regulatory reference collection,
owned by `the-custodian`, with Python command-line tools for indexing, review
bookkeeping and reports. Humans or agent sessions make the judgements and act
on the reports. This repository contains no web service, intake API, deployment
or independent scheduler, and does not itself serve `risk.coulomb.social`.

## What it can do

| Capability | Implemented scope and evidence |
| --- | --- |
| Record findings and notes | YAML front-matter and Markdown in `findings/` and `notes/`; [filing contract](findings/README.md) separates reporter facts from register grading. Research, review and observation have produced records. Incident intake is a written procedure; external-report contact provisioning remains routed elsewhere. |
| Grade and explain decisions | [Method instruments](docs/method/) define severity, disclosure, escalation, review, dependencies and verification. Dated rulings and finding histories record applied decisions. Scoring and acceptance are judgements, not computed decisions. |
| Generate a readable register | `make register` builds `REGISTER.md` from findings and notes, including constraints, finding waits, embargoes and cadence. It is an index, not the source of truth. |
| Report review work | `tools/register_check.py` reports due checks, missing grades, selected malformed fields, unknown statuses, waits/defaults, tracked fix state, embargo conditions and review dates, pending handovers and escalations, production re-score flags and regulatory reviews including full policies. `fixed` and `withdrawn` leave the ordinary watch list, but disclosure obligations remain visible; accepted, mitigated and unknown statuses remain watched. |
| Record review outcomes | `make checked ARGS="<id> clean\|moved\|defer ..."` updates an eligible record's timestamps, checker, cadence and review history, then regenerates the index. Clean climbs one rung from `instant` toward `1q`; moved resets; defer records a supplied date and reason. Completion of the review procedure and founder authorization for deferral are not enforced by the tool. |
| Read remediation records | `make fixes` resolves supported workplan/task IDs in live findings against sibling checkout files under `/home/worsch`, including an archive convention and YAML task blocks with arbitrary field order. It reports status, missing tracking and severity-based inactivity windows using the workplan file's last commit date. This is a proxy for recorded activity, not proof of task progress or a deployed fix. |
| Keep closure obligations visible | Live findings can state `closure_condition`, reported independently of source workplan completion. An accepted finding without fix tracking reports its recorded accepter, ending condition, resolvable regulatory determination and review date; missing fields still produce an incomplete-acceptance/missing-tracking warning. This does not verify that acceptance remains valid. |
| Check inbox freshness | `tools/inbox_check.py` reads up to 100 State Hub messages and matches names/IDs against live findings checked earlier. It reports potentially newer evidence; it neither interprets nor acknowledges messages. |
| Count reporting coverage | `make coverage` counts names appearing as system, fix owner or reporter and compares them with State Hub repo slugs when available. It measures mention coverage, not assessment coverage or assurance. |
| Retain regulatory research | One determination in `docs/regulatory/`, a thirteen-entry policy catalogue, and four full policy records. Sources, dates and activation conditions are stored for retrieval. Review discovery includes nested full policies; catalogues are excluded. All discovered records accept recorded outcomes. |
| Record disclosure and handover | Public, embargoed and restricted states express disclosure decisions. Finding metadata records publication status and addresses supplied by `policy-nexus`. Publication and access control are external; a `public` decision does not prove a completed handover. |
| Describe scheduled work | Two `activity-definitions/` files describe an hourly inbox watch and a daily 07:15 Europe/Berlin sweep. They ask an external activity system to instruct a session. They do not execute reviews or guarantee that a session acts. |

## Operating dependencies and limits

- Python 3, PyYAML, Make and Git are required for the relevant local commands;
  no dependency manifest is checked in. `make test` runs isolated regression tests.
- State Hub reads use hard-coded `http://127.0.0.1:8000` endpoints. Fix tracking
  assumes local sibling repositories and specific workplan naming/formatting.
- `make check` verifies the index and runs register and inbox reports even if a
  prior stage fails, returning nonzero for any failed stage. Rendering includes the
  current date and time-dependent due labels, so staleness need not mean source
  records changed. `make due` runs the full obligation report and inbox check directly,
  including nested policies, due embargo reviews and pending publication handovers
  across closed as well as live findings.
- Reports do not send escalations, apply defaults, expire acceptances, lift
  embargoes, close findings or block delivery. Operational warnings generally
  return exit code zero. Selected validation exists, not comprehensive schema
  enforcement; invalid date strings are tolerated by parsing and selected fields
  are reported for repair. Deferrals require valid future dates.
- Incident deadlines and production-transition events
  are procedural obligations without dedicated automated deadline/event handling.
  The production-transition definition is `adopted`, reconciled from the
  committed CUST-WP-0063-T04 owner decision; this does not declare a transition.
- Historical verification records distinguish owner evidence, checkout evidence
  and live reads. They do not establish current infrastructure access or health.

## Current recorded footprint

The checkout contains fifteen findings: nine fixed, four open and two accepted;
three notes; one regulatory determination; four full policies out of thirteen
catalogue entries; and three verification records. Qonto's source-only acceptance
is now recorded with its founder decision and ending conditions, retaining the
runtime closure path. The three Emergent findings remain open pending owner
acceptance/provider evidence; their historical 0.2.3 retest and current 0.2.6 Whitehat review have explicit limits.
T07 accepts the bounded 0.2.6 review gate only and withholds full provider acceptance.
Two findings are marked published, nine pending handover, and four have no
completed handover recorded. No finding is currently embargoed. The audit
retention acceptance and substantive regulatory reviews remain due. These are
repository records, not fresh verification of affected systems or published sites.
All seven workplans and 37 tasks are complete; remaining external/recurring
obligations are reported without inventing new workplans. The 2026-10-04
dependency audit in RISK-WP-0007 names owner records, missing tracking and
the evidence required for progress. The approved external contact route has
a selected URI under CUST-IN-0011; provisioning/delivery remain unverified.

## Ownership boundary

The repo owns risk intake records, grading, disclosure decisions, regulatory
research retention and escalation/review procedures. Fixes and incident response
belong to system owners; publication belongs to `policy-nexus`; canon and
estate-level decisions belong to the custodian and the founder, exercising `GOVERN @ estate`. It provides neither
legal advice nor compliance certification, estate-wide detection, or a delivery
gate. Completing the intended remit does not require taking over those roles.