I've been building a system called Nexus for the past few months. It's a personal data platform: 54 data sources, 250+ tables, 358,000 knowledge graph facts, all running in Postgres 16 on a home server. It ingests everything from iMessage to Gmail to Apple Photos to Spotify to HealthKit. The goal is biographical intelligence: a queryable model of my own life.
A few weeks ago, while wiring up some of the Apple-specific data sources, I cracked open the local databases that Apple maintains on macOS. What I found was... familiar.
What Apple stores locally
Apple maintains several overlapping SQLite databases on your Mac. The digital forensics community has mapped these fairly well, even though Apple barely documents them publicly. Sarah Edwards at mac4n6 was among the first to document knowledgeC.db in depth, and her later research on PersonalizationPortrait specifically called out that the database was "loaded with data." But that work focused on forensic investigation (what can law enforcement extract from a seized device), not architectural analysis. I'm coming at it from the other direction: I built a system that does the same thing, and I want to understand what Apple's design choices can teach me.
The databases I ended up ingesting into Nexus:
knowledgeC.db (CoreDuet framework) — this is the big one. Forensic researchers call it "pattern of life" data. App usage, device usage, location context, behavioral timelines, media activity, browsing behavior, communication metadata, charging patterns, movement patterns. On newer macOS/iOS versions, much of this moved into the Biome framework, but the architectural concept stayed the same.
After harvesting, my own aurora_raw_apple_knowledge table has 13,677 records and aurora_raw_biome has 249,776. Here's what the stream distribution looks like in knowledgeC:
| Stream | Records |
|---|---|
/app/usage |
8,739 |
/app/intents |
3,078 |
/app/webUsage |
758 |
/display/isBacklit |
338 |
/notification/usage |
304 |
/bluetooth/isConnected |
300 |
And in Biome:
| Stream | Records |
|---|---|
GenerativeModels.GenerativeFunctions.Instrumentation |
241,138 |
Autonaming.Messages.MessageIds |
2,221 |
Messages.Read |
2,098 |
App.Intent |
1,139 |
Siri.Remembers.MessageHistory |
1,051 |
That first Biome stream alone: 241,138 records of Apple Intelligence function invocations. Every time the generative model runs on your device, that's a record.
PersonalizationPortrait — this is where it gets architecturally interesting. My aurora_raw_apple_personalization table has 38,775 records. The schema:
entity_name text
entity_type text
interest_score real
decay_score real
topic_category text
is_significant_contact boolean
Apple is running interest scoring with temporal decay on entities it tracks about you. The entity types include significant_contact (3,970 records), topic (2,805 records), loc (2,000 location entities), and a set of opaque ne_* (named entity) categories that appear to map to different entity classes.
The topic_category values are Wikidata QIDs. As far as I can tell from the published DFIR literature, nobody has called this out before: Apple is using the Wikidata knowledge graph as its topic ontology. Q223563 (Google Calendar) is the most frequent topic in my data with 587 records and an average interest score of 0.999. Apple knows I'm very interested in calendaring.
The location entities have a mean decay_score of -1.0, which suggests Apple uses negative decay to actively deprecate location relevance over time. Contacts don't decay. Locations do.
Apple Intelligence triples — this one stopped me cold. aurora_raw_apple_intelligence has 40,339 records with this schema:
subject text
predicate text
object text
confidence real
That's a knowledge graph. Subject-predicate-object triples with confidence scores. Apple is running entity resolution on your device:
| Predicate | Count |
|---|---|
nm_hasVisualIdentifier/PS1 |
2,471 |
nm_hasVisualIdentifier/nm_associationReason |
2,471 |
nm_personType/ |
2,471 |
nm_entityAliasRelationship/nm_confirmationConfidence |
1,578 |
nm_entityAliasRelationship/PS89 |
1,578 |
nm_hasVisualIdentifier links face embeddings to person entities. nm_entityAliasRelationship with nm_confirmationConfidence is alias resolution: "this name and this face are the same person, with this confidence score." nm_personType classifies entities into person categories.
This is the same architectural pattern I built in Nexus, where aurora_social_identities (7,203 person entities) links to knowledge_facts (358,053 facts) through entity resolution with confidence scoring and alias deduplication. Apple and I arrived at the same design, independently, for the same reasons.
The architectural comparison
Here's what surprised me about the overlap:
| Capability | Apple (on-device) | Nexus (my system) |
|---|---|---|
| Entity resolution | Face-to-identity linking with confidence | Multi-signal identity merge with confidence |
| Relationship modeling |
is_significant_contact boolean + interaction frequency |
Weighted edges with temporal validity windows |
| Topic classification | Wikidata QIDs with interest + decay scores | Knowledge graph facts with typed predicates |
| Behavioral timeline | knowledgeC + Biome streams | Unified timeline across 54 sources |
| Location context | 2,000 location entities with decay scoring | Google Timeline + device GPS + travel records |
Where Apple is richer: the ML layer. The visual identifier linking, the interest/decay scoring algorithms, the generative model instrumentation. That's 241K records of model telemetry I can see but can't interpret because Apple's weighting logic is opaque.
Where Nexus is richer: temporal depth (24 years vs. however long your Mac has been running), cross-platform fusion (Apple only sees Apple ecosystem data), and full auditability. I can SELECT * FROM knowledge_facts WHERE subject_id = $person and get every fact I've ever recorded. Apple's system is a black box even to the device owner.
The part nobody talks about
Apple's privacy story is "we keep this on-device." That's meaningful. It's genuinely better than sending everything to a cloud. I respect the architectural decision.
But "on-device" doesn't mean "small." My Mac is quietly maintaining:
- 249,776 behavioral telemetry records (Biome)
- 40,339 knowledge graph triples with confidence-scored entity resolution (Apple Intelligence)
- 38,775 personalization records with interest scoring and temporal decay (Portrait)
- 13,677 app/web/media usage records (knowledgeC)
- 10,000 Siri interaction records
- 1,153 Siri entity records
Total across the Apple-specific tables I've ingested: 353,744 records. That's not a cache. That's an intelligence platform.
The forensic researchers have known this for years. DFIR investigators consider these databases some of the most valuable artifacts on an Apple device because they effectively reconstruct a complete behavioral profile: who you talk to, how often, which apps you use, what topics interest you, where you go, when you're active, and which people matter to you.
Apple's system is sophisticated, privacy-respecting by design, and significantly more extensive than most users or even most security professionals realize. The is_significant_contact flag alone implies Apple maintains a running model of your relationship hierarchy. The Wikidata topic ontology means it's classifying your interests against a structured knowledge base. The entity alias resolution with confidence scoring means it's doing the same identity deduplication work that takes enterprise MDM platforms months to implement.
All locally. All silently. All without documentation.
Why this matters if you build data systems
If you're building any kind of personal data platform, user modeling system, or behavioral analytics pipeline, Apple already solved a lot of the hard design problems on every Mac and iPhone. The patterns are worth studying:
Interest scoring with decay. Not just "what do you care about" but "what did you used to care about." The negative decay on locations vs. zero decay on contacts is a real design insight: people are permanent, places are transient.
Wikidata as ontology. Instead of inventing a topic taxonomy, Apple adopted an existing structured knowledge base. That's a build-vs-buy decision most teams get wrong.
Confidence-scored entity resolution. Not "this face is this person" but "this face is this person with 0.87 confidence." The alias relationship table is doing probabilistic identity merge, which is the correct architecture for a system that can't ask the user to confirm every match.
Separation of behavioral streams. Biome doesn't dump everything in one table. Each stream (
App.Intent,Messages.Read,ScreenTime.AppUsage) is its own event type with its own schema. That's the same architectural decision I made with Nexus's per-source bronze tables, and for the same reason: different data shapes shouldn't be forced into a single schema.
I spent six weeks a biographical intelligence system. Apple had already built the foundation of one on my laptop. The difference is: I can query mine whenever I want.
Top comments (0)