risk-nexus/history/2026-09-05-014333-scope-intent-assessment.md

type	title	date	assessed_at	author	repo	source_revision
history	Repository scope against INTENT: capabilities and remaining gaps	2026-09-05	2026-09-05T01:43:33+02:00	codex	risk-nexus	29f50d5143

Scope against intent

The repository implements a usable, manually operated risk register with reporting aids. It does not yet deliver the full intended assurance that known risks cannot go quiet, regulation stays current, or reports can arrive from any source. SCOPE.md was absent and has been created to describe the actual capability and its dependencies.

This assessment reads the local implementation, records and workplans, and runs read-only reports. It does not re-grade findings, verify external fixes, check publication endpoints, or reassess the legal correctness of regulatory texts. External operational claims below are identified as recorded or unverified. The timestamp prefix uses Europe/Berlin; the inspection timestamp is 2026-09-04 23:43:33 UTC. The existing modified Python bytecode file was left alone.

INTENT ownership claims

INTENT claim	Assessment	Evidence and boundary
Finding intake from research, review, incident and external report	Partial	Filing contract, eleven finding files and observation-sourced F-0011 demonstrate internal intake. Incident/external method supplies a procedure but records the external contact as only routed. No intake service or incident clock is implemented here.
Severity and triage	Implemented as a judgement workflow	Severity method, dated rulings and all three live records carry grades. Tools surface absent grades but do not compute or independently verify them.
Remediation tracking: owner, state and stalls	Partial	Fix tracker reads supported owner workplans and flags inactivity. All three live findings currently report no fix tracking; local workplan commits are only a progress proxy.
Disclosure timing and deliberate holds	Implemented records; partial follow-through	Disclosure method and F-0010 record a conditional embargo. Public/pending/published metadata distinguishes decisions from delivery, but embargo review deadlines and pending publication are not actively checked.
Regulatory intake and retained research	Partial	Regulatory collection retains one determination; the policy catalogue names thirteen positions, four written in full. Policy review dates are outside tool discovery.
Written escalation rule and operator attention	Rule implemented; delivery procedural	Escalation method defines triggers and delivery states. The checker prints pending and seven-day-unacknowledged items; it does not send, retry, acknowledge or apply defaults.

The intended boundaries are substantially preserved: no remediation service, publication host, legal-advice service or canon authority has been added. Verification is bounded by the verification method. There is a wording conflict to resolve: the adopted review method says re-scoring occurs before a production declaration completes, while INTENT excludes delivery blocking and the proposed transition method says it does not gate the event. No delivery gate is implemented.

Gaps and concrete completion criteria

1. The review entry point can suppress the overdue reports

Priority: high. Owner: risk-nexus. make check fails on stale REGISTER.md before running the register or inbox checker. The index embeds today's date and time-dependent due labels (generator), so the passage of time alone can stop the operational report. The direct checker currently reports all three live findings overdue and a two-day heartbeat gap.

Separate index validation from report execution so a stale index still exposes due work, heartbeat and inbox evidence. Completion means the stale-index case reports both the failure and the operational work list. Actual overdue reviews must be performed with evidence; regenerating the index cannot satisfy them.

2. Regulatory policies can silently expire outside the review loop

Priority: high. Owner: risk-nexus. register_lib.regulatory() uses a non-recursive docs/regulatory/*.md scan. All four full policies are nested in policies/, have next_check: 2026-08-20T21:30:00Z, and are omitted from both the due report and record_check.py's eligible records. Method review intervals likewise have no general due-date reporting. This contradicts INTENT's retained, non-silently-expiring regulatory knowledge requirement.

Discover and review the full policy records, make them eligible for recorded outcomes, and define how method review dates are maintained. Distinguish the nine catalogue-only entries from sourced determinations, with owners and dates for elaboration when activation approaches. Completion means an overdue nested policy appears in the work list and can receive a recorded review.

3. External and incident intake remain incomplete in operation

Priority: high. Owners: risk-nexus; policy-nexus and the-custodian for contact delivery. The intake method still says no external contact exists and describes a routed proposal. Local evidence establishes neither a delivered contact nor a tested external-to-register path; it does not establish the current state of the whole estate. Incident fields and urgent timing are prose only: the tools do not process incident or first_observed, enforce incident cadence, or report the notification deadline described by the method. No incident-marked finding was found in this checkout.

Obtain evidence of a discoverable contact and a report reaching triage. Add deadline handling for incident records and demonstrate an urgent intake exercise with an owner and escalation record. The legal basis for any deadline remains subject to the regulatory record's own review; this assessment does not validate it.

4. Remediation visibility is incomplete for the live register

Priority: high. Owners: risk-nexus and the named system owners. F-0010, F-0011 and accepted F-0008 all have unset tracking. The inbox check finds a newer F-0011 remediation notice naming QONTO-WP-0005, so the register is demonstrably behind incoming evidence. The notice is not proof the defect is fixed.

Read and reconcile that evidence, obtain the applicable tracking records, and record an explicit reviewable acceptance obligation where a fix plan is not appropriate. The tracker resolves only a workplan ID syntax and expected file layout, uses whole-file commit time rather than task transitions, and does not verify deployed state. Completion means every live finding has an actionable tracking or acceptance record and inactivity remains visible independently of register check frequency. Task shorthand and archived completed-status handling also need care: the parser requires full IDs, and the appended [archived] suffix prevents the current exact completed-state comparison from matching.

5. Expiry, escalation and execution still depend on an attending session

Priority: high. Owners: risk-nexus; activity-core for execution evidence. The tools report lateness and suggested actions but do not apply them. A heartbeat printed by the same command nobody runs cannot provide independent delivery assurance. The two activity definitions request work; their presence does not prove scheduler registration, execution, session completion or operator receipt. The observed overdue records show the intended cadence is not currently reflected in recorded outcomes. No escalation is presently reported as awaiting an answer.

Demonstrate scheduled instruction delivery through to a completed review, and an independently visible missed-run condition. Demonstrate acknowledgement and the single permitted re-raise/default path for an escalation. Human judgement should remain required; reliable delivery need not automate grading or send repeated nags.

6. Disclosure and production obligations are recorded but not fully followed

Priority: medium. Owners: risk-nexus, policy-nexus and the-custodian. The checker lists embargo conditions but never compares embargo_review with the clock. It does not list pending publication handovers; eight findings have that state, including fixed records outside the normal live watch list. Two findings are marked published; those metadata were not verified against a site.

The production definition remains proposed, contains historical counts and refers to F-0007's former acceptance although that finding is now fixed. The checker reports only live flagged findings (currently F-0008), not an event-driven acceptance expiry or policy activation process.

Completion means due embargo decisions and pending handovers remain actionable independently of closure; the custodian settles the transition definition and conflicting declaration wording; an event record identifies the applicable re-scores, acceptance decisions and policy activations without silently adding a gate.

7. Coverage measures mentions, not whether systems have been assessed

Priority: medium. Owners: risk-nexus with estate inventory owners. coverage.py combines system, owner and reporter strings, including values such as estate and per-consumer, on request. It has no last-assessed date, assessment scope or evidence for a clean assessment. Thus a mentioned repo is not necessarily assessed, and an unmentioned repo is unknown. The current inventory request did not yield a denominator; the historical 7-of-117 count must not be presented as current coverage.

Record assessment provenance and dates against canonical repo identities, with explicit unknowns. Completion means a clean assessment, a reported defect and an unassessed system can be distinguished without turning this repo into the estate's scanner or remediation team.

What good looks like: current result

• Known gaps have severity and owner: met for the recorded live findings; completeness across the estate is unproven.
• Applicable regulation is found before needed: not established. The previous assessment records retrospective discovery of already-live obligations. A catalogue improves retrieval but does not erase that history or provide ongoing horizon scanning.
• Stalled fixes are visible while stalled: partially supported by a local file reader, presently limited by missing tracking and overdue reviews.
• Necessary operator judgement is reached without noise: procedures and historical rulings exist; current end-to-end delivery assurance is unverified.
• Findings expire or escalate; the register stays readable: the small register and note floor are implemented. Timely follow-through remains a process requirement rather than a guaranteed outcome.

WP-0005 and STATE.md call the previous seven gaps closed. The delivered tools and procedures are real progress, but routing a contact request, drafting a transition definition, printing a heartbeat and counting mentions do not establish those end-to-end outcomes. Historical completion records were preserved; this assessment records the remaining capability gaps rather than rewriting their history.

Verification results

Read-only check	Observed result
PYTHONDONTWRITEBYTECODE=1 make check	Failed at stale index, Make exit 2; subsequent report stages did not execute.
PYTHONDONTWRITEBYTECODE=1 python3 tools/register_check.py	Exit 0; three live findings, all overdue by about 62–64 hours; two-day heartbeat warning; three missing fix trackers; one overdue top-level regulatory record; no pending operator escalations.
PYTHONDONTWRITEBYTECODE=1 make fixes	Exit 0; all three live findings report NO FIX TRACKING.
PYTHONDONTWRITEBYTECODE=1 python3 tools/inbox_check.py	Exit 0; nine messages returned, including a newer F-0011 remediation notice dated 2026-09-04. No messages were acknowledged or sent.
PYTHONDONTWRITEBYTECODE=1 make coverage	Exit 0; eleven distinct mention strings; inventory endpoint unavailable within the tool's attempts, so current denominator unknown. The separate inbox request succeeded.

Warnings returning zero are advisory output, not a clean bill of health. The review tools were run directly after the stale-index failure to inspect their results without regenerating unrelated files or claiming reviews had happened.