Handle corrections to a vulnerability data post in the open: fix the figure, add a dated note near the top that says what changed, and keep a short log with the old value, the new value and the cause. Readers who cited you can then update, and trust in the rest of the post stays intact.
Why data posts need a policy
A data post makes many small claims, and each can be wrong for a boring reason: a filter was applied twice, a snapshot was stale, a denominator was off by one. Because other writers copy your numbers, an uncorrected error spreads. A visible correction is a feature of a careful post.
There is also a second reason for updates that is not an error. The underlying data changes. KEV adds entries, EPSS rescoring moves values daily, and OSV records are edited or withdrawn. Those are updates, not corrections, and the two should be labeled differently.
Corrections versus updates
| Type | What happened | How to label |
|---|---|---|
| Correction | Your analysis was wrong | "Corrected 22 October 2026: the count was 311, not 331" |
| Update | The source changed after you wrote | "Updated with the 2026.10.23 release" |
| Clarification | Wording was ambiguous | "Clarified that shares are by entry" |
Never silently edit a figure. A reader who saved your old number will think either they or you made a mistake.
What goes in the log
Keep a plain file next to the script, with one row per change:
- Date of the change, in UTC.
- Where in the post.
- Old value and new value.
- Cause, in one sentence.
- Who found it, if they agreed to be named.
- The snapshot hash used for the fix.
If the cause was a method problem, such as an inner join dropping rows, say so. See the join post for that exact trap.
How to find your own errors first
- Rerun the script from scratch on the frozen file. See freeze a dataset.
- Check that every number in the text appears in a table, and every table total matches its text.
- Compare two dated snapshots of the same source to spot changes in entries you described. A single snapshot cannot show an edit, so keep the old file.
- Ask a colleague to reproduce one table without your help.
Wording
Say what was wrong, plainly. "We counted withdrawn records as current" is better than "a data issue was identified". Put the note at the top, keep it after the fix, and do not remove it later. The post's date line should reflect when you reviewed it, and never imply it was published earlier than it was.
A worked example of a correction
Imagine a post gave a wrong count for KEV entries added in 2025 and a reader points it out. The author reruns the script on the frozen 2026.10.16 file and finds that a filter on dateAdded accidentally included part of the next year. The right response has four parts.
- Confirm the right number on the frozen file. In the 2026.10.16 release, 245 entries had a dateAdded in 2025.
- Fix the figure in the text, the table and any chart.
- Add a note at the top: "Corrected 22 October 2026: the count of 2025 additions is 245. The earlier figure came from a date filter that included entries from 2026."
- Add a row to the log with the old value, new value, cause and snapshot hash.
The wrong figure in this scenario is deliberately left unstated, since it is a hypothetical. The real 2025 count in the 2026.10.16 file was 245, which is the figure to check against your own copy.
A log table you can copy
| Date (UTC) | Location | Old | New | Cause | Snapshot |
|---|---|---|---|---|---|
| 2026-10-22 | Table 1, row 2025 | earlier count | 245 | Date filter overlap | 2026.10.16 |
| 2026-10-23 | Caption, Figure 2 | earlier release | Release 2026.10.16 | Stale citation | 2026.10.16 |
Keep the log in the same repository as the script, so the code and the history of its mistakes travel together.
Tell the people who cited you
A correction helps only if people see it. If someone cited the wrong number, reply to them or to the thread where they shared it. If you track where your post is linked, check those places after a correction. Be matter of fact: state the old value, the new value and the reason in two sentences.
Corrections that touch conclusions
Sometimes a fixed number changes a conclusion. When it does, rewrite the conclusion, and say in the note that it changed. Do not leave a paragraph that argues from a number you have since replaced. If the change is large, consider a short summary at the top of the post: what you claimed before, what you claim now, and why.
Prevention beats correction
Most errors in data posts come from the same few places: stale snapshots, filters applied twice, joins that drop rows and denominators that shifted. Rebuild one table from scratch on a clean machine before you publish, and keep the frozen inputs. See freeze a dataset for how, and show the denominator for the checks that catch the most common slip.
Try it yourself
Click through it at your own pace, or open it full screen. Compare two scans of the same target and notice that change over time is normal, then decide which changes are updates and which would be corrections.
Quick check
Should I delete the old number from the text?
Replace it, but keep it in the corrections note so readers can see the change.
Do updates to changing data need a log entry?
Yes, as updates. Note the new snapshot version or date so readers know which numbers belong to which release.
What if a reader disagrees but I think I am right?
Share your script and snapshot hash and invite them to run it. If the numbers match, the difference is in definitions, and you can clarify.
Last reviewed: 19 October 2026.
