Архитектура и состав Home Ψ Lab

Home Ψ Lab — собирательное название всей инфраструктуры на собственном оборудовании. Городская площадка состоит из физического Beelink, базовой среды Proxmox VE и трёх изолированных гостевых систем. Отдельно в Home Ψ Lab входит дачная площадка Territory Ψ Edge на собственном Dell Wyse; её смысл и граница описаны на отдельной странице.

Устройство версии 1.0

flowchart TB
    hardware["Beelink — физические вычисления, память, диски и сетевые интерфейсы"]
    proxmox["Proxmox VE — базовая ОС и гипервизор"]
    gateway["Psi Gateway — Debian<br/>сетевой периметр и доступ"]
    omr["Territory OMR Server — Linux<br/>городской конец дачного World transport"]
    nexus["DETai Nexus — Ubuntu<br/>знания, модели и агентный runtime"]

    hardware --> proxmox
    proxmox --> gateway
    proxmox --> omr
    proxmox --> nexus

Уровень	Реализация	Ответственность
Физическая основа	Мини-ПК Beelink	Предоставляет вычислительные, дисковые и сетевые ресурсы лаборатории
Базовая среда	Proxmox VE	Управляет виртуальными ресурсами, изоляцией и жизненным циклом гостевых систем
Сетевой контур	Psi Gateway, Debian	Завершает внешний сетевой вход, применяет сетевую политику и обеспечивает локальный доступ
Territory OMR Server	отдельная Linux VM	Даёт городской endpoint одному из резервных World-транспортов Territory Ψ Edge; принадлежит дачному контуру по ответственности, хотя физически размещён на Beelink
Вычислительный контур	DETai Nexus, Ubuntu	Предоставляет Linux-среду для моделей, знаний, retrieval, enrichment и прикладных компонентов

Формулу «операционная система, которая создаёт операционные системы» полезно понимать как простую метафору. Proxmox — установленная на физическом узле Linux-среда и гипервизор: он создаёт виртуальные машины, выделяет им ресурсы и запускает внутри каждой собственную гостевую ОС. Поэтому один компьютер может поддерживать несколько логически отдельных систем.

Почему Gateway и Nexus разделены

Psi Gateway и DETai Nexus различаются не только названиями, но и классом ответственности.

• Gateway относится к базовой связности: его задача — предсказуемо и безопасно соединять локальную лабораторию с внешними сетями.
• Nexus относится к вычислительной и смысловой работе: модели, индексы, обработка знаний и агентные процессы могут развиваться быстрее и чаще меняться.

Изоляция не устраняет все общие риски одного физического хоста, но сокращает область влияния программных изменений. Эксперимент или обновление в Nexus не должны автоматически менять сетевую политику Gateway. Сетевой компонент, в свою очередь, не получает прикладные данные и функции только потому, что обе системы используют одно оборудование.

После фиксации Home Ψ Lab v1.0 эти контуры имеют отдельные циклы развития: общая лаборатория отвечает за физическую основу и Proxmox, Psi Gateway — за сеть и защищённую связность, DETai Nexus — за вычислительную и агентную среду. Territory OMR Server остаётся техническим компонентом Territory Ψ Edge и не превращается в самостоятельный городской infrastructure-контур только из-за места размещения.

Gateway как provider, Nexus как environment

Разделение Gateway и Nexus становится ещё яснее через provider–consumer модель Infrastructure.

Psi Gateway может предоставлять Network capability другим runtime-компонентам: regional egress, private network endpoints, routing, network health, tunnels и другие сетевые возможности. Consumer зависит от стабильного network contract, а не от конкретной внутренней реализации Gateway.

DETai Nexus при этом остаётся execution environment. Если Telegram-facing компонент работает на Nexus и использует сетевую capability Gateway, это не создаёт цепочку ownership component → Nexus → Gateway.

flowchart LR
    consumer["Consumer @ DETai Nexus"]
    contract["Network capability contract"]
    gateway["Psi Gateway"]

    consumer --> contract --> gateway

Nexus отвечает за размещение и ресурсы consumer, но не становится обязательным логическим middleware только потому, что процесс запущен внутри него. При переносе consumer на другую execution environment network contract может сохраниться без переноса чужой ответственности.

Network provider также не должен знать бизнес-контекст consumer. Например, Gateway может оперировать logical network profile, его health и routing state, но ему не требуется знать конкретный Telegram account, публикацию Storytelling или другую предметную сущность.

DETai Nexus как вычислительная среда

DETai Nexus размещает компоненты нескольких самостоятельных систем. Он не объединяет их репозитории и не забирает их ответственность:

Слой	Владелец	Содержимое
Продуктовый смысл	соответствующий продукт	Правила, contracts и human review
LLM-исполнение	intelligence-runtime	Сценарии, model roles, adapters, validators и traces
Общие живые процессы	ecosystem-runtime	API, боты, workers и runtime-данные
Каноническое знание	Knowledge Substrate	Документы, knowledge pipelines, retrieval и detai_core
Машина и deployment	Infrastructure	Ресурсы, сервисы, модели, данные и backup

Репозитории остаются самостоятельными источниками истины, а Infrastructure связывает их на конкретной машине.

Как продукты подключаются к LLM

Продукт передаёт собственные правила и contracts. Intelligence Runtime создаёт для него проектную проекцию: технический сценарий, который связывает эти правила с доступными LLM и проверками. Модели и inference runtime размещаются в Nexus, а результат возвращается продукту для предусмотренного human review.

Подробнее эта граница объяснена на странице intelligence-runtime.

Данные и память

PostgreSQL и Qdrant имеют отдельные постоянные области данных и не смешиваются с Git checkout или scenario cache.

• knowledge-данные принадлежат Knowledge Substrate;
• общие operational schemas принадлежат ecosystem-runtime;
• product-specific schemas принадлежат соответствующим продуктам;
• Qdrant хранит векторные проекции по versioned retrieval contracts, а не неструктурированные копии runtime cache.

Веса моделей и inference binaries являются общими машинными ресурсами. Код сценария ссылается на model roles, поэтому физическую модель можно менять через конфигурацию и benchmark без переноса продуктовой семантики.

Архитектурные принципы

Собственная основа без изоляционизма

Лаборатория не ставит цель самостоятельно воспроизвести каждый облачный сервис или отказаться от внешних моделей. Её задача — сделать зависимости явными и управляемыми. Критически важные знания, версии, правила и данные должны сохранять переносимость, а внешние компоненты — иметь понятную границу и, где это практически возможно, путь замены.

Техника подчинена смыслу и ответственности

Инфраструктура психотерапевтической экосистемы не нейтральна: способы хранения, доступа, поиска и автоматизации влияют на то, какие различия система замечает и кому отдаёт право решения. Поэтому собственная вычислительная среда важна не сама по себе. Она создаёт место, где команда может осознанно проектировать технологию вокруг метода, человеческой субъектности и профессиональной ответственности.

Инфраструктура — длительное обязательство

Готовность версии 1.0 означает, что базовая архитектура собрана и работает, а не что работа завершена навсегда. Узел требует обновлений, мониторинга, резервного копирования, проверки восстановления, управления доступом и документирования изменений. Эти процессы относятся к эксплуатации и не раскрываются на публичной странице.

Home Ψ Lab остаётся частью распределённой Infrastructure. Перенос stateful- сервиса включает проверяемый backup, изолированный restore, отдельный cutover и ограниченный период read-only fallback; создание копии данных само по себе не является cutover.

Отдельная площадка: Territory Ψ Edge

В Home Ψ Lab входит и отдельный дачный контур Territory Ψ Edge. Он не является ещё одной VM городского Beelink: это собственная физическая площадка с локальным edge-узлом, двумя пользовательскими сетями и связью с городским Network Provider.

Эта граница важна не только технически. Territory Ψ Edge создаётся для Территории Психеи — пространства, где будут проходить очная психотерапия, группы, тренинги, семинары и другие образовательные форматы. Поэтому задача контура — не демонстрировать сетевую сложность, а заранее убрать её из пользовательского опыта: базовая связь должна просто работать.

Граница документа

Публично фиксируются назначение уровней, операционные системы, разделение ответственности и устойчивые архитектурные принципы. Hostnames, IP-адреса, учётные данные, ключи, точная сетевая топология, конфигурации, команды и журналы работ остаются во внутренних системах ClickUp и Infrastructure согласно документационной архитектуре DETai.