## TL;DR
When every medium becomes high, the mapping table is wrong, not the findings: an off-by-one band edge, a source severity scale mapped carelessly, or a template default overriding real scores. Centralise severity derivation so the label is computed from the numeric score by one tested mapping, repair the mapping, and regenerate rather than hand-editing labels across the report.

```text
agent's severity mapping flipped medium findings to high across the report
```

## Use this when
- A report's severity distribution skews high and spot checks show medium-scored findings labelled high.
- The mislabelling is uniform across tools and templates, pointing at shared mapping code.

## Not for this skill when
- One finding was raised by a human for business context and documented. Leave it, and its rationale, alone.
- The client contract defines its own severity bands. Map to the contract bands, not the generic ones, and say so in the report.

## Steps
1. Sample five flipped findings and write down each one's numeric score, source severity, and report label. Verify: Verify: the pattern is consistent, for example everything at or above a medium score renders as high.
2. Find every place severity is set: source import mapping, band thresholds, template defaults, and any model-written label; list them. Verify: Verify: you can point at each code path that can produce a label.
3. Decide the single source of truth: the label is derived from the numeric score by one band table, and source severities are converted to scores at import, never directly to labels. Verify: Verify: the design leaves exactly one place where a label is computed.
4. Fix the band table against the standard the report claims, commonly the CVSS qualitative bands, and add unit tests at every band boundary value. Verify: Verify: boundary scores, such as the exact medium to high cut, produce the expected labels in tests.
5. Regenerate the report from stored findings and diff severity counts before and after, attaching the explanation to the QA record. Verify: Verify: the distribution changes only where the mapping was wrong, and the diff is reviewable.

## Variant phrasings
### severity band thresholds off by one cvss mapping
The threshold phrasing.
### all mediums reported as high agent severity inflation
The symptom phrasing.
### single source truth severity derivation report pipeline
The design phrasing.

Compatibility: Compatibility: any agent reporting pipeline with scored findings; band tables must match the scoring version the report uses.

## Why it happens
Severity labels feel like words, so pipelines let several components produce them, and each drifts: an importer maps a five-point source scale onto four labels generously, a threshold is typed from memory, a model polishes medium into high for emphasis. Uniform flipping across a whole report is the fingerprint of a shared mapping bug, which is why the fix is centralisation and boundary tests, not proofreading.

## Edge cases / pitfalls
- If a draft with flipped severities reached the client, issue a corrected version with a clear note; severity inflation damages credibility fast.
- Keep the numeric score visible beside every label so readers can sanity-check the mapping at a glance.
- Contract-specific bands are fine, but print the band table in the report appendix so the mapping is auditable.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_aZngnpnWC0QJFwVU9uoG_w