The Explanations That Fit the Same Facts
The eight ordinary explanations that fit most time anomalies, why writing them down before the meeting improves the case, and what to do when one of them holds.
One set of facts, and the explanations each is consistent with
Every row is consistent with an ordinary explanation and four are consistent with more than one. Writing both columns before the meeting is the whole of the method here. This is one employer's own file.
Write down the innocent explanations before the meeting, not after the person offers one. Every anomaly in this collection is consistent with something ordinary, and the ones that survive a list of alternatives are the cases actually worth pursuing.
The practical lesson in “The Explanations That Fit the Same Facts” is that visibility is not certainty. For teams researching employee monitoring at tech companies, employee monitoring at tech companies can add time and project context to the operational record, provided the purpose is explained, access is restricted and any material inference is checked through conversation and proportionate human review.
Doing this is not generosity. It is the only way to know whether there is a case, and an investigation that has already excluded the obvious explanations is substantially stronger than one that meets them for the first time in a hearing.
The FIDO Alliance passkey resources offers another lens on the issue raised in “The Explanations That Fit the Same Facts”. Compare its principles with the actual record, ownership model and review route rather than importing a generic checklist unchanged.
The eight that cover most of it
- A queue, a failed reader or a terminal in the wrong place.
- A meeting, a call or work that produces no system record.
- An instruction from a supervisor that nobody wrote down.
- A long-standing local practice the organisation tolerated.
- A system failure, a flat battery or an app that was suspended.
- A clock that is wrong in one of the systems being compared.
- A shared credential, so the record is about a role.
- A genuine mistake: wrong button, wrong terminal, forgotten punch.
Eight lines. Checking them against a specific anomaly takes under an hour and resolves the large majority.
The supervisor's instruction
This one deserves separate mention because it is both common and invisible. People are told to clock out and finish up, to put the time on a different code, to not record the extra twenty minutes.
The instruction is usually well-meant and never written down. When the record is later questioned, the employee's account is that they were told — and the supervisor may not remember, or may not want to.
Asking the question directly, early, of the supervisor as well as the employee, is the only thing that gets to it.
Tolerated practice
The second big one. A practice that has run for years, that managers have seen, and that nobody ever said was wrong, is part of how the workplace operates whatever the handbook says.
Deciding to enforce the rule is legitimate. Treating the first person caught as having done something dishonest, when the practice was known, is not — and it is the pattern most likely to produce an unfair outcome.
Doing the exercise properly
For each fact, two columns: what the record shows, and what it is consistent with. Fill the second column with everything plausible rather than everything convenient.
The test is whether somebody who disagreed with you would add anything to the list. If they would, the list is not finished.
What to do when an explanation holds
Say so, in the file, and close the matter cleanly. Tell the person it is closed and why.
That last step is skipped constantly and it matters. An investigation that stops without a conclusion leaves the person believing they are under suspicion indefinitely, which is both unkind and a reliable source of resignation.
When several explanations each cover part of it
The most common real finding. Three days are explained by the queue, one by a meeting, and two remain.
Those two are the case. Pursuing all six because they were originally counted together is the error that turns a small, defensible matter into an overreaching one.
Asking the systems' owners too
Several of the eight explanations are only visible to somebody who administers a system: the reader error log, the app's suspension behaviour, a known fault, an upgrade that changed a setting that week.
A single email to each system owner — was there anything unusual with this system in this period — takes a day to come back and resolves a surprising share of anomalies outright.
Nobody sends it, because the investigation is framed as being about a person rather than about a record.
Recording the ones you rejected
Each explanation considered and rejected belongs in the file with the reason. "The reader error log shows no failures on these dates" is a line that closes an explanation properly.
A file that lists six explanations and what became of each is an investigation. One that lists only the conclusion invites every one of those six to be raised later, by somebody else, at a worse moment.
Keeping the list
The eight explanations above are general. Every organisation has two or three of its own — a particular system that fails, a site with a known problem, a shift pattern that produces apparent gaps.
Writing those down, once, saves every subsequent investigation from rediscovering them, and it is the kind of institutional knowledge that otherwise leaves with whoever happened to know it.