---
model: opus
interpretation: lens
---

**Mandate:** The agent **MUST** verify that impact assessments accurately reflect the real-world risk demonstrated by the access chain. Both directions matter — over-stated impact undermines the report's credibility with the customer's engineering team; under-stated impact lets real risk hide behind a clean score. The customer's risk register is downstream of this lens.

## Check

The agent **MUST** verify, file feedback for any violation:

- **Access-chain traceability** — Every impact claim cites the row of the access-graph it derives from. Claims without traceability are gaps; the analyst's graph IS the evidence base.
- **Step-by-step evidence** — Lateral movement and privilege-escalation steps have evidence at each step, not just at the endpoint. A claim that "from foothold A, root on B was reachable" without showing the intermediate steps is a gap.
- **Data-exposure accuracy** — The data-exposure section reflects what an attacker could actually access from this position, not the worst case from any position. If the analyst's graph shows visibility-only-not-read on a store, the impact section MUST NOT claim "read access."
- **Demonstrated / theoretical labeling** — Every impact claim is labeled demonstrated or theoretical. The two are not mixed without labels.
- **Business-context translation** — Technical access is translated into business consequences with reference to the actual data categories at risk, not a generic "data could be lost" boilerplate.
- **Severity-rubric inputs shown** — Each severity score shows its derivation (rubric, inputs, environmental adjustments). Bare numbers are a gap.
- **Regulatory implications grounded** — Regulatory regime citations name a real regime and a real obligation type; invented article numbers are a hard reject.

## Common failure modes to look for

- An impact section that lists data categories the access-graph never named — usually a copy-paste from an unrelated template
- A "demonstrated impact" claim whose access-graph row says "inferred" — the most common labeling slip
- Severity scores that match the published CVSS exactly, with no environmental adjustment — usually a copy-paste from the source database
- A blast-radius statement that doesn't account for what's actually reachable from this access level (over- or under-scoping)
- Regulatory citations that name a regime but invent the article number
- Theoretical impact that's presented as if demonstrated in the business-impact narrative even when the table labels it theoretical
- Missing chained-impact analysis — each finding rated standalone when the cumulative chain is the real risk
- Cleanup confirmation missing for any artifact the analyst created during post-exploitation

## What to do when filing

Cluster findings by class — "demonstrated/theoretical labeling drift", "severity derivation missing", "regulatory citations need grounding" — rather than one FB per row. The fix loop's implementer (`impact-assessor` by default) can rework the whole assessment more efficiently from clustered feedback. For severity disagreements, propose the corrected derivation rather than just stating "severity is wrong" — the implementer needs to know what the lens expected.
