What the Checker Caught First in a 355-Session Backfill

I pulled 355 old work sessions apart and got 1,748 separately tracked pieces of work out of one pass. The first thing the process that checked them caught was a mislabeled record, a piece of work credited to the wrong source.

That result changed how we think about a stretch of work sitting in a chat log or a meeting note. It does not simply evaporate as a blob of context once the conversation ends. It is a real piece of work, with a beginning, a sequence of decisions, a result, and a claim about that result that can be checked later, if you build it that way.

The weekly report nobody could trace

The reason to do this at all was a weekly habit that had become unreliable: trying to remember what had happened over the past week well enough to report on it. That is a different problem than it sounds like. A summary written from memory, even an honest one, can only tell a plausible story about what happened. It cannot answer more specific questions. Which part of a long session actually shipped? Which conclusion got checked against something real? Where did a particular claim in this week’s report come from? Memory smooths things into a narrative, and a narrative isn’t evidence.

So we started treating each session as something to break down into its individual pieces of work. Each piece carries its own status, whether it was verified, and what actually happened, tied back to the real record instead of to how the week felt in hindsight. Everything else, a weekly report, a daily note, this very sentence, is meant to be a view over that underlying record and never a replacement for it. If a number in a report looks surprising or gets disputed, we can trace it back down to the specific pieces of work that produced it.

Backfilling everything at once

Doing this at scale came with its own trap. Our first instinct was to backfill all of history in one unbounded pass. That risked running away across years of records with no natural stopping point. The fix was ordinary and easy to overlook: explicit, bounded batches, with a separate routine to pick up anything still left over afterward, rather than one process trying to swallow everything at once.

What the checking step found

The most useful part of the whole effort was what the verification step caught while we were building it, more than the final count. It found the attribution bug, work credited to the wrong source, and a couple of other mistakes in the system doing the recording. We fixed each one at its actual source and did not patch it over in whatever report happened to be showing it. A manually patched report is only a document with better formatting.

If your own team reports on its work from memory

Ask whether last week’s summary would hold up when someone asks for the exact origin of each claim. If the answer is that the team remembers it that way, that is not the same thing as a record. Ask your team to show exactly where last week’s summary came from.

dxdev LESSON · paste into your AI coding agent
LESSON: Only a record built at the time work happens can answer what actually shipped
WHAT TO SHARE: Describe how your team currently reports on what got done, whether it's a weekly summary, a status meeting, or a report pulled together after the fact.
ASK YOUR AGENT TO:
1. Identify whether the current reporting method is built from a record made at the time work happened, or reconstructed afterward from memory or a general summary.
2. List a few recent claims from a status report or summary that couldn't easily be traced back to a specific, verifiable piece of work.
3. Propose the smallest change that would make future reporting a view over a real record, rather than a retelling from memory.
RETURN: A short table of current reporting method, whether it's traceable, and the smallest fix.
BOUNDARY: Analysis only. No agent should run an unbounded backfill or bulk process across your history without an explicit limit set by a person first.