Pattern, Incident and the Difference
Why a single anomaly means almost nothing, the two comparisons that turn one into a finding, and the risk of investigating the person who was noticed.
One anomaly, checked against the surrounding months
The anomaly that prompted the review.
Checked individually.
The reader error log confirms it.
Nobody had looked at anybody else.
Nothing to check.
The anomaly is one of twelve on that shift and the only one anybody examined. Checking the surrounding period and the comparison group took an afternoon and changed what the matter was. This is one employer's own file.
A single anomaly is noise. Everything in this collection produces occasional odd records — a failed reader, a forgotten punch, a meeting, a flat battery — and any sufficiently large set of time data contains them for everybody.
The practical lesson in “Pattern, Incident and the Difference” is that visibility is not certainty. For teams researching mouse jiggler detection, open the relevant feature summary 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.
What distinguishes a finding from an artefact is not the anomaly itself. It is whether it recurs for this person and whether it occurs for others, and both comparisons take an afternoon.
The Mozilla privacy principles offers another lens on the issue raised in “Pattern, Incident and the Difference”. Compare its principles with the actual record, ownership model and review route rather than importing a generic checklist unchanged.
The two comparisons
Over time, for the person: does this happen on other days, and if so how often and in what circumstances?
Across people, for the same shift and the same conditions: does it happen to others, and at what rate?
Either comparison alone can mislead. Together they establish whether the anomaly belongs to the person or to the situation.
The comparison group is the one that gets skipped
Investigations start because somebody was noticed, and the natural next step is to look harder at that person. Looking at everybody else is counterintuitive and it is the step that most often changes the answer.
Where eleven comparable gaps exist across six people and only one was examined, the organisation does not have a case about an individual; it has a system problem and a selection effect.
Selection, and how cases begin
How did this come to attention? A manager's suspicion, a complaint, a routine report, an automated flag?
That matters because suspicion-driven investigations look only where suspicion pointed. Recording the trigger in the file, at the start, makes the selection visible to whoever reads it later — including to the person deciding whether the process was fair.
What a pattern looks like
Repetition, consistency and the absence of an environmental explanation. The same gap, on days that have nothing in common except the person, when colleagues on the same shift show nothing comparable.
That is a finding. It is also, usefully, much easier to put to somebody, because it is a description of their own record rather than an interpretation of one day.
What an incident looks like
One occurrence, often with an obvious explanation available, sometimes without.
A single unexplained incident can still matter if the thing itself is serious enough, but it is a different matter from a pattern and should be handled as one — with a conversation rather than an investigation, in most cases.
The retention limit on both comparisons
Both comparisons depend on having the surrounding data, and in most organisations the window is thirty days.
That is worth knowing at the start, because it sets what is possible. An investigation that begins six weeks after the event can examine the event and nothing around it, which means the most informative step is already unavailable.
Doing the comparison fairly
Use the same criteria for everybody, applied mechanically, before looking at the results. Define what counts as a comparable gap first.
Defining it afterwards — once you have seen which days are inconvenient for whom — produces a comparison that proves whatever was expected, and it is visible to anybody who asks how the criteria were chosen.
Defining the criteria first
The criteria for what counts have to be written before the data is looked at, or they will be written to fit what was found.
- What exactly counts as a comparable anomaly, in minutes or in kind.
- Over what period the comparison runs.
- Which people form the comparison group, and why those.
- What rate is normal for this shift, established from the data.
- What threshold of difference would be treated as a finding.
- Who agrees the criteria before the query is run.
Six lines, agreed in ten minutes. They are the difference between a comparison and a confirmation.
The pattern that belongs to the shift
Where the comparison shows the behaviour across a group, the finding is about the arrangement and belongs to whoever owns it.
That is a different document going to a different person, and it is the one most likely to change anything. A finding about a shift sent only to an individual's file changes nothing at all.
Recording how the comparison was done
The trigger, the criteria, the period examined, the comparison group, and the results for everybody in it, not just the person concerned.
That record is what makes the finding a finding. Without the comparison, an employer has a day that looks odd, which is a description of ordinary data rather than evidence about anybody.