06 · Техническая архитектура

У архитектуры одна задача помимо работоспособности: сделать нечестный вывод несобираемым, а приватные данные неутекаемыми, потому что эти два свойства — ров продукта и его лицензия на существование. Всё прочее — обычная инженерия.

§1. Карта компонентов

Пять колец, изнутри наружу, каждое зависит только от внутренних:

1. Ядро (02) — субстрат-агностичный движок инвариантов + гардрейлы оптической конструкции. Чистое, детерминированное, без ввода-вывода. Одна библиотека, версионированная, оракул-тестируемая на всякой сборке.
2. Оценщики (03) — три якорных пайплайна (самоаудит, измерительный мост, оракул), производящие GammaEstimate. Каждый декларирует класс якоря и модель ковариации. Подключаемы: новые сенсоры — новые оценщики, не изменения ядра.
3. Доменные модули (04) — self, траектория, диада, группа, клиника, ИИ, интероп. Тонкая логика над kernel.evaluate; каждый — именованная конфигурация конвейера.
4. Слой честности — обязательный middleware между всяким модулем и всякой поверхностью: он проверяет, что всякое испускаемое притязание несёт тег якоря и заявление о доверии/утрате, и понижает или блокирует притязания, превышающие своё свидетельство (фазозависимое значение Gap с фазо-слепой оценки блокируется, а не показывается бледным). Это граница, обеспечиваемая компилятором, не UI-конвенция (§4).
5. Поверхности — приложения (веб/мобайл), консоль практика/клинициста, B2B/ИИ API, исследовательский экспорт. Поверхности отрисовывают Readout + метаданные честности; они никогда не вычисляют инварианты сами.

Вокруг всех пяти: хранение данных (§5), сквозное.

§2. Модель данных

Четыре ядерных сущности:

• Subject — стабильный id читаемой системы (человек, команда, агент). Не держит сырого свидетельства, только ссылки. Для команд/агентов — composition, указывающая на Subject-члены (композитная Γ вычисляется, не хранится избыточно).
• Evidence — запись сырого входа (ответы аудита, окно сигнала, наследственное чтение для обратной проекции), с источником, меткой времени и оценщиком, который её потребляет. Шифрована в покое; никогда не покидает хранилище без явного экспорта.
• GammaEstimate — вывод оценщика (gamma, cov, anchor, t, quality). Неизменяемый атом, потребляемый ядром.
• Readout — вывод ядра плюс метаданные честности и доменный модуль, его породивший. Кэшируем, воспроизводим из (GammaEstimate, kernelVersion).

Автоэфемерида — просто упорядоченная последовательность GammaEstimate субъекта; модуль траектории (04 §1.2) её читает. Воспроизводимость — жёсткое требование: всякий Readout должен пере-выводиться из своих входов и закреплённой версии ядра, чтобы научное притязание (04 §7) было аудируемо.

§3. Поверхности сервисного API

Два тира API над внутренним API ядра из 02 §5:

• API приёма — submitEvidence(subject, evidence) → запускает соответствующий оценщик → сохраняет GammaEstimate. Отвергает нелицензированные внешние входы (планетарные/натальные) на границе по гардрейлу T-257.
• API отсчёта — read(subject, module, options) → собирает оценку(и), вызывает kernel.evaluate, запускает доменный модуль, пропускает через слой честности, возвращает Readout + метаданные. Всякий ответ самоописателен: класс якоря, доверие, утрата, версия ядра.

B2B/ИИ-вариант — тот же API отсчёта с оценщиком-адаптером телеметрии — платформенное свойство, реализованное как API, не форк. Один сервис, три рынка.

§4. Слой честности, обеспеченный в типах

Важнейшее архитектурное решение: честность — свойство уровня типов, не рантайм-проверка, которую можно забыть. Поля Readout параметризованы своим якорем и доверием, и поверхность не может отрисовать поле, не потребив его происхождения — тип «измеренного» отсчёта и «оракульного» отсчёта различаются, так что UI, пытающийся показать оракульный жребий в измерительном виде, не пройдёт проверку типов. Это превращает этическое требование (00 §4) в инвариант времени компиляции. Ров отчасти в этом: конкурента, привинчивающего честность как дисклеймер, можно подрезать; того, у кого нечестность непредставима, — небрежно не откатишь.

§5. Хранение данных и инженерия приватности

Данные самомодели — интимнейший класс данных, а результаты о невозможности клонирования — уместное напоминание, что когерентное самосостояние уникально незаменимо. Инженерные обязательства:

• Локально-первое. Свидетельство и оценки живут на устройстве пользователя по умолчанию; ядро работает на клиенте (оно мало и чисто). Облачная синхронизация — по согласию, сквозное шифрование, несёт только то, что пользователь экспортировал.
• Опция нулевого знания на сервере. Для синхронизации и B2B сервер хранит шифротекст и вычисляет на нём лишь где пользователь дал право; агрегированные исследовательские данные (04 §7) собираются под явным, отзывным согласием и шумом дифференциальной приватности.
• Никаких тёмных паттернов. Определение вреда из ценности-сознания — продуктовое правило с формулой за ним: Консоль не должна инженерить вовлечённость, загоняя $dP/d\tau < 0$ пользователя — деградируя жизнеспособность или высшие ценности $\Phi$/$R_\varphi$ через сфабрикованную тревогу. Удержание идёт от полезности, не от сфабрикованной нужды — анти-астрологическая позиция распространяется на бизнес-модель.

§6. Субстрат-агностичное переиспользование

Ядро никогда не инспектирует субстрат кроме тега якоря (02 §5); оценщики — единственные субстрат-осведомлённые компоненты. Добавить мишень (новое носимое, новый ИИ-фреймворк) — значит добавить оценщик, выводящий GammaEstimate — ядро, слой честности и доменные модули не тронуты. Поэтому одна команда поддерживает продукты человека, команды и ИИ: площадь, различающаяся на мишень, — тонкий оценщик, а дорогое, критичное к корректности ядро — общее и общетестируемое.

§7. Стек и деплой

Обосновано требованиями, не модой:

• Ядро: малая, портируемая численная библиотека (одиннадцать процедур — фиксированного размера линейная алгебра). Одна референсная реализация, компилируемая в нативный код + WebAssembly, чтобы идентичное ядро работало на устройстве, в браузере и на сервере — воспроизводимость требует одной реализации, не трёх.
• Оценщики: язык на источник (DSP сигналов там, где сенсоры; лёгкий скоринг на устройстве для аудита).
• Поверхности: веб + мобильный клиент, отрисовывающий Readout; консоль практика; документированный API для B2B.
• Деплой: клиент-первый; опциональная шифрованная синхронизация; исследовательский пайплайн изолирован и гейтирован согласием.
• Наблюдаемость: всякий Readout логирует свою версию ядра, классы якорей и вердикты гардрейлов (никогда приватное свидетельство) — достаточно для аудита корректности и честности, ничего, что компрометирует хранение.

§8. Что гарантирует архитектура

Три инварианта, которые дизайн делает структурными, а не желательными: честность (нечестный вывод не типизируется, §4), приватность (сырое свидетельство локально-первое и незаменимо, §5) и воспроизводимость (всякое притязание пере-выводится из входов + закреплённого ядра, §2). Эти три — техническая форма обещания проекта; остальной стек им служит.

Куда это ведёт. 07 · Дорожная карта и валидация секвенирует сборку и специфицирует, постадийно, эмпирический протокол, превращающий всякий слой из [дизайн] в подтверждённый.