For twenty-one Fridays I have documented Apple Unified Log artifacts on this site. This week I write down something I have never made explicit: how I actually read a log. An artifact table tells you what exists in the AUL. It does not tell you which entries you can build a reconstruction on. So let me start with the line that changed my way of reading.

The face was there.

This line comes from one of my own reference devices, an iPhone 12 mini on iOS 18.2.1:

2025-03-09 14:50:43.337360  kernel / AppleH13CameraInterface
PearlCamFrameReceived - isFaceDetected=1, hasAttention=1, hasGlasses=1,
hasOcclusion=0, hasEyeOcclusion=0, isFIDValidFrame=1

This line records that a face, or something closely resembling one, was visible to the TrueDepth camera at that exact microsecond. The eyes were directed at the phone. In my reference research, hasAttention=1 consistently matched the moment the user looked at the device.

The user did not choose to create this entry. The sensor fired because a face appeared in front of it. The person holding the phone was almost certainly unaware this was being logged. That is why this entry sits at the top of my scale.

The scale

My ordering principle is simple.

The less aware the user was that an action would be logged, the harder that entry is to dispute.

At the top of the scale sit sensor entries the user never consciously triggered. A biometric frame. An orientation change while the screen was off. At the bottom sit deliberate, visible actions. A passcode entry. A tap on an app icon. Below those sit automatic system events with no user interaction at all. A Bluetooth connection can be a small plus in a reconstruction, but it proves nothing about what a person did.

Compare the face frame with a passcode unlock from the same device:

2025-03-09 14:50:16.052949  SpringBoard.auth
Processed authentication request (success=YES)

This entry is real and useful, but structurally weaker. A code is knowledge, and knowledge travels. Anyone who knows six digits can produce this line. A valid Face ID frame cannot be produced by knowing something.

One warning. A readable event message is not automatically a reliable one. Readable strings feel trustworthy, and that feeling is a trap. A pattern only becomes an anchor after it has been verified in reference research, on a controlled device, with logged actions and noted timestamps. Readable plus verified is an anchor. Readable alone is a temptation.

The anchor is a starting point

I never read a Unified Log to see what turns up. The AUL is too large for that. An unframed reading produces noise, and it produces the story you were already inclined to find. I go in with a defined investigative question. I find my strongest anchor. From there I build the scenario outward.

From the face frame, the log continues:

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

Three lines within thirty-two milliseconds. It is tempting to connect them because they are close together. I refuse that reasoning. Proximity in time is a hint, never a verification.

What I check instead is whether the sequence behaves like a phone in your hand. Everyone has experience with 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. Nobody waits two seconds for Face ID. A valid frame, then the keybag moving from locked to unlocked within milliseconds, then the biometric daemon resolving identities. That is the timing and order of a real unlock. If the chain would feel wrong in your hand, it is wrong in the log.

Where I stop

This is where my method differs from a tool that always gives an answer.

The sentence I am prepared to put in a report: at 14:50:43, a face, or something closely resembling one, was directed at this device. It matched an identity enrolled in the keybag, resulting in an unlock.

The sentence I will not write: the owner unlocked the phone.

The log proves presence, attention, and a match with an enrolled identity. It does not prove whose face that was. Enrollment is not ownership. A device can hold more than one enrolled face, and the log does not name them. The moment I write “the owner,” I have stopped reading the log and started assuming.

What comes next

This post is the first of six. In the coming Fridays I will take the method apart step by step. The fixed core of search terms and the trap in each of them. Verifying causal chains instead of trusting the clock. Reasoning backwards from a provable endpoint. The stop rule that scales a conclusion down. And finally the same method applied on iOS 12, iOS 18, iOS 26 and macOS. The strings change with every version. The way of reading does not.

All data in this post comes from my own reference devices, documented in my graduation research. No casework.