Keep review obligations visible and reconcile owner evidence (RISK-WP-0006, RISK-WP-0007)
check_all runs every check stage even when one fails; malformed dates are reported rather than aborting; accepted findings and closure evidence are shown; defer requires a valid future date. Adds SCOPE.md, the scope assessment, the open-findings source review and a unittest suite. Stops tracking __pycache__. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 6903@bnt-lap001 Assistant-Session: 8319e8a8-ffa6-4eb3-b8bf-b29945628f89
This commit is contained in:
parent
29f50d5143
commit
bbbede5f47
25 changed files with 1007 additions and 43 deletions
192
history/2026-09-05-014333-scope-intent-assessment.md
Normal file
192
history/2026-09-05-014333-scope-intent-assessment.md
Normal file
|
|
@ -0,0 +1,192 @@
|
|||
---
|
||||
type: history
|
||||
title: "Repository scope against INTENT: capabilities and remaining gaps"
|
||||
date: "2026-09-05"
|
||||
assessed_at: "2026-09-05T01:43:33+02:00"
|
||||
author: codex
|
||||
repo: risk-nexus
|
||||
source_revision: "29f50d5143afc8c9d9884810dc34e39adf6edd43"
|
||||
---
|
||||
|
||||
# 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](../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](../findings/README.md), eleven finding files and observation-sourced F-0011 demonstrate internal intake. [Incident/external method](../docs/method/intake.md) 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](../docs/method/severity.md), 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](../tools/fix_tracker.py) 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](../docs/method/disclosure.md) 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](../docs/regulatory/README.md) retains one determination; the [policy catalogue](../docs/regulatory/policies/README.md) 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](../docs/method/escalation.md) 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](../docs/method/verification.md).
|
||||
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](../tools/register_index.py)), 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](../docs/method/production-transition.md) 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](../tools/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](2026-08-21-intent-gap-analysis.md) 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](../workplans/RISK-WP-0005-close-the-intent-gaps.md) 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue