NCE — Neuro-Cognitive Engine

Многоарендная память и логическая основа для ИИ-агентов с набором бизнес-движков, построенных на ней.

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

Создано на Python с использованием Postgres, MongoDB, Redis и MinIO. Доступно через MCP (JSON-RPC 2.0) и REST.

Что здесь находится

Числа подсчитаны по дереву, а не оценены. Количество инструментов проверяется тестом (tests/test_tool_registry.py), поэтому оно не может отклониться от реальности без сбоя сборки.

Что стоит внимания

Изоляция арендаторов обеспечивается базой данных, а не соглашением. Каждая таблица с привязкой к арендатору содержит ENABLE + FORCE ROW LEVEL SECURITY с политикой на namespace_id. Прикладной код дополнительно явно фильтрует, потому что суперпользовательское соединение обходит FORCE RLS, и тест, забывающий об этом, ничего не доказывает. tests/test_rls_catalog.py вызывает сбой сборки, если какая-либо таблица арендатора добавлена без регистрации.

Право на запись запрещено по умолчанию. Движки не записывают данные друг друга. nce/config_data/node-ownership.json сопоставляет (node_type, transition) → owning engine, и assert_owner отклоняет всё незарегистрированное на месте записи. Владение может быть по переходу, а не только по узлу: статус ORDERED строки заказа на закупку принадлежит модулю Procurement, DELIVERED — Warehouse, INSTALLED — Field Tech, и одна и та же проверка выражает все три.

Журнал аудита является append-only на уровне базы данных. event_log имеет триггер WORM; UPDATE и DELETE отозваны, а не просто не используются.

Автономия ограничена. Инструменты, изменяющие мир, по умолчанию требуют подтверждения человеком, имеют ключ идемпотентности и записываются в журнал аудита. Перед ними стоят ограничения на значение и объём, белый список и аварийный выключатель. Повторное выполнение действия — это no-op, а не вторая запись.

Деньги и себестоимость не покидают здание. Проектор полей с белым списком (project(node, surface)) контролирует, что достигает внешней поверхности. Маржа и себестоимость отсутствуют в любом белом списке.

Сгенерированный текст обоснован. Текст собирается из фактов, уже находящихся в графе, причём каждое утверждение связано с узлом, из которого оно получено, а не создаётся свободно и проверяется задним числом.

Данные могут поступать из двух систем одновременно. Разрешитель для каждого пространства имён определяет, читает ли данная функция из Dynamics 365, из NCE или из обеих, и регистрирует расхождение, когда они не совпадают — чтобы миграцию можно было измерить до того, как она будет зафиксирована.

Вертикальные движки

Одиннадцать движков имеют код в main. Каждый владеет своими таблицами, своими типами узлов и документированной границей с остальными.

procurement · product · agreements · vendors · sales · system_design · project · economy · inventory · dynamics365 · diagnostics

Планируется 17 движков. Они создаются постепенно и не завершены; см. Статус ниже.

Как это построено

Набор движков не пишется вручную за один проход. Он строится как последовательность небольших модулей — запланировано 229, каждый на одну задачу, каждый в своей ветке и коммите — и каждый модуль проходит независимую состязательную проверку перед принятием.

Проверка выполняется другим экземпляром модели, не тем, что писал код, с конкретной инструкцией попытаться его сломать и по умолчанию отклонять при неуверенности. Это неоднократно оказывалось важным:

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

• Изменение шины событий помечало бы события как успешно опубликованные, при этом молча их теряя, потому что обработчик записывал в лог и возвращал управление вместо того, чтобы вызвать исключение. Проверка отклоняла его дважды, прежде чем что-либо было выпущено.

• Тест, проверяющий правило точности десятичных чисел, оказался проходимым одинаково как с применением правила, так и без него, потому что его единственный фикстура округляла одинаково в обоих путях.

Повторяющийся урок: зелёный набор тестов говорит меньше, чем кажется. Свойства, которые выходят из строя, обычно те, которые в docstring утверждаются наиболее уверенно, и ни один тест на самом деле их не различает.

Запуск

cp .env.example .env          # fill in the values
make local-up                 # Postgres, MongoDB, Redis, MinIO via docker compose
make lint typecheck           # ruff + mypy
pytest -m "not integration"   # unit tests, no database required
pytest -m integration         # requires the stack above

Интеграционные тесты пропускаются, а не завершаются ошибкой, когда база данных недоступна. Зелёный код возврата с пропущенными тестами не является успешным прогоном — проверяйте количество.

Документация

Полная документация опубликована по адресу sindrehaugen.github.io/neuro-cognitive-engine — архитектура, восемь записей архитектурных решений, руководства администратора и пользователя по каждому движку, справочник общего ядра и поваренная книга MCP-инструментов.

Стоит начать с:

• Архитектура — стек из четырёх баз данных и расположение слоёв

• Общее ядро — разрешение сущностей, владение, управление автономией, редактирование

• Мультиарендность — как применяется FORCE ROW LEVEL SECURITY

• Поваренная книга MCP-инструментов — поверхность инструментов с флагами шлюзования

• ADRs — решения и их компромиссы

Структура

nce/                    engine core: memory, graph, RLS, autonomy, signing, replay
nce/vertical_modules/   the business engines
nce/migrations/         idempotent SQL, re-applied on boot under an advisory lock
tests/                  391 files; integration tests marked and CI-wired
docs/                   source for the published documentation
go/                     launcher and hardware detection
trimcp-infra/           Terraform for AWS and GCP
deploy/                 compose stacks and container images

Статус

В активной разработке. Одиннадцать из семнадцати движков имеют код в main; двенадцатый в процессе. Базовая подсистема — изоляция арендаторов, владение, управление автономией, журнал аудита, подпись, повторное выполнение — завершена и используется вышестоящими движками.

Этот репозиторий опубликован для демонстрации архитектуры и инженерного подхода. Это не готовый продукт, и обязательств по поддержке нет.

Лицензия

Проприетарная. Все права защищены. Опубликовано для ознакомления; не лицензировано для повторного использования.

Синдре Лёвли Хауген · github.com/sindrehaugen