Who Was Using the Mac? A knowledgeC and Biome Method

TL;DR. To answer "was someone using this Mac, and when?", build unlocked sessions from /device/isLocked (0 = unlocked), check them against /display/isBacklit and /device/isPluggedIn, then fill each session with app focus (Biome App.InFocus, knowledgeC /app/usage and /app/inFocus) and web usage. Separate records synced from other devices, convert to local time with ZSECONDSFROMGMT, and state clearly what the data does not prove: it shows activity under an account, not the identity of the person at the keyboard.

This article is the interpretation step of the series. For the click path in the tool, see how to analyze knowledgeC.db and Biome in your browser; for the files themselves, the knowledgeC.db forensics guide.

The question you can answer

knowledgeC.db and Biome record "pattern of life" events: states over time (locked, display lit, on power) and app activity. Together they answer a narrower question than "who":

During which intervals was this Mac unlocked with the display on, and what was in the foreground under this account?

That is often enough to confirm or rule out a timeline, and it tells you where to look in other artifacts.

The streams

Value meanings follow APOLLO and the published research; field numbers for Biome come from mac_apt and iLEAPP (see the SEGB format reference). On recent macOS releases app focus moves to Biome and /app/inFocus can be sparse or empty: that is expected, not a sign of wiping (knowledgeC vs Biome). Not every Mac has every stream, so list the streams on your evidence before planning the analysis.

Collect knowledgeC.db-wal with the database. The most recent events, which are often the ones that matter, may exist only in the WAL (knowledgeC WAL recovery).

Step 1: Build unlocked sessions

knowledgeC events are intervals with ZSTARTDATE and ZENDDATE in Mac absolute time. An unlocked session is a /device/isLocked interval with value 0:

SELECT datetime(o.ZSTARTDATE + 978307200, 'unixepoch') AS start_utc,
       datetime(o.ZENDDATE + 978307200, 'unixepoch') AS end_utc,
       datetime(o.ZSTARTDATE + o.ZSECONDSFROMGMT + 978307200, 'unixepoch') AS start_local,
       round(o.ZENDDATE - o.ZSTARTDATE) AS seconds,
       s.ZDEVICEID AS device_id
FROM ZOBJECT o LEFT JOIN ZSOURCE s ON o.ZSOURCE = s.Z_PK
WHERE o.ZSTREAMNAME = '/device/isLocked' AND o.ZVALUEINTEGER = 0
ORDER BY o.ZSTARTDATE;

Then check each session against /display/isBacklit. An unlocked interval with the display lit is the core of a session. A lit display with the Mac locked is someone (or something) waking the screen without unlocking. /device/isPluggedIn adds context: a laptop that stays on power all day most likely stayed at its desk, though it does not prove it.

If /device/isLocked is missing, backlight intervals plus app focus give a weaker approximation. Say so in the report.

Step 2: Put app focus inside each session

Biome App.InFocus stores separate "in focus" and "out of focus" records. Pair them per app to get intervals: an in-focus record ends at the next out-of-focus record for the same bundle ID. knowledgeC /app/usage and /app/inFocus rows are already intervals.

Read focus inside the unlocked sessions, never on its own:

• focus during an unlocked, lit session is the strongest signal of use these sources give;
• focus that continues after the lock time is an app left in front, not activity;
• a long single focus interval with no other change can be an idle screen with one window open.

Step 3: Add web usage

/app/webUsage carries the bundle ID with the domain and URL in ZSTRUCTUREDMETADATA; /safari/history holds the URL, with the title in metadata. In Biome, App.WebUsage has URL, domain and bundle ID. Look at deleted records (state 3) and at tombstone/ files: a cleared history can leave Biome records marked deleted with their payload still readable.

Step 4: Separate synced devices

Devices on the same Apple Account sync some records. They must not be attributed to the Mac:

• in knowledgeC.db, group rows by ZSOURCE.ZDEVICEID (APOLLO reads it as the hardware UUID of the originating device);
• in Biome, files under .../<Stream>/remote/<device UUID>/ come from another device; local/ is the Mac itself.

Synced records are still useful: they show what the other device was doing at the same time.

Step 5: Convert to local time carefully

Stored times are UTC. ZSECONDSFROMGMT is the offset the device used at the time of each event, so start + ZSECONDSFROMGMT gives local time for that row. Biome records have no such column: apply the offset you established from knowledgeC or from system settings, and write down which one you used. A change in ZSECONDSFROMGMT between events points to a time zone change.

Worked example: FIN-MBP-03 (synthetic)

The built-in sample is synthetic and fictional, generated for this tool. MacBook FIN-MBP-03, user dana.whitlock, Monday 2026-09-14. The Mac's offset is +02:00 (ZSECONDSFROMGMT = 7200). In the scenario, Dana locks the Mac and leaves for lunch at 11:58 local time; the next routine session starts at 14:58 local.

Two more observations change the reading:

• Synced iPhone records. App.InFocus under remote/<iPhone UUID>/ and knowledgeC rows with another ZDEVICEID show Maps from 10:12 to 10:19 UTC and Messages from 10:27 to 10:29 UTC. They are not Mac activity. They are consistent with Dana using her phone elsewhere, which fits the scenario, but they do not prove where she was: someone else could hold her phone, or she could use both devices.
• A night session. A three-minute unlock at 01:12 UTC, 03:12 local, with Safari on files.example. Converting to local time is what makes this stand out.

The App.MenuItem values come from a schema-less decode: the stream has no public field map, so the table quotes the visible strings and does not assign meanings to field numbers. In the sample, every row after 10:00 UTC in the system knowledgeC.db exists only in the -wal: without it, the incident window is empty.

What this supports: the Mac was unlocked under dana.whitlock from 10:04:31 to 10:49:38 UTC with the display lit, and the sequence of apps and sites above was in the foreground. What it does not support on its own: that Dana, or anyone in particular, was at the keyboard.

What the data does not prove

• Identity. Records belong to an account and a device. A shared password, an unlocked Mac left unattended or remote control all produce the same records.
• Attention. An app in focus in front of an idle screen looks like use.
• Completeness. Retention is roughly four weeks in knowledgeC (Sarah Edwards) and about 28 days for most Biome streams (iOS research); measure the oldest record per stream on your evidence. "First use" means "first use in the retained data".
• Intent. A web visit or a menu item says what was on screen, not why.

Corroborate with other artifacts

Use these sessions as a skeleton and look for independent support in the same windows:

• Unified logs: login and screen lock related entries around the session edges, within the log retention.
• TCC.db: permission records, for example a Full Disk Access change near the System Settings interval.
• Quarantine events: downloads and their origin, for example the archive fetched in Safari.
• FSEvents: file system changes, for example on an external volume during the Finder interval.

Each of these has its own caveats; treat them as corroboration, and let physical-world evidence (badges, cameras, witnesses) address identity.

Checklist for the report

• Streams present, oldest and newest record per stream, and whether -wal files were collected.
• Unlocked sessions with UTC and local times and the offset used.
• Focus and web activity per session, with synced-device records separated.
• Deleted, tombstone and CRC-failed Biome records listed as such.
• A sentence stating that the data shows account activity, not identity.

FAQ

Can knowledgeC.db prove who was using a Mac?

No. It shows that the Mac was unlocked, that the display was lit and which apps were in focus, under a given user account. It does not identify the person at the keyboard. Attribution needs other evidence such as badge records, CCTV, witness statements or authentication logs.

Which knowledgeC streams show when a Mac was unlocked?

/device/isLocked, where ZVALUEINTEGER 0 marks an unlocked interval and 1 a locked one, together with /display/isBacklit (1 = lit). Not every Mac has every stream, so check which ones exist on your evidence first.

Why do I see iPhone apps in a Mac's knowledgeC.db or Biome folder?

Devices on the same Apple Account can sync records. In knowledgeC.db they carry a different ZSOURCE.ZDEVICEID; in Biome they sit under remote/<device UUID>. They describe the other device, not the Mac under examination.

Is an app in focus proof that someone was using it?

No. An app stays in focus in front of an idle screen until something else takes focus or the screen locks. Weigh focus intervals against the lock and backlight intervals and against activity inside the app.

Related articles

• How to analyze knowledgeC.db and Biome in your browser
• Recovering recent events from knowledgeC.db-wal
• knowledgeC vs Biome on macOS
• Biome SEGB file format