I’ve probably mentioned the mutability of the “permanent audit log” once or twice before. There is even a record irregularities report where you can watch entries change organizations, time, and users.[1] Now, Flock is stepping up its mutations game. The unique event identifiers that are supposed to be the rug tying the room together now fluctuate in the audit logs.
The Search IDs
Around the time Flock made heavy-handed edits to existing government records, it added, or started to expose, an “id” field along with search results. From the outset, haveibeenflocked.com has ignored that field because Flock can’t be trusted to keep anything stable. As we’ll see here.
I don’t use Flock’s IDs and instead rely on other methods to handle duplicate entries, so I mostly ignore them. Then I received an email from someone who paid more attention. He had been manually downloading audit logs from transparency portals and comparing the files, noticing that entries change more than they should.
To be honest, I didn’t really believe him at first. It sounded implausible even for Flock to do something so technically terrible. Egg on my face.
Transparency portal search logs now typically look something like this:
e71b39a6-3cc8-4161-b4ec-e62c6e1cd135,***,2026-03-04T20:37:04.924Z,6050,investBecause cops can’t be trusted with cop data, Flock’s network logs look about the same. In addition to the ID, they have a name of an agency. The idea is that an auditing PD will pick up the phone, relay the ID in their network log to the named agency, and verify that “invest” was a legitimate search.
With about 6,000 agencies doing 10,000+ searches per day, that’s a lot of phone calls.
This idea is obviously completely divorced from reality to begin with, but it’s being used — to great effect — to convince uncritical elected officials of the existence of accountability.
Now, I’m not sure what cops are supposed to do.
The Time and ID Changes
The transparency portal logs are produced on a 30 day rolling basis. So, if you downloaded the same log a day apart, you’d expect to see 29 days worth of identical records with one day trimmed and one day added. However …
On March 23, 2026, West Des Moines’ log showed these two searches:
e71b39a6-3cc8-4161-b4ec-e62c6e1cd135,***,2026-03-04T20:37:04.924Z,6050,invest
bc377b4b-2261-4fe1-a96c-ebb59217c061,***,2026-03-04T21:00:31.190Z,6051,investTwo searches on March 4, both labeled “invest,” one at 8:37pm (UTC), and one at 9pm (UTC).
On March 24, 2026, they are both gone. In their place are two new searches:
9c685baa-cf80-478c-acf1-2df174a1d686,***,2026-03-04T20:26:48.972Z,6050,invest
ec162dff-51b1-4de6-be2d-16a2b2cd8411,***,2026-03-04T21:39:47.263Z,6051,investThe also both happened on March 4, and are both labeled “invest,” but now one happened at 8:26pm (UTC) and the other at 9:39pm (UTC). That’s a significant difference.
If the same change happened in network logs, and if anyone had made that phone call about search ID
e71b39a6-3cc8-4161-b4ec-e62c6e1cd135, they would have to make another phone call about the search
that replaced it: 9c685baa-cf80-478c-acf1-2df174a1d686.
The problem appears broad. In the March 23 – 24 comparison alone (about 200 lines total) there were multiple changes:
-b76afd28-1246-4b3d-91d7-5f14642dd191,***,2026-02-25T20:56:59.751Z,2,Windsor Heights Fresh Stolen
+72db34f8-dd39-4d5d-814c-c968cb5e58b2,***,2026-02-25T20:52:17.101Z,2,Windsor Heights Fresh Stolen
-e71b39a6-3cc8-4161-b4ec-e62c6e1cd135,***,2026-03-04T20:37:04.924Z,6050,invest
-bc377b4b-2261-4fe1-a96c-ebb59217c061,***,2026-03-04T21:00:31.190Z,6051,invest
+9c685baa-cf80-478c-acf1-2df174a1d686,***,2026-03-04T20:26:48.972Z,6050,invest
+ec162dff-51b1-4de6-be2d-16a2b2cd8411,***,2026-03-04T21:39:47.263Z,6051,invest
-b8afc2dc-434c-41e3-8614-92134e713de8,***,2026-03-05T07:58:19.466Z,1169,
+3c652fad-db99-472f-bf7a-16430beb949d,***,2026-03-05T07:01:14.526Z,1169,
+8e10d1fb-2b66-4a0a-b4a8-2ef4b4f33899,***,2026-03-15T05:12:16.454Z,1,invest
-95134732-9341-420e-b830-901856bd4a75,***,2026-03-15T05:39:30.257Z,1167,invest
-e6941d9c-fbf2-4cbb-a54b-7c5d1fd391cb,***,2026-03-19T18:49:41.776Z,1166,
-d277a79e-0a14-4ccd-a561-8df2cfb7ca10,***,2026-03-19T19:00:37.487Z,1166,
+6f9738b1-1fbf-498a-b026-c8eda3d3aece,***,2026-03-19T18:22:11.557Z,2,
+18bf73c6-e37c-4246-ab1c-f98aae2849a6,***,2026-03-19T19:14:27.501Z,1166,In this one file, about 7% of records changed within 24 hours.
Clanker Analysis
Asking the clanker to analyze the changes over multiple files it wrote a little Python script and produced:
WDM (8 snapshots, Mar 16 - Apr 4)
Non-rolling change rate per snapshot pair: 2.6% - 7.1% (avg ~5%)
| Comparison | Removed | Added | Modified | Rate |
|---|---|---|---|---|
| 03-16 → 03-22 | 4 | 4 | 0 | 3.3% |
| 03-22 → 03-23 | 7 | 7 | 0 | 6.6% |
| 03-23 → 03-24 | 7 | 7 | 0 | 6.7% |
| 03-24 → 03-25 | 8 | 8 | 0 | 7.1% |
| 03-25 → 03-26 | 6 | 6 | 0 | 5.2% |
| 03-26 → 03-27 | 3 | 3 | 0 | 2.6% |
| 03-27 → 04-04 | 4 | 4 | 0 | 3.3% |
Key patterns:
- Removals always equal additions — records are being swapped, not just deleted or added. This is highly suspicious and suggests some kind of rotation/replacement mechanism.
- No field modifications — records are never edited in place; they vanish and a different record with the same date appears.
- 17 “flickering” records that disappear and reappear across snapshots. Example:
95134732...(date 03-15) appears in only the 03-23 and 03-25 snapshots out of 8 — pattern..Y.Y...
Johnston (3 snapshots)
Similar pattern: 3.9% - 8.2% non-rolling change rate, removals always equal additions, 2 flickering records.
The Takeaway (AI)
When it was done running its script, it gave its unsolicited, but almost accurate “key takeaway”:
The audit logs are not immutable. Every day, ~3-7% of records within the overlapping date window are swapped out (equal number removed and added, zero modifications). Some records flicker in and out across multiple snapshots, meaning the same record can be removed, reappear, and be removed again. This is consistent with records being retroactively added/removed from the audit log on an ongoing basis.
The Actual Takeaway
This is the straightforward explanation, but it’s not necessarily what’s happening. What could be happening is that Flock, like Axon, is distributing its database in an effort to sidestep accountability and ownership by conflating data control and data ownership.
I’ve called this nonsense out before as Flock saying the kitchen is not a central repository for pots and pans, because it has multiple cupboards.
But it may be what we’re seeing here. The log could be pulling in different entries from different “cupboards”, and not all “cupboards” may be available each time the log runs.
A distributed explanation is not any better than deleting and adding records in a centralized database. In fact, it would be a very fundamental, very fatal, flaw for records that are supposed to be immutable — like audit records — to have multiple copies in multiple places without a single authoritative copy.
Apparently log entries can go missing without Flock’s system throwing an error. If you can’t be sure that your log is complete, you can’t rely on it to show whatever it is you’re auditing for — it may have been deleted.
If you’re getting new results every day, your previous audits are automatically invalid and unreliable. A search that occurred at 9pm may look valid, but if a police officer goes off shift at 9:30pm and the next day the log shows the search happened at 9:45pm, that’s potentially unflagged off-duty use of a police system.
It could also cut the other way: the officer’s shift might not start until 9:30pm, and the logs will show improper use the first time around, but not the second (if anyone looks).
Network Logs
These observations are from transparency portal logs, which are largely performative to begin with. Whether the same holds in a network audit remains to be confirmed.
Examining older network logs, which did not have the IDs, entries can be seen disappearing between runs. Because I do not have enough overlapping data to fully confirm, I can only say that it seems very likely that the observed ID changes in West Des Moines and Johnston show a structural problem that has existed for a while now.
This finding alone should be cause to invalidate all prior audits, as well as all future audits until Flock addresses the problem.
States with mandatory audits, like Minnesota, and police departments with audit requirements, will have to redo their audits after it’s fixed. That’s a lot of phone calls.
That is, if they want to make good on their promises of accountability and oversight.
I won’t be waiting by the phone.
The irregular records report was a little unstable because of all the redactions. As of today, it tries to be a little smarter about identifying duplicates even with limited data. ↩︎