Создание интеллектуального CRUD-приложения на Holo Engine

Идея: от CRUD к интеллектуальному CRUD

Большинство бизнес-приложений начинается с CRUD: создать, прочитать, обновить и удалить записи. CRM хранит клиентов и сделки. Складская система хранит локации и остатки. HR-приложение хранит сотрудников и события. Финансовое приложение хранит транзакции и состояния периодов.

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

Holo Engine позволяет строить приложение вокруг более богатой модели:

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

Важное архитектурное решение: интеллект — это не отдельный продукт, подключаемый позже. Это свойство состояния, которое продукт и так создаёт.

Архитектура на одной диаграмме

Ваш API по-прежнему владеет аутентификацией, правами, валидацией и бизнес-правилами. Holo Engine владеет операционным состоянием для этого сценария: записи, ветки дерева, их атрибуты, импортированные строки и индексированный текст.

Модель данных: пути для структуры, атрибуты для состояния

Каждой бизнес-записи нужен стабильный адрес. В Holo Engine этот адрес — путь в дереве. Используйте пути для части модели с естественной иерархией, а атрибуты — для полей, описывающих запись.

Для CRM чистое стартовое дерево:

/crm
  /customers
    /northstar-logistics
      /contacts
        /olga-petrova
      /deals
        /renewal-2026
  /segments
    /enterprise

Путь показывает где находится запись. Атрибуты показывают чем запись является сейчас:

{
  "company": "Northstar Logistics",
  "segment": "enterprise",
  "stage": "proposal",
  "owner": "maya",
  "priority": "high",
  "country": "GE"
}

Используйте предсказуемые URL-безопасные метки, такие как northstar-logistics и renewal-2026. Храните человекочитаемое имя в атрибуте. Это даёт UI стабильные пути, даже если отображаемое имя меняется.

Шаг 0: Создание одного хелпера для авторизованных запросов

Все вызовы принадлежат одному тенанту, определяемому API-ключом. В вашем серверном приложении создайте хелпер, который добавляет заголовок авторизации и передаёт JSON без изменений.

const HOLO_BASE = "https://api.hiholo.ai";

export async function holo(path, method = "GET", body) {
  const response = await fetch(`${HOLO_BASE}${path}`, {
    method,
    headers: {
      Authorization: `Bearer ${process.env.HOLO_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: body ? JSON.stringify(body) : undefined
  });

  if (!response.ok) throw new Error(await response.text());
  return response.json();
}

Этот хелпер — не вторая база данных. Это безопасная граница между публичным UI и ключом тенанта Engine. Держите API-ключ в серверном сервисе или edge-функции; не отправляйте ключ тенанта в браузер.

Шаг 1: Create — добавить ветку и запись

POST /api/insert добавляет узел под явным родительским путём. Это правильный примитив, когда пользователь создаёт один объект в бизнес-приложении: клиента, складскую локацию, сотрудника или отчётный период.

Сначала создайте CRM-ветки:

await holo("/api/insert", "POST", {
  parent_path: "/",
  label: "crm",
  attributes: { type: "application" }
});

await holo("/api/insert", "POST", {
  parent_path: "/crm",
  label: "customers",
  attributes: { type: "collection" }
});

Теперь создайте клиента. Та же структура работает для отдельной записи в любом месте дерева:

await holo("/api/insert", "POST", {
  parent_path: "/crm/customers",
  label: "northstar-logistics",
  attributes: {
    company: "Northstar Logistics",
    segment: "enterprise",
    owner: "maya",
    country: "GE",
    priority: "high",
    lifecycle: "active"
  }
});

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

Создание множества записей сразу

Используйте POST /api/seed при загрузке исторического экспорта или большого плоского датасета. Он принимает массив объектов со строковыми, числовыми и булевыми колонками; числовые значения можно распределить по квантильным бакетам. Отлично подходит для начальной истории транзакций, исторических возможностей или импорта каталога.

await holo("/api/seed", "POST", {
  rows: [
    { segment: "enterprise", country: "GE", stage: "won", amount: 42000 },
    { segment: "mid-market", country: "GE", stage: "lost", amount: 8000 },
    { segment: "enterprise", country: "TR", stage: "won", amount: 97000 }
  ],
  target_key: "stage",
  numeric_bins: 4
});

Используйте явные пути insert для интерактивного дерева продукта. Используйте seed для массовых исторических строк и датасетов, которые позже поддержат обнаружение паттернов или предсказание. Оба сохраняются в том же хранилище тенанта и доступны для последующих возможностей Engine.

Создавайте и поисковые документы

В бизнес-приложениях есть и неструктурированное состояние: клиентский бриф, складской отчёт об инциденте, политика или заметка с интервью. POST /api/feed_text сохраняет и индексирует документ как текстовые узлы, не требуя сервиса эмбеддингов.

await holo("/api/feed_text", "POST", {
  doc_id: "northstar-renewal-notes",
  text: "Клиент запросил контракт на 24 месяца и хочет локальный контакт поддержки.\n\nРешение по продлению запланировано на сентябрь.",
  metadata: {
    customer: "northstar-logistics",
    area: "sales",
    owner: "maya"
  }
});

Это позволяет обычной CRM-записи содержать как структурированное состояние, так и документы, которые его объясняют.

Шаг 2: Read — открыть, отфильтровать, найти

Чтение в приложении на дереве имеет три простых режима.

Открыть узел и его ближайших детей

GET /api/get?path=... — примитив навигации. Возвращает выбранный узел и его детей.

const customer = await holo(
  "/api/get?path=/crm/customers/northstar-logistics"
);

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

Фильтр по атрибуту

GET /api/search?key=...&value=... ищет узлы по атрибуту. Это простой фасетный фильтр для экранов приложения.

const highPriority = await holo(
  "/api/search?key=priority&value=high"
);

Ответ включает количество и совпадающие пути. Приложение может затем открыть каждый путь или показать пути напрямую как список результатов.

Поиск документов, привязанных к работе

POST /api/query_text извлекает релевантные индексированные чанки из feed_text. Он комбинирует текстовые термины с метаданными, например owner:maya. Поле результата называется k, а не top_k.

const notes = await holo("/api/query_text", "POST", {
  query: "renewal local support owner:maya",
  k: 5
});

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

Шаг 3: Update — изменить состояние, не перемещая запись

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

Используйте эндпоинт обновления Engine против существующего пути записи, передавая изменённые поля состояния:

await holo("/api/update", "POST", {
  path: "/crm/customers/northstar-logistics",
  attributes: {
    stage: "proposal",
    owner: "david",
    priority: "high",
    last_activity_at: "2026-08-02"
  },
  merge: true
});

На уровне UI это просто кнопка «Сохранить» в форме редактирования. На уровне данных это изменение персистентного узла Engine, а не скопированной строки в теневой системе. merge: true сохраняет существующие атрибуты; установите false, только если форма намеренно заменяет весь набор атрибутов. Успешное обновление сообщает путь и счётчики обновлённых атрибутов, текстовых чанков и метаданных.

Шаг 4: Delete — удалить тестовую запись или закрыть ветку

Удаление работает с учётом веток. POST /api/clear может очистить всё хранилище тенанта или удалить выбранное поддерево. В приложении полезна именно точечная форма.

await holo("/api/clear", "POST", {
  path: "/crm/customers/northstar-logistics",
  remove_root: true
});

// Для деструктивного сценария подтвердите удаление через
// GET /api/get?path=/crm/customers/northstar-logistics
// и ожидайте 404.

Используйте для записи клиента, которую нужно удалить со всеми контактами и сделками, для заброшенного рабочего пространства проекта или для плохой ветки импорта. remove_root: true удаляет саму выбранную ветку; установите false, когда нужно сохранить узел ветки и очистить только то, что под ним. После деструктивного вызова проверьте цель через GET /api/get?path=...: настоящий тест — это 404 Not found, а не только счётчик в ответе clear.

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

Шаг 5: Learn — превратить подтверждённые исходы в продуктовую возможность

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

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

Ключ — отправлять категориальные, бизнес-читаемые признаки и итоговый ответ. POST /api/cognitive/observe записывает размеченные наблюдения немедленно.

// 1. Добавляйте размеченные наблюдения по мере реальных исходов
await holo("/api/cognitive/observe", "POST", {
  target_key: "outcome",
  rows: [
    {
      segment: "enterprise",
      amount_band: "high",
      activity: "recent",
      decision_stage: "proposal",
      outcome: "won"
    },
    {
      segment: "mid-market",
      amount_band: "medium",
      activity: "silent",
      decision_stage: "discovery",
      outcome: "lost"
    }
  ]
});

// 2. Спросите про одну новую, неразмеченную запись
const prediction = await holo("/api/cognitive/predict", "POST", {
  input: {
    segment: "enterprise",
    amount_band: "high",
    activity: "recent",
    decision_stage: "proposal"
  }
});

// 3. Когда реальность наступит, замкните цикл
await holo("/api/cognitive/feedback", "POST", {
  input: {
    segment: "enterprise",
    amount_band: "high",
    activity: "recent",
    decision_stage: "proposal"
  },
  actual: "won"
});

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

Для офлайн-проверки train/test используйте POST /api/cognitive/learn с train_rows, test_rows и max_rounds; он возвращает выполненные раунды, финальную точность, сходимость и историю раундов.

Пять приложений, один шаблон

API один и тот же. Меняются только структура дерева, атрибуты и интеллект-вопрос, который вы выбираете.

Дерево для каждого продукта

/crm
  /customers
    /northstar-logistics
      /contacts /olga-petrova
      /deals /renewal-2026
        /events /proposal-sent

/warehouse
  /sites /tbilisi-01
    /locations /a-03
      /items /sku-1029
        /movements /2026-08-02-001

/people
  /departments /product
    /employees /alex-ivanov
      /onboarding /equipment
      /reviews /2026-h1
  /candidates /samira-khan

/finance
  /entities /hiholo
    /periods /2026-08
      /invoices /inv-000184
      /payments /pay-000184
      /reviews /review-000184

/projects
  /atlas
    /milestones /beta
      /tasks /mobile-permissions
        /updates /2026-08-02
    /tasks /api-integration

Доменные заметки, которые важны

CRM. Храните текущее состояние сделки на узле сделки. Добавляйте дочерний узел для каждого значимого события продаж: звонок завершён, предложение отправлено, юридический обзор начат, исход подтверждён. Загружайте заметки по аккаунту и резюме встреч через feed_text. Наблюдайте только те поля, которые были доступны на момент решения — иначе модель может случайно учиться из будущего.

Склад. Каждое перемещение — дочерний узел с направлением, бакетом количества, источником и временной меткой. Приход или подбор обновляет on_hand на SKU и создаёт узел перемещения. Запустите GET /api/anomaly?path=/warehouse/sites/tbilisi-01 как сигнал структурного аудита; возвращённый barycenter_shift указывает на дисбаланс или дрейф — повод для проверки, а не доказательство ошибки. GET /api/missing?path=... может показать предсказанные структурные пробелы, которые должен проверить человек или бизнес-правило.

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

Финансы. Импортируйте исторические транзакции через seed, затем постройте классификатор приоритета проверки на основе прошлых случаев, где финальный результат проверки известен. Предсказание ранжирует, какие транзакции заслуживают проверки первыми — превращая очередь аудита из FIFO в приоритетную очередь, управляемую собственной историей движка.

Перед запуском: чек-лист релиза

Перед тем как выпустить первый сценарий, сделайте эти решения явными:

Частые вопросы

За пределами CRUD: весь Engine

Сценарий выше использует около дюжины эндпоинтов. У Holo Engine их тридцать. Как только состояние приложения живёт в дереве, та же платформа открывает возможности, которые обычно требуют отдельных продуктов, отдельных команд и отдельной инфраструктуры.

Ничего из этого не требует копирования данных в другую систему. Тот же тенант, то же дерево, тот же API-ключ.

Структурные рассуждения — /api/reason

Движок рассуждений открывает структурные законы из наблюдений и применяет их для ответа на запросы. Поддерживает 36 типов законов — арифметика, сохранение, классификация, временные последовательности, логика, заполнение сеток и более. В отличие от LLM, он даёт точные символические ответы с уверенностью и энергетическими оценками.

// Открыть закон за последовательностью, затем запросить его
await holo("/api/reason", "POST", {
  observations: "Seq t1 10 t2 20 t3 30 | observe | Y 40\nSeq t1 5 t2 10 t3 15 | observe | Y 20",
  query: "Seq t1 100 t2 200 t3 300",
  target_key: "Y"
});

Для финансового приложения это означает, что движок может обнаружить правило за серией транзакций и предсказать следующую. Для склада — обнаружить, что последовательность перемещений следует паттерну — или нарушает его.

Открытие законов — /api/discover

Имея датасет и целевую колонку, движок открывает математический закон, управляющий данными — через ДПФ (дискретное преобразование Фурье) или полиномы Жегалкина над конечными полями. Возвращает тип закона, полином, сложность и покрытие.

await holo("/api/discover", "POST", {
  rows: [
    { x: "0", y: "0" },
    { x: "1", y: "1" },
    { x: "2", y: "1" },
    { x: "3", y: "0" }
  ],
  target_key: "y",
  domain: ["0", "1"]
});

Это не статистика. Это точное извлечение закона — движок сообщает алгебраическое правило, которому следуют ваши данные.

Графовая оптимизация — /api/graph_solve

Универсальный графовый решатель на аделевой гиперболическом дереве. Поддерживает TSP, кратчайший путь, назначение, VRP с ограничением ёмкости, потоковые сети, мультискладскую маршрутизацию, временные окна и планирование задач. Узлы графа эмбедируются на диск Пуанкаре — гиперболическое расстояние направляет поиск.

await holo("/api/graph_solve", "POST", {
  dsl: "TASK shortest_path\nNODE A B C D\nEDGE A B 1\nEDGE B C 2\nEDGE C D 1\nEDGE A D 5\nSOURCE A\nTARGET_NODE D"
});

Для складского приложения — это оптимизация маршрутов по точкам доставки. Для финансового приложения — оптимизация потоков транзакций. Для инструмента управления проектами — планирование критического пути. Всё из того же движка, всё из того же состояния.

Многоагентная координация — /api/v2/connectome/solve

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

await holo("/api/v2/connectome/solve", "POST", {
  agents: [
    {
      id: "sales",
      rows: [{ x_budget: 10, x_headcount: 3 }],
      constraints: [
        { label: "budget_limit", op: "le", coefficients: { x_budget: 1 }, rhs: 50 }
      ]
    },
    {
      id: "engineering",
      rows: [{ x_budget: 20, x_headcount: 5 }],
      constraints: [
        { label: "headcount_limit", op: "le", coefficients: { x_headcount: 1, x_budget: 1 }, rhs: 100 }
      ]
    }
  ],
  bounds: [
    { variable: "x_budget", min: 0, max: 100 },
    { variable: "x_headcount", min: 0, max: 20 }
  ]
});

Для ERP — это распределение бюджета по отделам. Для проектного инструмента — назначение ресурсов по командам. Для CRM — балансировка территорий между менеджерами по продажам.

Обнаружение аномалий и анализ пробелов — /api/anomaly, /api/missing

Структура дерева сама несёт сигнал. /api/anomaly возвращает сдвиг барицентра для каждого узла — меру структурного дисбаланса или дрейфа. /api/missing предсказывает, какие элементы должны существовать в категории, но отсутствуют, используя теорию двойных слотов.

// Аудит складской ветки на структурный дисбаланс
const audit = await holo(
  "/api/anomaly?path=/warehouse/sites/tbilisi-01"
);

// Предсказать недостающие SKU в категории товаров
const gaps = await holo(
  "/api/missing?path=/warehouse/sites/tbilisi-01/locations/a-03/items"
);

Никакого аналитического пайплайна. Никакого ETL. Никакого отдельного стека мониторинга. Дерево знает собственную структуру — и знает, когда чего-то не хватает.

Ближайшие соседи на диске Пуанкаре — /api/nearest

Найдите k ближайших соседей любого узла в гиперболическом пространстве. Расстояние вычисляется через нативные Z-координаты — без эмбеддингов, без векторной базы. Полезно для рекомендаций, поиска похожих и кластеризации.

// Найти 5 самых похожих клиентов на Northstar
const similar = await holo(
  "/api/nearest?path=/crm/customers&k=5&z_re=0.12&z_im=0.34"
);

Язык Holo — /api/holo_exec

Тьюринг-полный язык для оркестрации всех API Engine в одном вызове. Естественный синтаксис: set x = 5, if x > 5 then ... end, while i < n do ... end. Встроенные функции: sqrt, json_parse, http_get, http_post и более. Без точек с запятой, без фигурных скобок.

await holo("/api/holo_exec", "POST", {
  code: "set customers = invoke http_get with \"/api/get?path=/crm/customers\"\nset count = length of customers.children\nprint at count\nif count > 10 then\n  print \"Large portfolio\"\nelse\n  print \"Growing portfolio\"\nend"
});

Один вызов. Один язык. Весь движок.

Полная карта эндпоинтов

Начните с CRUD. Добавьте интеллект, когда данные появятся. Добавьте рассуждение, открытие и оптимизацию, когда бизнес этого потребует. Тот же движок, то же дерево, тот же тенант — без миграций, без ETL, без новой инфраструктуры.

Доказательство, а не обещания: мы прогнали воркшоп на реальных данных

Мы не остановились на написании этого воркшопа — мы прогнали его шаг за шагом на двух реальных бизнес-датасетах против продакшн-движка: воронка продаж Maven Analytics CRM Sales Opportunities с 8 800 сделками и канонический датасет IBM Telco Customer Churn с 7 043 клиентами. Каждый эндпоинт на этой странице вернул реальный ответ на реальных данных — и вы можете скачать те же датасеты и воспроизвести каждое число ниже. Вот что получилось — и что это даёт бизнесу, который строит так.

Learn — воронка, ранжированная по риску, из записей, которые вы уже храните

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

Точность — не главное, главное — траектория. Точность по оттоку выросла с 0.75 до 0.80, когда обучающая история увеличилась с 1 000 до 3 000 клиентов. Модель становится умнее с каждым исходом, который фиксирует приложение. Для бизнеса: очередь сделок и список продлений превращаются в очередь, ранжированную по риску, вместо FIFO. Продавцы и retention-команды звонят сначала аккаунтам с наибольшей вероятностью оттока или закрытия — прямой выигрыш в конверсии и удержании, из состояния, которое уже существует, без ML-пайплайна, фиче-стора или сервиса эмбеддингов, которые надо строить и кормить.

Discover — правила, которым уже следуют ваши данные

Получив только сырые числа, /api/v2/discover/holo-formula восстановил закон, который действительно важен бизнесу: риск оттока затухает с длительностью жизни клиента, аппроксимированный логарифмической кривой с R² = 0.968. Риск пиковый в первые два года жизни клиента и спадает после. Для бизнеса: вкладывайтесь в онбординг и удержание в первый-второй год и перестаньте переплачивать позже. Тот же эндпоинт восстановил структуру ценообразования воронки (стоимость сделки ≈ прайс, R² = 0.996) — на живых данных это работает как непрерывная проверка целостности данных, которая сигнализирует, как только биллинг расходится с прайсом.

Reason, Solve, Optimize — решения, а не только дашборды

/api/reason корректно ответил на вопрос о риске оттока нового клиента с полным трейсом того, какие факторы повлияли (помесячный контракт, короткий срок жизни, отсутствие опции безопасности). /api/solve назначил четыре различных retention-предложения четырём высокорисковым клиентам без двойного бронирования. /api/graph_solve проложил маршрут полевой retention-команды через пять рисковых сегментов, а /api/v2/connectome/solve разделил retention-бюджет между тарифами контракта с точно проверенными ограничениями. Для бизнеса: аудируемые причины риска вместо чёрных ящиков, бесконфликтное назначение офферов, меньше миль и больше визитов в полевой день и доказуемо согласованное разделение бюджета — всё из одного тенанта.

Что это даёт бизнесу

Куда идти дальше

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

В этом практическое обещание Holo Engine: не отдельный AI-слой рядом с приложением, а приложение, чьё собственное состояние может обучаться, рассуждать, открывать законы и оптимизировать.

Начните маленьким. Постройте страницу клиента, складской экран, заявку на отпуск, очередь инвойсов или канбан-доску. Holo Engine даёт тому же состоянию приложения маршрут в поиск, структурные сигналы, предсказания, рассуждение и оптимизацию — без предварительного экспорта в отдельный стек интеллекта.