In late February and early March 2025, auditors from the US Postal Service's Office of Inspector General visited 21 delivery units. At 20 of them they found a total of 133,863 delayed mailpieces. The units themselves had reported only 37,392 in the reporting system, about 28% of what the auditors counted. Ten units had reported no delayed mail at all, even though the auditors found some.

In the report published in August 2025, the auditors spelled out the consequence: when local units don't report delays, senior management assumes there are none. The main cause was that the manual reporting procedures weren't being followed. The audit covered selected units that had been audited before, so its findings can't be extended to the whole postal network.

This case doesn't prove that anyone made a wrong decision. What it shows is how far the picture available to management can drift from what is actually happening in operations.

In a company, a gap like this can mean confirming a delivery date that can't be met, or reacting too late to a shortage of people or materials. Before concluding that an employee or a system failed, it's worth checking what information was available at the moment the decision was made.

When is this worth checking?

Not every stale piece of information is a problem worth spending money on. A report refreshed once a day may be perfectly good for planning next week's work. It isn't good enough for a decision that has to be made within the hour, if the situation can change materially in the meantime.

The warning sign is management learning about a problem from the customer, after a plan has already been changed, or while explaining why a deadline was missed. It's also worth a look when, after the fact, nobody can say what data a decision was based on.

Don't start by checking every report. Pick one decision where three conditions all hold: a mistake would be costly, the situation changes quickly, and earlier information would still have left time to react. If even an instant notification wouldn't have changed anything, faster data won't solve the main problem.

Today's status doesn't tell you what was known yesterday

A planner confirmed a delivery date to a customer. The next day, the system shows that part of the material needed had already been issued to another job. It's easy to conclude that the planner ignored the data.

But we don't know whether, at the moment the date was confirmed, that issue of material was visible in the report the planner was using. Four moments need pinning down:

• Event: when the material was actually issued.
• Record: when the issue of material was logged in the system.
• Availability: when the information appeared in the place the planner was supposed to be using.
• Decision: when the date was confirmed to the customer.

This is a different problem from the postal case. There, some of the delays were never properly reported. In the warehouse example, the event may have been logged right away, while the report used for the decision refreshed too late.

Whether the employee actually read the available data and interpreted it correctly is a separate question. The fact that the information was in the system doesn't settle it. Distinguishing the time an event happened from the time it was recorded is a well-known idea in modeling historical data. When you analyze a decision, you also have to check when the record was available to the right person.

How to check whether the information was available in time

One important decision is enough to start with. The process owner, with help from someone who knows the systems, should answer five questions.

1. What decision was made? Who made it and when? For example: confirming a delivery date to a customer at 10:00.

2. What information was needed? In our example: whether the required quantity of material was available at that moment. Check too whether the process defined how current that information had to be. If no such requirement existed, you can't claim after the fact that it was breached. You should, however, set one for the future.

3. What confirms the actual state? Compare the transaction history, the material issue document and other independent confirmations. If the sources contradict each other, find out why instead of arbitrarily declaring one of them true.

4. What was available at the moment of the decision? Check the time of the event, of its record, of the report refresh and of the decision. If the system doesn't keep a history of changes, today's view isn't enough to reconstruct the past.

5. What's the result? The information needed was available in time and reliable enough, or it wasn't, or there isn't enough evidence to tell. Each result leads to a different next step.

Example: confirming a date

Assume the process rules say the planner must see every earlier issue of material from stock before confirming a date.

If the refresh history confirms this sequence, you know that the report didn't contain the required information when the planner made the decision. You don't yet know why the report refreshed late, or whether the customer actually felt the consequences.

If current data had been available before 10:00 in the agreed place, the next step would be to check how it was used in the decision. If neither the refresh history nor any other reliable trace survives, there's no way to tell what the planner could see at the time. In both cases, rushing to commission a rebuild of the report could be money wasted.

Checking what's in the system isn't enough

There's a second trap. If you only analyze events recorded in the system under review, you'll never find the ones that never made it in.

So pick some cases from the log and some from other evidence that the work was done. In a warehouse process that might be material issue documents. In order handling, confirmations from customers and suppliers. Those sources can contain errors too, so compare them against each other.

Research on the quality of event logs describes problems such as missing entries and incorrect timestamps. Checking a few well-chosen cases can reveal what kind of discrepancy you're dealing with. It won't tell you how often it occurs across the company.

If the history can't be reconstructed, look at the next cases as they happen instead. For an agreed period, record the moment of the event, the moment it was logged, the moment the information became available and the moment of the decision. Keep the data you collect limited to what this analysis needs.

What should the board get?

The result doesn't have to be a lengthy audit. For a handful of cases, a short summary will do: what decision was being made, what information was needed, whether it was available in time and what to do next. It should also name the person responsible for the next step.

A conclusion might read: "Issues of material from stock are logged immediately, but the planner's report shows them with a delay. The process owner should define how quickly the information has to be available, and IT should find the cause of the lag." That's a far more useful result than a general request to build a new dashboard.

Once the cause is known, you can define what the solution has to deliver: what information has to be available, to whom, how fast, and how its correctness will be checked. Sometimes a change of procedure is enough. Other times it takes a configuration change, an integration or the ability to browse the history of changes.

At Codino we've worked on projects that made data from operational systems available in a form fit for analysis and decisions. In that kind of work, producing the report is never the whole job. You also have to establish which question it's meant to answer and whether the data will be there when it's needed.

Before the company invests in more reports, it's worth examining a few important decisions and establishing what information was actually available at the time. That separates a data problem from a problem with how data is used, and points to the right course of action.

And if the information is available in time and orders are still running late, a different question comes up: what happens between the end of one activity and the start of the next? That's what the next part of this series is about.