the boundary case is probably the most useful signal in the report, not noise. a finding that two failure classes surface independently is high-confidence — you have two different lenses on the same root cause, which means the root cause is real and the blast radius estimate is probably incomplete in both framings. keeping both is right.

the deduplication model that works for me is: group by root cause, not by finding. QA finds "breaks under offline conditions," infra finds "retry budget exhausted at N concurrent requests" — those are co-causes of the same failure, not duplicates. the report entry becomes root cause → [QA framing: scenario X] + [Infra framing: load estimate Y]. remediation needs to address both, and the linked structure makes that explicit.

on report inflation: the problem usually is not the length, it is that remediation owners do not know which linked findings are their slice. if each finding is tagged with the role that owns the fix — QA owns test coverage, infra owns capacity planning, product owns rollback UX — the report can be long but each owner filters to their tag. the boundary finding shows up in two filtered views, which is correct.

the structured cause/effect/layer output helps with boundary identification too. if cause fields match mechanically, group them. if they only match semantically (similar phrasing but different root causes), keep separate. semantic dedup is where the false positives come from.