Начиная с macOS 13 (2022 год) в каждом Mac работает пара демонов, у которых одна задача: строить граф о вас. Кто вы, кого вы знаете, кем эти люди приходятся вам и друг другу, как вы с ними общаетесь, где бываете, чем заняты и когда. Ниже разбираем, как устроена эта система, и даём инструмент, чтобы заглянуть в собственный граф.
Примечание переводчика: оригинал опубликован на сайте 8rank.ai, где каждое исследование оформлено как шахматная партия. Эпиграф-позицию (вилка конём, нападающим разом на короля, ферзя, ладью и слона белых) я опустил, как и интерактивный граф с синтетическими данными. Три большие справочные таблицы (181 класс сущностей, 278 предикатов, 144 признака модели) приведены выборочно; полностью они есть в оригинале. Скриншоты панели iKnow, кроме стартового экрана, в оригинале встроены прямо в страницу, поэтому здесь они заменены описаниями авторов.
Находка
Цель: Apple Intelligence / Personal Knowledge Graph Где: macOS 13 и новее, Intel и Apple silicon Класс: приватность, персонализированный ИИ
Что, если я скажу, что в каждом Mac с 2022 года есть пара демонов, единственная цель которых — строить граф о вас и людях вокруг вас: кто вы, кого знаете, как эти люди связаны с вами и друг с другом, как вы общаетесь, куда ходите, с кем, что делаете и когда. Граф строится прямо на устройстве сопоставлением почти всего, что есть на машине: Контактов, Календаря, Фото, Сообщений, Почты, геолокации, Экранного времени и длинного хвоста поведенческих сигналов. И, что важнее, он хранится как хранилище, к которому можно делать запросы и из которого (якобы) берут данные языковые модели. Поверите?
Так и есть. Любопытно, что документации о том, как всё это работает на вашем Mac, почти нет. Ближе всего к официальному описанию — man-страница (man 8 knowledgeconstructiond), и это всё, что вы получите:
man 8 knowledgeconstructiond macOS 26.6.2, build 25G83 NAME knowledgeconstructiond – A daemon that analyzes content on the device to build a general purpose knowledge graph. DESCRIPTION knowledgeconstructiond analyzes the content on this device to help build a knowledge graph representing the device and the user. It works together with intelligenceplatformd, performing some of the heavy processing tasks, to generate the knowledge graph.
(«Демон, который анализирует содержимое устройства, чтобы построить граф знаний общего назначения… работает вместе с intelligenceplatformd, выполняя часть тяжёлой обработки».)
Предыдущие работы. Справедливости ради, исследователи Apple ещё в 2023 году опубликовали статью о методах, на которых построен этот граф. Но о том, как он встроен в macOS, почти ничего нет: в каких версиях он работает и что именно собирается и выводится. И ни слова о выводе «родства», о котором пойдёт речь ниже. Мы сами наткнулись на него в августе 2026 года, когда занимались исследованием безопасности пакета Apple Intelligence в macOS 26. Но за несколько месяцев до нас ту же базу нашёл Ник Лайдон и описал в статье «Я построил персональный граф знаний. Оказалось, Apple уже построила его на моём ноутбуке».
Мы копнули немного глубже.
Эта статья — отчёт об анализе того, что граф знаний делает на самом деле. Цель — чтобы вы, пользователь, лучше понимали этот механизм и ясно видели, что граф хранит о вас, вашей семье и друзьях. Всё описанное собрано на macOS 26 (на момент написания — 26.6.2).
Для этого мы открываем исходники локальной панели iKnow: с её помощью можно прочитать содержимое собственного графа знаний на своём Mac.
Под конец мы немного отвлечёмся и займёмся тем, что умеем лучше всего: превращением находок в оружие. Проведём мысленный эксперимент (он применим к любой подобной персонализированной системе) и покажем, что будет, если такая база попадёт не в те руки и как «единая точка отказа приватности» в связке с аблитерированной LLM (моделью со снятыми ограничениями) может угрожать вам так, как вы, возможно, не думали.
Что лежит в персональном графе знаний
Оба демона хранят результаты работы в ~/Library/IntelligencePlatform — это каталог с SQLite-базами (их пятьдесят одна). Базы лежат открытым текстом, но в зоне, которую защищает разрешение TCC «Полный доступ к диску».
Самая интересная из них, по-видимому, graph.db. Это хранилище триплетов со словарём из 181 класса сущностей и 278 предикатов: каждая строка — субъект, предикат и объект. Субъект — сущность (человек, приложение, событие); объект — либо простое значение (имя, контакт, дата), либо другая сущность, и именно так в графе появляются рёбра. Самое интересное — предикат: он говорит, какое отношение, по мнению системы, связывает эти двое.
На схеме в оригинале показано одно ребро графа (данные синтетические): человек «(Я)», владелец этого Mac, связан с организацией Halden Labs через промежуточный узел отношения. Первое ребро помечено PS500 (employer, работодатель), сам узел — CS165 (тип отношения «трудоустройство»), второе ребро — PS45 (member of, член). Ниже то же ребро показано как две строки таблицы stable_graph с общим relationshipId: одна называет тип отношения, другая указывает на организацию. Столбцы — subject, predicate, relationshipId, relationshipPredicate и object, и в каждой строке есть ещё confidence, sources, sourceDuplicates и timestamp. Значения выдуманы, а идентификаторы предикатов, путь и столбцы — настоящие.
PS500 — это идентификатор, который predicate.json даёт предикату employer, и его областью значений служит не организация, а тип отношения. Поэтому одно ребро хранится как две строки с общим relationshipId: одна называет вид отношения, другая указывает на другую сущность. Сорок шесть классов типов отношений из таблицы ниже существуют ровно для этого: благодаря им у ребра может быть собственная уверенность и его можно позже отозвать.
Большая часть работы двух демонов — заполнять эти предикаты и соседние таблицы всем, что ОС позволяет им прочитать. В граф попадают Контакты; Фото (лица); Календарь (названия и участники); Семейный доступ (включая возраст каждого члена семьи); экстренный контакт из Медкарты в Здоровье; события и контакты, которые Предложения Siri находят в Почте и Сообщениях; люди, которых передают приложения через App Intents; и установленные приложения. Рядом, в отдельных таблицах, лежат: кто с кем появляется на ваших фото; журнал коммуникаций (кто, когда, через какое приложение, в какую сторону, без содержимого), который подтягивает данные и с других ваших устройств; местоположение и перемещения; и длинный хвост сигналов устройства (экран заблокирован, Wi-Fi, Bluetooth, зарядка, освещённость и поток ContextualUnderstanding.PhysicalSocial, в формате записей которого люди перечислены по имени, телефону и почте, каждый со временем начала и конца. Похоже на журнал того, кто физически был рядом с вами, хотя заполненным мы его ни разу не видели).
Что выводится
Полный список 181 класса сущностей приведён в оригинале. Вот несколько строк из него (идентификатор, метка, группа, нашли ли мы механизм заполнения):
Класс |
Метка |
Группа |
Механизм найден? |
|---|---|---|---|
|
person |
core |
реализован |
|
place |
core |
реализован |
|
device primary user |
person |
механизм не найден |
|
sex |
attribute |
возможно реализован (не проверено) |
|
religion |
attribute |
механизм не найден |
|
political party |
attribute |
механизм не найден |
|
sleeping activity |
activity |
реализован |
|
employment relationship type |
edge |
реализован |
|
order payment relationship type |
edge |
реализован |
Все классы, которые объявляет поставляемая онтология, мы сгруппировали, а не оставили в порядке файла: сначала базовые типы, потом люди, атрибуты, места и события, затем блок активностей и в конце сорок шесть типов отношений. Это вообще не вещи: каждый из них овеществляет ребро, чтобы у ребра могли быть собственные свойства, в том числе уверенность. Идентификаторы и метки — Apple, группировка — наша. intValue идёт от 1 до 185, четырёх номеров не хватает (18, 54, 169, 181), и на диске ничто не говорит, чем они были.
Пятьдесят семь из 181 описывают активность: сон, тренировка, осознанность, отход ко сну, дорога на работу, приём пищи, и у большинства рядом есть парный класс типа. То есть почти треть словаря описывает ваши занятия; на то, кто вы и где, приходится меньше. При этом не очевидно, что используется каждый класс: часть может быть заготовками, которые объявлены и никогда не заполняются. В таблице мы помечали как реализованные классы, для которых нашли механизм, предположительно отвечающий за них. Эти пометки — результат нашего анализа, и истиной в последней инстанции их считать нельзя.
А это выдержка из полного списка предикатов (та же оговорка). Мы оставили только строки, которые заполняет модель:
Предикат |
Что записывает |
Источник данных |
Как получен |
Механизм найден? |
|---|---|---|---|---|
|
эта запись — тот же человек/объект, что и та |
любой источник |
Embedding-модель |
реализован |
|
другое имя, под которым известен тот же человек |
Контакты, Фото |
Embedding-модель |
реализован |
|
темы, которыми интересуется человек |
Personalization Portrait |
Скоринговая модель |
механизм не найден |
|
человек связан / ассоциирован с другим |
Контакты, Здоровье, Семейный доступ, Экранное время, Фото |
XGBoost + правила + копирование |
реализован |
|
слово для отношения, например «сестра», «коллега» |
Контакты, Здоровье, Семейный доступ |
XGBoost + копирование |
реализован |
|
метка утверждения, сделанного машиной |
классификатор родства |
XGBoost |
реализован |
|
кластер лиц для человека |
лица в Фото |
Кластеризация лиц |
реализован |
|
день рождения, достроенный системой, — и именно его она читает |
оценка возраста по Фото (кандидат) |
Неизвестная модель |
реализован |
|
владелец, вычисленный по поведению |
история поведения |
Неизвестная модель |
реализован |
|
назначение места, например дом, спортзал |
история местоположений |
Неизвестная модель |
реализован |
|
имя, угаданное для безымянного лица |
лица в Фото + текст Сообщений |
Локальная LLM |
реализован |
|
угаданное отношение лица к владельцу телефона |
лица в Фото + текст Сообщений |
Локальная LLM |
реализован |
В полной таблице первый столбец — идентификатор в том виде, в каком его хранит graph.db, а последний говорит, как туда попадает значение: копируется из источника, присоединяется из другой записи, выводится правилом, поставляется Apple как знание о мире или вычисляется моделью (выделено жирным). Для семи предикатов мы этого установить не смогли, и таблица так и говорит, вместо того чтобы гадать. Идентификаторы и метки — Apple, пояснения простым языком — наши.
Как это выводится
Методы самые разные. Большая часть словаря заполняется простым копированием (имя из Контактов, участник из Календаря) и правилами поверх скопированного. Интересные строки дают модели. Пара XGBoost-классификаторов решает, кто вам семья, по 144 признакам, в основном поведенческим. Две embedding-модели — один из десяти сигналов, по которым система решает, что две записи относятся к одному человеку. Двенадцать анализаторов в Фото оценивают, кто вам партнёр, родитель, ребёнок, коллега или друг, по тому, кто появляется с вами на снимках, в каких поездках и на каких праздниках. А встроенная LLM Apple читает ваши сообщения, чтобы подписать лицо именем и отношением (если включён Apple Intelligence).
Каким бы ни был метод, каждая строка попадает в граф с confidence — числом от 0 до 1.
Семейные оценки живут отдельно. Рядом с онтологией лежат две модели CoreML, EntityTagging_Family.mlmodelc и EntityTagging_FamilyAndFriends.mlmodelc: бинарные XGBoost-классификаторы, которые принимают 144 признака и возвращают класс и вероятность. Их оценки идут мимо хранилища триплетов, в отдельную таблицу (entityTagging.db: строка на человека, семнадцать столбцов отношений от семьи до матери и коллеги, пересчитывается каждый день). Именно её читает «табель родства» iKnow, о котором ниже. Только за двумя из семнадцати столбцов стоит поставляемая модель. Что заполняет остальные пятнадцать и как эти вероятности превращаются в уверенность в графе, мы проследить не смогли.
Имена признаков лежат открытым текстом в metadata.json каждой модели. Это самое ясное описание того, что представляет собой эта система, какое я где-либо встречал. Признаки делятся на три блока самой схемы: двадцать о том, кто этот человек, сорок о том, когда и как вы с ним общаетесь, восемьдесят четыре о фотографиях, на которых вы оба есть. Полный список в оригинале; первые два блока целиком:
identity (20): isVIP sharesWorkAddress hasSamePrivateEmailDomain hasBirthday hasSameEmailDomains sameLastName hasSamePublicEmailDomain photosPersonAge isFavorite hasSameEduEmailDomain hasSameWorkEmailDomain hasNickname allowListedNameMatch ageDifferenceCategory nameContainsEmoji nicknameContainsEmoji sharesHomeAddress allowListedNicknameMatch photosAgeDifferenceCategory iCloudFamilyMember communication (40): personOverallPopularity personLongTermPopularity personPopularityGivenMonday … personPopularityGivenSunday mondayPopularityGivenPerson … sundayPopularityGivenPerson personPosteriorProbabilityGivenMonday … personPosteriorProbabilityGivenSunday personPopularityGivenMorning personPopularityGivenAfternoon personPopularityGivenEvening personPopularityGivenNight personPopularityGivenHome personPopularityGivenWork homePopularityGivenPerson workPopularityGivenPerson personPosteriorProbabilityGivenHome personPosteriorProbabilityGivenWork personPopularityGivenWeekday personPopularityGivenWeekend weekdayPopularityGivenPerson weekendPopularityGivenPerson top1PersonInteractionMechanism top2PersonInteractionMechanism top3PersonInteractionMechanism
Блок photos устроен так же, только по совместным снимкам: photosPersonPopularityGivenMonday, mondayPopularityGivenPhotosPerson, photosPersonPosteriorProbabilityGivenMonday и так по всем дням, времени суток, дому и работе, плюс вероятности для каждой пары «день недели + время суток».
Это все входы, которые читает EntityTagging_Family.mlmodelc, в том порядке, в каком их объявляет metadata.json. EntityTagging_FamilyAndFriends читает те же 144 признака в том же порядке, и все они числовые. Два из двадцати «личностных», photosPersonAge и photosAgeDifferenceCategory, тоже берутся из Фото. Имена — Apple, названия групп — наши.
Группа identity — это опрятная часть истории: та же фамилия, тот же домашний адрес, флаг Семьи iCloud. И это меньшая часть. Основная масса модели — два других блока: кому вы пишете и кто появляется на ваших фото, с учётом дня недели, времени суток и того и другого сразу. photosPersonPosteriorProbabilityGivenSaturdayNight («апостериорная вероятность человека на фото при условии субботнего вечера») — это имя признака в поставляемом классификаторе, задача которого — решить, родственник ли этот человек.
Удалённое удаляется не везде.
Живой граф забывает. Удалите контакт, и ничто его заново не выведет: следующий прогон заменяет таблицу целиком.
Но рядом с живой таблицей хранилище держит вторую, expired_stable_graph. Отозванная строка переезжает туда и сохраняет свою уверенность и источники. Как долго она там остаётся, по тому, что мы видели, неясно. Похоже, примерно 48 часов (хранилище держит отметку очистки, и недавний снимок таблицы не уходил дальше этого срока). Но на своём Mac я всё ещё мог прочитать там очень старые записи.
А вывод может пережить свои основания. На моём Mac табель родства всё ещё оценивал двух людей, которых граф выбросил днём ранее; обоих система знала только по приглашению в календаре. Так что если вы не хотите, чтобы партнёр узнал об удалённых контактах и их «близости» к вам, почистите и expired_stable_graph (к сожалению, вручную). Но я уверен, что вам нечего скрывать (шучу).
Загляните в свои данные
Чувствительно ли всё это? Решать вам: «чувствительное» для всех разное (хотя, по-моему, выбрать здесь есть из чего). Но дело в том, что ничто из этого не живёт изолированно. Всё построено для того, чтобы соединять и сопоставлять; узлы существуют, чтобы их связывать.
В оригинале здесь интерактивный граф с синтетическими данными: владелец Mac, одна группа, которую хранилище держит как сущность, семь человек, оценённых как семья, девять оценённых как близкие, четыре работодателя, шесть групповых чатов и шестьдесят один человек, которых система знает, но никуда не отнесла. Каждый узел — строка в хранилище, а запись под ним — то, что хранилище держит. Размер узла — сколько строк его упоминают, форма — что это за сущность, кольцом отмечены четверо, кого хранилище считает семьёй. Пунктир — вывод, который никто не вводил.
Если щёлкнуть по узлу, под графом появится то, что хранилище о нём держит (сами строки, без пересказа). Шестьдесят одна бледная точка — та часть, которой никто не ждёт: люди, которых хранилище знает и не разместило. Они там потому, что однажды вам написали или были в чужом приглашении.
Но главное — это касается не только вас (того, кто пользуется Mac). Там же люди вокруг вас: ваша семья, друзья, «кто угодно», с кем вы общались через устройство. Никого из них не спрашивали. Хранилище связывает их с вами и, через общие события и группы, друг с другом. Отношение — это сведения уровнем выше строк, из которых оно выведено. Например, сопоставляя данные собственного хранилища, я (точнее, работающая на меня LLM) мог бы легко выяснить следующее:
Что в семье есть ребёнок и примерно какого он возраста. Типы членов семьи и семейный круг дают домохозяйство. Столбцы «ребёнок» и «сын/дочь» в табеле дают место ребёнка в нём. Рядом лежит возраст, скопированный из Семейного доступа; а даты рождения в хранилище могут нести собственную пометку системы imputed («достроено»), хотя что система под этим понимает, нам неясно.
В какой детский сад ходит ребёнок и оба номера, по которым туда можно дозвониться. Скопировано из карточек контактов. Обратите внимание, чего там нет: в календаре нет события «отвезти в школу», так что хранилище знает учреждение и его телефоны, но не час, когда ребёнка привозят. Этого всё равно достаточно, чтобы позвонить родителю с номера, которому его телефон уже доверяет.
Где семья будет, в какие дни и в какие часы. Одно событие календаря, место, два сохранённых временных слота и название, в котором упомянута семья (так что список гостей есть в строке, даже если записи об участниках пусты).
Кто из семьи там будет. Табель называет тех, кого оценил как семью, сущность домохозяйства объединяет их, а круг Семейного доступа говорит, кто из них в одной семейной группе.
И, в том же файле, что установлено на машине, вплоть до менеджера паролей.
Нетрудно представить, как это можно обратить во вред, если эта единая точка отказа вашей приватности попадёт не в те руки. Этот (гипотетический) сценарий мы разыгрываем во второй статье. Утешает одно: эти сведения должны оставаться локально на вашей машине под защитой разрешения «Полный доступ к диску»; хотя их могут потреблять и другие сервисы (но как и что именно доступно, нам до конца не ясно).
На деле объём информации в этом хранилище поразителен: каждый раз, когда мы разбираемся, что и как выводят демоны, открывается несколько новых направлений для исследования. Всё, что вы предпочли бы скрыть о себе или своей семье, вполне может где-то там лежать, и мы считаем, что вы вправе знать, так ли это. А вместо этого у вас нет ни документации, ни способа посмотреть хранилище, ни общего способа исправить ошибочный вывод.
Поэтому мы даём два инструмента. Первый — iKnow, локальная панель для просмотра собственного графа, при этом ничего не покидает ваш Mac (о ней следующий раздел). Второй — для тех, кто хочет копнуть глубже. В репозитории iKnow есть инструкция для вашего агента: где лежат базы и как их читать, чтобы агент мог искать то, что вам нужно. (Пожалуйста, используйте с ней модель на своём железе; облачную не надо.)
iKnow
Мы сделали iKnow как веб-панель на стандартной библиотеке Python: ни npm, ни CDN.
Запускать её нужно прямо на Mac, где лежат базы. При запуске она слушает 127.0.0.1, находит базы в файловой системе (если выданы нужные разрешения), открывает их только на чтение, собирает сведения на лету и показывает на панели. Ничего не записывается и не логируется: значения идут из хранилищ через loopback во вкладку браузера. Можно запускать и без сети.
Мы проверили её на macOS 26.6.2 и 26.7.1 и частично на 27.0.1.
В iKnow около дюжины страниц.
С чего начать
Что знает ваш Mac. Стартовая страница: граф людей вокруг вас. Ниже — лица с ваших фото, ваша семья, ваши контакты, ваши собеседники и то, где вы будете в ближайшее время.
Её граф — то же синтетическое домохозяйство, что и на интерактивном графе в оригинале, только нарисованное собственным рендерером инструмента:

Первый экран. Белый узел с пометкой (Me) — владелец Mac, остальные — люди, работодатели и групповые чаты, которые хранилище с ним связывает, раскрашенные по тому, кем, по его мнению, является каждый. Оранжевый — семья по оценке. Синий — оценка близости выше порога. Бледные имена по краям — люди, которых хранилище знает, но не разместило.
Здесь нет никакой сводки, которой не было бы в записи: каждый узел — строка, и в самой панели щелчок по нему показывает эту строку.
Граф — это обзор, а обзор легко пролистать. Страницы за ним так не пролистаешь.
Социальный граф. Кого хранилище связывает с кем через общие встречи, групповые чаты и оценку близости. Каждый круг раскрывается до участников и доказательств.
Что система заключила
Табель родства. Семейные связи, которые вывел демон.
На стартовой странице его карточка урезана до названных в ней людей. Заголовок — «Семья, как её видит табель», подзаголовок — «61 человек оценён по 17 столбцам отношений. Никто ничего из этого не вводил». В ней шесть человек, у каждого одна метка и одна оценка: Мара Квилл, мать, 0,960; Томас Квилл, отец, 0,960; Майя Смит, дочь, 0,960; Нильс Квилл, брат, 0,500; Лео Смит, сын, 0,500; Инес Квилл, сестра, 0,500. В разделе «Домохозяйство по числу совпавших сигналов» у Мары Квилл 8 из 9, у Томаса Квилла и Прии Сандовал по 7 из 9, у Майи Смит 6 из 9, и последний раздел называет домохозяйство Квиллов: 4 члена, уверенность 0,880.
Шесть человек, шесть отношений и подзаголовок, что никто ничего из этого не вводил. Для оценок это верно; но часть того, из чего они вычислены, вы всё-таки вводили (отношение в карточке контакта, экстренный контакт, Семейный доступ). Мать, отец и дочь — 0,960, выше эти столбцы не поднимаются; брат, сын и сестра — 0,500.
Ниже идёт та часть, с которой мне спорить труднее всего. Девять отдельных проверок (столбец партнёра, составная оценка, сущность-группа домохозяйства, токен Семейного доступа, флаг Семьи iCloud, лучший контакт за двенадцать месяцев, кластер лиц в Фото, запись в Контактах, доступный контакт), и карточка считает, сколько из них указывают на одного и того же человека. Восемь из девяти у матери; семь у отца и семь у Прии Сандовал — партнёра владельца, которого нет в списке выше. iKnow показывает отношения, которые сворачиваются в другой столбец (мать и отец в родитель), а партнёр ни во что не сворачивается. И всё же сопоставление нашло партнёра.
Карточка — сводка одной таблицы, и iKnow рисует таблицу целиком: тепловую карту «Каждый человек, каждый столбец», тридцать человек на семнадцать столбцов отношений, отсортированных по familyAndFriends, самой широкой из оценок. Семеро сверху подсвечивают каждый своё отношение и столбец, в который оно сворачивается (мать и отец в родитель, сестра и брат в брат или сестра, сын и дочь в ребёнок), а партнёр заодно ещё и коллега. Ниже — друзья и остальной офис. Под ними почти у всех остальных одни и те же две ячейки: одно повторяющееся значение в family и другое в familyAndFriends. Это то, что классификатор пишет, когда сказать ему нечего. Два столбца (alumni и unknown) не используются вовсе.
Оценки на этих двух снимках в оригинале (карточка и тепловая карта) выдуманы и щедрее настоящих. На Mac, который мы разбирали, верха шкалы достигла только мать; немногие другие, кого система вообще оценила, получили по одному маленькому голосу сразу за все семейные метки, и за отца, и за брата. Из настоящей таблицы фикстура сохраняет её зернистость: таблица пишет всего несколько значений (0,125, 0,25, 0,5 и 0,96), и большинство людей сидит на одном значении по умолчанию.
Индекс лиц. Кластер лиц для каждого, кто есть на ваших фото.
Граф совместного появления лиц не использует ни одного контакта, сообщения или события календаря. Он построен только из фотографий. На снимке экрана в оригинале — сорок семь кругов с размытыми лицами, соединённых, если двое оказались на одном снимке, и подписанных шестисимвольными фрагментами идентификаторов кластеров. В центре один кластер, связанный почти со всеми; слева плотный узел, выше группа посвободнее, а третья группа справа внизу не имеет ни одной связи с узлом.
Два лица соединены, если они есть на одной фотографии, и это единственный вход: 8904 кластеризованных лица на 1643 снимках, где людей больше одного. Подписи — фрагменты локальных идентификаторов кластеров, потому что имён показать нечего. Владелец — центр. Узел слева — семья, группа справа внизу — работа, и вместе в кадр они не попадают ни разу.
Каждый узел показывает ключевое лицо своего кластера, взятое из фотобиблиотеки и размытое переключателем iKnow для демонстрации экрана. Под размытием никого нет: у фикстуры нет фотобиблиотеки, так что все лица — синтетические портреты, нарисованные для неё.
Здесь страница честно показывает главное: граф указывает на кластеры лиц и почти ни одного не может назвать (в фикстуре — три из двадцати девяти). Ему это и не нужно. Кто стоит рядом с кем, как часто и какие группы никогда не пересекаются — всё есть и без единого имени. Тот, кто знает семью, вернёт имена за секунду.
Угадано или введено. То, что вы ввели сами, и то, что Mac вычислил сам, живут в одной таблице. Разделяет их только оценка уверенности.
Что система записала
Год общения. С кем вы общались, когда, и ни слова из текста сообщений (а ему и не нужно, чтобы понять, когда вы спите).
Именно эта карточка на стартовой странице вызывает больше всего реакций, и в ней нет никакого вывода вообще. Подзаголовок: «18 432 взаимодействия за 365 дней, 146 собеседников (97 с именами), 5 приложений — и ни одного слова текста». В ней восемь человек с числом взаимодействий, разбивкой на входящие и исходящие, числом звонков и датой последнего контакта, а последний раздел называется «Часы, которые можно прочитать как сон».
Год общения по каждому человеку, входящие и исходящие, звонки и дата последнего контакта по пяти мессенджерам — и, как и сказано в подзаголовке, ни слова текста. Ничто из этого не содержимое. Это всё метаданные, и их достаточно.
Последнюю строку стоит перечитать дважды: часы, которые можно прочитать как сон.
iKnow рисует и её, из того же журнала, сложенного в одну неделю. Первая карточка, «День недели против часа суток: когда этот человек на связи и когда спит», — тепловая карта: семь строк дней недели на двадцать четыре столбца часов. Бледная полоса с 01 до 07 каждый день, по субботам и воскресеньям сдвинутая позже, тёмное плато в рабочее время по будням и самые тёмные клетки с 20 до 22. Вторая карточка, «Часы, когда журнал затихает: режим сна, который никто не записывал», сообщает: «Часы, на которые приходится меньше 25% от равномерного распределения, образуют один непрерывный отрезок в 6 часов, с 01:00 до 07:00 по лондонскому времени. На него приходится 402 из 18,4 тыс. событий (2%)».
Каждая клетка считает сообщения и звонки, пришедшиеся на один час одного дня недели за год. Там видна рабочая неделя, вечера и поздние выходные утра; и бледная полоса с часу до семи каждую ночь. Никто не сохранял режим сна. Самый тихий шестичасовой отрезок выпадает из временных меток сам собой.
Таково общее устройство этого хранилища: почти ничего в нём не пришлось собирать специально, потому что почти всё в нём — следствие того, что собрано.
Календарь. Единственный слой, который знает, где вы будете: час, комната, участники и ссылка для подключения.
Что вы отозвали. Отзыв факта его не удаляет. Строка переезжает в таблицу просроченных и сохраняет уверенность и происхождение.
Механизмы
Хранилище. Сам файл: что он моделирует и две настоящие строки, развёрнутые во всё, чего они касаются.
Отпечаток устройства. Каждое установленное на Mac приложение записано открытым текстом рядом с токеном, который представляет собой несолёный SHA-256 от того же идентификатора приложения. Страница пересчитывает его в браузере, и вы видите, как он совпадает.
Кто ещё это читает. Граф — первая копия, но не единственная. Эта страница показывает представления, которые на него подписаны, базы, в которые они публикуют данные, таблицы с повторами тех же фактов, потоки от сопряжённого с Mac оборудования и механизмы, которые настроены, но ещё не запускались.
Замечание о macOS 27. macOS 27 вышла 14 сентября 2026 года. После обновления до 27.0.1 граф отозвал большую часть строк, построенных из Контактов, Календаря, Предложений Siri, Семейного доступа и каталога приложений, и за следующие сутки построил их заново. Некоторые страницы iKnow на macOS 27 пока могут работать не полностью.