## TL;DR
If the findings data did not change, the count cannot change; a drifting total means each draft is regenerated from scratch and the model adds, drops, or merges findings per draft. Freeze the findings as a versioned data set after triage, render every draft from that set, and diff each draft's count against the set so unexplained drift blocks delivery.

```text
agent's finding count changed between report drafts with no new scan data
```

## Use this when
- Two drafts of one report show different finding totals while no rescan or triage happened between them.
- Individual findings appear or vanish between drafts without any note.

## Not for this skill when
- A rescan, retest, or human triage session occurred between drafts. Counts should change then, with the change logged.
- The drafts are for different scopes or dates. Compare like with like before calling it drift.

## Steps
1. Gather the drafts and compute each one's finding list as titles plus hosts, then diff the lists to name exactly which findings moved. Verify: Verify: the drift is itemised per finding, not just a total difference.
2. Confirm from run records that no new scan data, import, or triage decision landed between the drafts. Verify: Verify: the inputs were identical, proving the generation step is the variable.
3. Freeze the canonical findings set: export the triaged findings to a versioned file with an id and a hash, and declare it the only report input. Verify: Verify: the frozen set exists and its hash is recorded in the QA log.
4. Change the drafting flow to render from the frozen set without re-deriving findings, so the model's job is prose around fixed rows, never the rows themselves. Verify: Verify: two renders from the frozen set produce identical finding lists.
5. Add a draft check: each generated draft's finding count and id list are compared with the frozen set, and a mismatch blocks the draft from being shared. Verify: Verify: deleting a row in a test render trips the check.

## Variant phrasings
### finding count changed between drafts no new data
The symptom phrasing.
### freeze findings dataset versioned render drafts from it
The design phrasing.
### agent regenerates findings each draft adds drops issues
The root-cause phrasing.

Compatibility: Compatibility: any agent drafting workflow; needs only a JSON export of findings and a hash for the frozen set.

## Why it happens
A model asked to write the report again will write a similar report, not the same one: summarising merges two findings here, an emphatic paragraph promotes an observation there. If findings live only inside generated prose, there is no stable object to count, so totals drift innocently and continuously. Freezing the data separates the stable facts from the variable prose.

## Edge cases / pitfalls
- Legitimate late triage should create a new frozen version with a change note, not an in-place edit; the version history is the audit.
- Clients comparing drafts will find drift themselves; a short change note with each draft pre-empts the credibility damage.
- Freeze supporting numbers too: counts by severity and host totals should derive from the same frozen set.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Pjxk0IbhfR-yrt9HAQVIDw