Anchored Log Reconstruction, principle 3

Two entries sit three hundred microseconds apart. It is tempting to read them as one event. That temptation is the most common way to get a Unified Log wrong.

This post is about what I check before I connect two lines, and why the clock is never enough.

Why the clock cannot carry the weight

A modern Apple device runs many processes at the same time. They all write to the same log. Two entries landing microseconds apart tells you the device was busy at that moment. It does not tell you they belong to the same event.

The finer the granularity, the more convincing the illusion becomes. Microsecond precision makes unrelated things look connected, because everything is close to everything else when you zoom in far enough.

So proximity is where I start looking. It is never where I stop.

What I actually check

Three things, and it is the combination that decides.

Does the sequence follow the logic of a process that is actually being carried out. Not “did these happen in this order” but “is this the order in which this process runs on this device.”

Does the timing match how long that process takes in reality. Everyone reading this has held a phone. You know roughly how long an unlock takes. An unlock that appears before the authentication attempt does not belong to it. An unlock two seconds after does not belong either, because nobody waits two seconds for Face ID.

Is there a real link through the processes themselves, and not only through the clock.

If the chain would feel wrong in your hand, it is wrong in the log.

A chain that holds

From my reference research, the unlock sequence I described in #22:

kernel / AppleH13CameraInterface   PearlCamFrameReceived ... isFIDValidFrame=1
WidgetRenderer_Default / ChronoServices   keybag Transition: locking -> unlocked
biometrickitd / BiometricSupport   identities:withClient: ->

These belong together, and not because they are close. There is a causal relationship you can reason about. A face is captured. It is compared against the identities enrolled in the keybag. The result of that comparison determines whether the device unlocks.

Note the structure. The first two steps always happen. The camera captures, the comparison runs. The third step is the one that can fail to happen. That is what makes this chain useful: the absence of the unlock is itself informative, because you know the two steps before it took place regardless.

A chain that does not hold

Now three entries from a reference device, spanning one hundred and seventy microseconds:

09:55:30.467643  SpringBoard (CoreMotion) [com.apple.locationd.Motion:WakeGesture]
Gesture notification: 1(Detected), Mode:Normal, Start:FaceUp, End:Level, HostAwake, 0, Inferred:0

09:55:30.467732  SpringBoard [com.apple.SpringBoard:LiftToWake]
Transition received: (sleep -> wake)

09:55:30.467814  backboardd (PearlEventFilter) [com.apple.BiometricKit:PearlEventFilter]
PearlEventFilter::prewarmCamera (4)

The first two are one event. The device was lying face up, it was lifted to level, and the screen woke. Lift to wake. Motion detected, transition executed, one process carried out from start to finish.

The third entry is where analysts go wrong. It mentions BiometricKit. It sits eighty-two microseconds after the wake. Read the three together and you produce a sentence like “the user picked up the phone and Face ID activated.”

That is not what happened. prewarmCamera means the camera is being prepared. Not that Face ID ran. Not that a face was captured. Not that authentication was attempted. The system is warming up hardware in anticipation, because a device that just woke will probably need the camera in a moment.

It is a separate process. It can be related to the lift, in the sense that the lift is what prompted the system to prepare. But it does not belong to the same process, and it proves nothing about a face, a user, or an unlock.

The distance between “the camera was prepared” and “Face ID was used” is the distance between a defensible finding and a wrong one.

Where I hold the line

When the process logic, the timing and the process link all agree, I am prepared to state that entries belong to one event.

When only the clock agrees, I state that they coincided. Nothing more.

That distinction sounds small in a report. In a courtroom it is everything.

What comes next

Part 3 of 6, every other week. Next up: reasoning backwards from a provable endpoint.

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.