risk-nexus/SCOPE.md

SCOPE — risk-nexus

Updated 2026-09-05 (Europe/Berlin), including RISK-WP-0006 and RISK-WP-0007. This describes the checked-in capabilities; INTENT.md remains the intended remit. Evidence and remaining gaps are in the dated assessment.

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 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 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 operator 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. 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 remains proposed.
• 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 eleven findings: eight fixed, two open and one accepted; three notes; one regulatory determination; four full policies out of thirteen catalogue entries; and three verification records. Both open findings now carry owner workplan tracking and explicit pending runtime/provider evidence. The accepted finding carries a resolvable determination and an overdue substantive review, displayed as a recorded acceptance obligation. Two findings are marked published, eight pending handover, and one embargoed. These are repository records, not a fresh verification of the affected systems or published sites.

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/operator. 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.