In the previous post I ordered artifacts by evidential strength. This time: where I start looking, and why the starting point decides what I find.

People expect me to have a fixed list of search terms. I don’t. What I have is a fixed way of choosing them, and it begins outside the Unified Log.

Start with a time you did not get from the log

Before I open a log I want a moment that came from somewhere else. The time of a collision. The time of death. A witness statement. That external moment is my anchor, and it defines the window I search in. Without it, the AUL is too large to read and I will find whatever I was already inclined to find.

The investigative question then decides the window, not the other way around.

The window is an argument, not a habit

Take a collision. The question is whether the driver was distracted. My first pass is one minute before and one minute after. That number is not a convention. At a hundred kilometres per hour, a minute is a considerable distance. The window has to match what happened in the physical world.

Then I use the two halves differently.

Before the collision I am looking for interaction. Screen touches, an unlock, button presses, an app moving from background to foreground, a swipe. If I see heavy interaction, I widen the window backwards to build a picture of what the driver was doing in the minutes leading up to it.

After the collision I am looking for behaviour. Was a call placed immediately? Or did something else happen first, including actions that may have altered the data on the device? The same log, a different question, and therefore different search terms.

A different case, a different shape

Now take an unnatural death. Here I am not looking for a single moment. I am looking for a pattern of interaction, and whether it deviates from what is normal for this device.

The most useful entries are often about movement after the fact. Was the device disconnected from the charger. Did the screen orientation change. And the one that carries the most weight: a Face ID that scans but does not unlock. A device does not scan a face on its own. Someone picked it up, and it was not the person enrolled in the keybag.

That is evidence built on something that did not happen.

When absence means something, and when it does not

Absence is the sharpest tool in this method and the easiest to misuse. If an artifact is not there, that can mean nothing happened. It can equally mean the log no longer holds it.

So I hold a boundary, and it is not a soft one.

For biometric events, passcode and Face ID, I say nothing about absence beyond roughly ten hours. For interaction artifacts, apps, touches and buttons, it becomes difficult after twenty-four hours. Beyond those points, “no artifact” is not a finding. It is a gap.

Volatility is a complexity multiplier. Every hour that passes between the anchor moment and the preservation of the log costs you conclusions you can no longer defend.

The trap

The real trap is not one misread line. It is analysing without reference research.

Apple changes its operating systems, and with them what gets logged and how. Entries appear that were not there before. Some of them add depth. Others add nothing but complexity. An interpretation that held on one version can quietly stop holding on the next, and the log will not warn you.

That is why the state of the device matters so much. A physical button press has a clear beginning and little room to misread. A screen touch does not: what gets logged depends on whether the screen was awake or asleep. Face ID can trigger more than once, so a single approach to a device may produce several frames.

None of that is knowledge you can look up reliably. It is knowledge you produce.

So the rule I work by is simple. If I do not fully understand what I am seeing, I stop interpreting and run reference research. A controlled device, the action performed deliberately, the time written down by hand, the log preserved and compared. That is the only way to know what an entry means on this version, on this device.

Everything else is assumption with a timestamp attached.

What comes next

Part 2 of 6, every other week. Next up: why I never connect two entries because they sit close together in time, and what I check instead.

All examples come from my own reference devices. No casework.

© 2026 Tim Korver — Thesis Friday. Licensed under CC BY-NC-ND 4.0. Method: Anchored Log Reconstruction (ALR). Commercial or training use requires written permission. See Copyright and Use.