A red-team scan is re-run against the same application every week. How would you give each report item an identity that survives across runs, so a fixed item does not reappear as brand new and a genuinely new failure is not silently absorbed into an old one?

### Why this is a different problem from deduplicating one run Within a single run, a bad grouping key merges defects or explodes the count, and the damage is contained to that report. Across runs, a bad identity destroys the **trend line** — and the trend is the only thing most stakeholders actually read from a recurring programme. "Are we getting better?" is answerable only if "the same finding" means the same thing in week one and in week nine. Everything about a recurring scan works against that. Generated prompts are re-generated. The tool's own catalogue of techniques shifts between versions, renaming and re-numbering cases. The target application changes underneath, so surfaces appear and disappear. Any identity built on those things is re-minted every week. ### The design, in three parts **A key made of durable attributes.** The identity is derived from what a remediation would change: the control that failed, the behaviour the model produced, the entry surface it was reached through. Everything the scanner varies (prompt text, ordering, random seed) and everything about the run itself (timestamp, attempt index, the tool's generated case id) is excluded by construction. The diagnostic tell that a team skipped this step is a weekly report whose item count is stable while almost no identifiers repeat — the underlying defects are the same and the scheme cannot see it. **A register, not a recomputation.** Store each assigned identity with its key and its members, and match each week's items against that store. Do not recompute identity from scratch per run, because a key that shifts even slightly then reassigns everything at once. **Explicit lineage for splits and merges.** Triage learns things: a bucket turns out to be two defects, or two items turn out to be one. Both are normal and both must be expressed as parent and child rather than as deletion and creation. Without lineage, a legitimate re-split reads as a regression and a merge reads as a fix, and the trend line reports application changes that never happened. ### Three rules that carry most of the value **Fail toward review, never toward creation or merge.** An item matching nothing in the register lands in a human queue. Auto-creating grows the register forever and makes the count meaningless. Auto-merging on a fuzzy match is the more dangerous reflex, because it hides genuinely new defects inside old identifiers and is invisible in the numbers — nothing looks wrong, the count is stable, and a new failure is silently attributed to something already being worked. **Status is separate from presence.** An item absent from this week's run is not fixed. It may not have been probed at all — catalogue changed, surface unreachable, budget cut short — or the control is probabilistic and simply did not fail this time. Closure requires positive evidence: an accepted fix, or a targeted re-test at a stated attempt count. "Not observed this run" is its own state and belongs in the schema. **A named owner.** The register is a maintained dataset. Without someone accountable for the weekly match queue it decays within a couple of months into a list nobody trusts. ### What it costs The scan is automatable; the register is not. Realistic ongoing cost is a standing hour or two of analyst time a week to work the unmatched queue and record lineage, plus the engineering to keep the key computable as the tool changes. That is the item to be honest about with whoever asked for weekly scanning: if the trend is not worth roughly a day a month of a skilled person, the correct answer is to publish per-run reports and stop claiming a trend exists. A register maintained badly is worse than none, because it produces a graph that looks authoritative and is not. ### Where the number misleads - **Item-count stability is not stability.** A flat count with total identifier turnover means the scheme is re-minting, not that the application is steady. Read turnover, not totals. - **A drop in open items after a tooling upgrade is almost never remediation.** When the tool renames or regenerates its catalogue, keys reshape and old items stop matching. That looks like closure. Any week where identifier turnover spikes without a corresponding application change should be investigated as a tooling change first. - **"Closed" built from absence inflates the fix rate.** Track how many items were closed by re-test versus by silence; if the second number is large, the programme's headline improvement is mostly bookkeeping. - **A rising manual-match share is a leading indicator, not noise.** It means the key is drifting away from what the tool now emits, and the trend is degrading before anyone notices in the graph. ### What you check Weekly: the manual-match share, the split of closures into re-tested versus not-observed, and identifier turnover against the application's own change log. Before publishing any trend to leadership: confirm the tool version and its catalogue did not change between the two points being compared.