Some records were never built to hold the answer.

There are two questions to ask about any process. What does it capture? And what can it capture? The second one rarely gets asked.

Years ago, at a medical equipment delivery company, our delivery tickets were paper. Each one carried a date of service and no time at all. The only timestamp in the whole process belonged to the fax machine: when the paper reached the office, not when anything happened in the field.

And tickets got lost. It wasn't unusual to clean out a van and find a few. So the record wasn't just imprecise. It was incomplete, and nothing told us it was incomplete.

No amount of discipline fixes that. A form with one date field can't tell you when something happened. A status overwritten in place can't tell you what it was before. More care doesn't recover a value the record was never built to hold.

When we moved to handheld scanners, the record captured the time of the scan, the time of delivery, the time of signature, and who signed. But the field that mattered most was one nobody would think to ask for: how each value got there. Scanned, or typed in by hand.

That field turned arguments into a rule. When the same asset tag showed up in two places, the process I put in place checked which entry was scanned and which was keyed. You couldn't fudge a scanned barcode, so it was treated as verified and locked in. The keyed entry went back to the driver to resolve.

The record didn't just hold more. It held whether each value was verified or asserted.

That's the gap I see in how AI work gets logged today. We record what an agent did. We rarely record whether it read a value from a source or produced it. Stored side by side, the two look the same.

Before you automate on top of a system, find out what it can't tell you. The question isn't what the data says. It's what the process was never built to record.

What is one thing your system can't tell you, no matter how carefully people use it?