Quick Answer: Every Mac running macOS 13 or later ships two daemons, knowledgeconstructiond and intelligenceplatformd, that build a Mac personal knowledge graph. It maps you, your contacts, how they relate to each other, and your daily activity. The graph is stored as SQLite databases in ~/Library/IntelligencePlatform, and Apple has documented very little of it.
Here's a question most Mac owners never ask: what does the computer think it knows about your family? A research team recently spent weeks answering it on macOS 26.6.2, and the answer is more structured than most people would guess. Your Mac isn't just storing your contacts. It's building a relationship map of your life, on the device, and keeping it in a form that AI features can query.
The analysis published on 8rank.ai is the most detailed public look at this system so far. Apple has published little about it. The closest official material is the man page for knowledgeconstructiond, which describes the daemon in a single sentence.
What the Mac Personal Knowledge Graph Actually Is
The graph is a model of you and the people around you. It records who you are, who you know, how those people relate to you and to each other, how you communicate with them, where you go, and what you do, and when. Every bit of it is built on the device.
Apple's own researchers published a 2023 paper on the techniques behind graph construction. What that paper doesn't cover is how the system ships in macOS: which versions run it, what exactly it collects, and how it infers relationships. That gap is why the research matters. The graph is not a hypothetical future feature. It has been running on Macs since macOS 13 in 2022.
Where the Data Lives and How It's Structured
The two daemons write to ~/Library/IntelligencePlatform, a directory holding 51 SQLite databases. The files are plaintext, but the folder sits behind TCC (Transparency, Consent, and Control) protection, so reading it requires Full Disk Access.
The most important file is graph.db, a triple store. Every row is a subject, a predicate, and an object. The subject is an entity such as a person, app, or event. The object is either a plain value, like a name or a date, or another entity, which is how the graph forms edges. The vocabulary includes 181 entity classes and 278 predicates.
Here's where it gets interesting. An edge isn't stored as a single row. In the example the researchers document, "employer" points not to an organization but to a relationship type entity. So one logical edge becomes two rows that share a relationshipId: one naming the kind of relationship and one pointing at the other entity. That indirection is what lets the system attach a confidence score to an edge and retract it later. Every row also carries confidence, sources, and timestamp fields.
What Goes In: The Input Feeds
The daemons don't need you to tell them anything. They read from whatever the OS permits. The published inputs include:
- Contacts, Photos (face data), and Calendar (event titles and attendees)
- Family Sharing, including the age of every family member
- The Medical ID emergency contact in Health
- People and events that Siri Suggestions finds in Mail and Messages
- People donated by apps through App Intents
- Installed apps
Alongside the graph, separate tables track who appears with whom in your photos, a communication log showing who, when, which app, and which direction (without message content), plus location, movement, and a long tail of device signals. Those signals include screen lock state, Wi-Fi, Bluetooth, charging, and ambient light.
One stream stands out. ContextualUnderstanding.PhysicalSocial is described as listing people by name, phone, and email, each with start and end times. The researchers say it reads like a log of who was physically near you, though they never saw it populated.
What Gets Inferred (and What's Still a Guess)
Collecting data is one thing. Inferring relationships from it is where the risk grows. The researchers went through all 181 entity classes and noted whether they could find a working mechanism for each. A sample from the table:
| Class ID | Label | Group | Mechanism status |
|---|---|---|---|
| SB104 | person | core | Implemented |
| SB152 | place | core | Implemented |
| nm_document | document | core | Could not find mechanism |
| SB170 | time | core | Could not find mechanism |
| SB517 | eating activity | activity | Might be implemented (unverified) |
| SB784 | driving activity | activity | Could not find mechanism |
The pattern is useful. Core classes like person and place are backed by working code. Many activity and sports classes are either unverified or have no mechanism the team could find. That doesn't mean the unverified classes are harmless. It means the labels exist in the schema before anyone can confirm what fills them.
The researchers also flag a "kinship" inference, a relationship type the graph appears to derive between people. They found nothing about it in Apple's documentation, and it's the part of the system most worth scrutinizing.
Why "Just Turn Off Siri Suggestions" Isn't Enough
Here's the counter-intuitive finding that most privacy guides miss. Siri Suggestions is only one of several feeds. Contacts, Calendar, Photos, and Family Sharing reach the graph through their own paths, according to the inputs the researchers list. Disabling Siri Suggestions removes one source of events and people, but it doesn't clear what the other feeds have already written.
The practical implication is that privacy controls work at the feed level, while the graph works at the relationship level. Turning off a feed stops new data from arriving. It doesn't tell you what's already stored.
The Threat Model: A Single Point of Failure
Think about what a store like this would be worth to someone who got access to it. Even without any sensitive message content, a consolidated record of who your contacts are, who appears with whom in your photos, when you're usually at home, and who you talk to on which app is a detailed social map. A social engineering attack built on that map would be far more convincing than one built on guesswork.
That's the "privacy single point of failure" problem. Individually, each data source looks harmless. Combined into one queryable store, they become a profile. The researchers used this thought experiment to show that the risk is structural, not just a bug to patch. Any personalized system that consolidates relationship data has the same exposure, regardless of vendor.
The defense is not panic. It's knowing the store exists and treating its contents as sensitive. Keep your Mac's login password strong, keep macOS updated, and be cautious about granting Full Disk Access to apps you don't fully trust, since that permission is the door to these folders.
How to Check Your Own Graph Safely
If you want to see what's in your own graph, you can start with a read-only review. Here's a safe sequence:
- Open System Settings > Privacy & Security > Full Disk Access and review which apps already have access. Remove any you don't recognize or no longer use.
- Grant Full Disk Access to your terminal only if you need it, and revoke it afterward.
- Make a backup copy of the ~/Library/IntelligencePlatform folder before opening anything, so you can compare changes later.
- Use the open-source iKnow dashboard linked in the original research to browse graph.db without editing it. Avoid tools that write to the database.
Be honest about the limits here. The databases are plaintext, so anyone with read access to your account can see them. Protecting the folder depends on your account security and on which apps you allow to read it.
Frequently Asked Questions
what is a mac personal knowledge graph?
A Mac personal knowledge graph is an on-device data store built by the knowledgeconstructiond and intelligenceplatformd daemons. It records people, places, events, and relationships drawn from Contacts, Calendar, Photos, and other system data. It sits in ~/Library/IntelligencePlatform as SQLite databases, with graph.db as the main triple store.
how do i see what my mac knows about my family?
Grant Full Disk Access to your terminal, then inspect the SQLite files in ~/Library/IntelligencePlatform with a read-only tool. Back up the folder first. Start with graph.db and look for person entities and the relationship-type rows that link them.
why does my mac know who my family members are?
Family Sharing and Contacts give the OS direct information about family members, including ages. The graph then links those people using predicates and inferred relationships such as kinship. This happens automatically on the device, and Apple has not documented the kinship inference.
can turning off siri suggestions remove my data from the graph?
Not fully. Siri Suggestions is one feed among several, and Contacts, Calendar, and Photos supply data through their own paths. Disabling Siri stops that feed, but existing records remain until you remove them through the appropriate system settings or by deleting the data.
Stop Guessing What Your Mac Knows
The core takeaway is simple: your Mac is building a relationship map of your life, and the controls you think cover it may only cover part of it. Start with the Full Disk Access list today, and remove any app you don't recognize. Then check whether your own family appears in graph.db, and note what the graph got right and what it got wrong.