Нейросимволическая среда исполнения

1. Краткое изложение

OpenCradle движется от «on-premise платформы, которая запускает агентов» к контролируемому слою исполнения между вероятностными агентами и системами, на которые они могут повлиять.

Цикл:

• агенты порождают proposals — кандидатов в действия, планы и факты;
• среда оценивает эти proposals по типизированным контрактам;
• символьные правила (политики, права, доменные ограничения) определяют, что можно исполнить;
• инструменты исполняются и порождают observations;
• верификаторы определяют, действительно ли произошёл нужный переход состояния;
• всё записывается как evidence с указанием происхождения.

Всю конструкцию держат три разделения:

Proposal — не решение. Вывод инструмента — не проверенная истина. Успешное исполнение — не проверка результата.

Это не делает языковую модель детерминированной. Это делает последствия вывода языковой модели управляемыми явными и проверяемыми правилами.

Текущее состояние

Фазы 1-3 дорожной карты из §19 реализованы, плюс первый доменный пакет. Что есть в кодовой базе Cradle:

Чего пока нет: онтологии исполнения как словаря или графа (§9 и фаза 4 не тронуты); RDF, OWL и SHACL нигде (§8, фаза 6); формата манифеста доменного пакета и версионируемой поставки; отката в смысле восстановления снапшота — есть только компенсация через инструмент, который предоставил сам провайдер.

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

Существовавшая СУР управляет ответами людям. Добавленная среда управляет действиями над системами; пока это два несведённых механизма.

2. Постановка проблемы

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

• Вероятностный вывод. Один и тот же вход может дать разные действия.
• Промпт — не исполняемая политика. Инструкция в системном промпте — пожелание, которому модель может следовать; это не ограничение, которое накладывает система.
• Валидность схемы не равна валидности смысла. Идеально типизированный {"refund_amount": 480000} вполне может быть катастрофическим бизнес-решением.
• Скрытые побочные эффекты. Инструмент может писать больше, чем следует из его названия.
• Устаревшее состояние. Контекст, на котором агент строил рассуждение, мог перестать описывать мир к моменту исполнения.
• Неавторизованные действия. Идентичность, которая рассуждала, — не обязательно та, которой разрешено действовать.
• Неидемпотентные повторы. Повторённое «создать счёт» создаёт два счёта.
• Неверное прочтение результата. 200 OK — это не «произошло то, что я хотел».
• Отсутствие доказательств. Вывод без прослеживаемого источника невозможно ни проаудировать, ни оспорить.
• Нет проверки постусловий. Большинство агентных фреймворков останавливаются на «инструмент не бросил исключение», а это утверждение не о мире.

Логи это не решают. Лог говорит, что было вызвано. Он не говорит, было ли это разрешено и держится ли достигнутый эффект.

3. Принципы проектирования

1. Агент предлагает; среда располагает. Генерация и авторизация — разные подсистемы.
2. Никаких неконтролируемых побочных эффектов. Каждый эффект проходит через шлюз, знающий его класс риска.
3. Разделять рассуждение и авторизацию. Модель никогда не должна быть компонентом, который решает, что ей можно.
4. Проверять до исполнения. Структура, идентичность, политики, предусловия.
5. Проверять после исполнения. Независимо, по целевой системе.
6. Каждое значимое утверждение требует доказательства. Источник, время, актор.
7. Каждый переход состояния должен быть атрибутируем. К решению, а через него — к идентичности.
8. Доменные правила живут вне промптов. В коде, политиках или моделях ограничений — версионируемых и тестируемых.
9. Подтверждение человеком — полноценный объект среды, а не аварийный люк.
10. Неопределённость представлена явно. confidence, unknown, needs_clarification — легитимные значения.
11. У отказа больше одной формы. Reject, repair, retry, compensate, escalate.
12. Локальное развёртывание и семантическая безопасность — разные вещи. Работа на своём железе определяет, где лежат данные. Она ничего не говорит о том, было ли действие корректным и разрешённым.

4. Базовая модель среды

Целевая архитектура.

Agent · Task · Intent · Proposal · Plan · Action · Tool
Observation · Fact · Evidence
Policy · Permission · Constraint · Decision
Verification · StateTransition · HumanApproval · AuditEvent

Сущности

Agent — адресуемая единица рассуждения. Поля: id, role, skills, model_ref, permitted_scopes. Связи: порождает Proposals. Пример: агент triage-support на локальной модели 7B.

Task — единица работы с источником. Поля: id, origin, input_ref, status, deadline. Пример: входящее сообщение в Telegram.

Intent — нормализованная интерпретация того, что требуется. Поля: id, task_id, intent_type, slots, confidence. Пример: refund_request{order_id: "A-119", amount: null}.

Proposal — кандидат в действие от агента, явно вероятностный. Поля: id, task_id, agent_id, action, candidate_facts, evidence_refs, confidence, alternatives. Proposal никогда не исполняется сам по себе.

Plan — упорядоченный набор Proposals с зависимостями. Поля: id, steps, ordering_constraints, abort_policy.

Action — конкретная операция, которую запрашивает Proposal. Поля: action_type, target, arguments, side_effect_class, idempotency_key.

Tool — зарегистрированная возможность с объявленным контрактом. Поля: id, version, input_schema, output_schema, side_effect_class, required_scopes, supports_dry_run.

Observation — сырой вывод инструмента или внешней системы. Поля: id, execution_id, tool_id, raw_ref, observed_at, reported_side_effects. Observation — это данные, а не истина.

Fact — нормализованное утверждение, принятое системой. Поля: id, subject, predicate, object, source_ref, asserted_at, confidence, verification_status. Fact всегда атрибутируем.

Evidence — материал, подтверждающий Fact или Decision. Поля: id, kind (фрагмент документа, ответ API, скриншот, прогон тестов), content_ref, hash, collected_at, collector.

Policy — правило о том, что может произойти. Поля: id, version, scope, rule_ref, effect, obligations. Пример: «любое необратимое действие в production требует HumanApproval».

Permission — грант, связывающий идентичность с действиями над ресурсами. Поля: subject, action_type, resource_selector, conditions.

Constraint — доменный инвариант. Поля: id, domain_pack, expression, severity. Пример: «классификация ТН ВЭД должна ссылаться хотя бы на один действующий источник права».

Decision — вердикт среды по Proposal. Поля: id, proposal_id, verdict, reasons, policy_results, required_actions, decided_at, decided_by, policy_version. Decision — единственное, что авторизует исполнение.

Verification — проверка, что ожидаемое состояние достигнуто, выполненная независимо от инструмента, который это заявил. Поля: id, execution_id, checks, status, evidence_refs.

StateTransition — зафиксированное изменение ресурса. Поля: id, resource_ref, from_state, to_state, decision_id, verification_id, committed_at.

HumanApproval — акт авторизации человеком. См. §15.

AuditEvent — append-only запись обо всём значимом. Поля: id, kind, subject_ref, actor, at, payload_hash, prev_hash.

Различия, которые важны

5. Жизненный цикл исполнения

Целевая архитектура.

Приём входа
  → Нормализация контекста
  → Порождение proposal
  → Валидация схемы proposal
  → Разрешение идентичности и прав
  → Вычисление политик
  → Проверка доменных ограничений
  → Формирование решения об исполнении
  → Запрос подтверждения человека, когда требуется
  → Исполнение инструмента
  → Захват observation
  → Нормализация кандидатов в факты
  → Проверка семантической согласованности
  → Проверка постусловий
  → Фиксация перехода состояния
  → Публикация audit event
  → Возврат результата

Любой шаг может завершить прогон. Возможные исходы:

Таблицу ограничивают два правила: циклы repair должны быть ограничены (фиксированный бюджет попыток, после которого исход — escalate), и inconclusive — это не verified: он никогда не должен молча фиксировать изменение.

6. Архитектура двух шлюзов

Целевая архитектура.

Шлюз 1 — до исполнения

Работает после появления proposal и до того, как затронут любой инструмент.

class ExecutionProposal(BaseModel):
    agent_id: str
    task_id: str
    action_type: str
    target: ResourceRef
    arguments: dict
    evidence_refs: list[str]
    confidence: float | None
    idempotency_key: str

Проверки в порядке возрастания стоимости:

1. Структурная валидация — схема, обязательные поля, типы, диапазоны, перечисления.
2. Разрешение идентичности — какой субъект действует и от чьего имени.
3. Авторизация — есть ли у субъекта Permission на это действие над этим ресурсом.
4. Вычисление политик — правила организации и окружения.
5. Доменные предусловия — ограничения из активного domain pack.
6. Требования к доказательствам — нужны ли для этого класса действий доказательства, и присутствуют ли они, и свежи ли.
7. Требования к подтверждению — выводятся из уровня риска и класса побочного эффекта.
8. Классификация риска — существующая СУР L1/L2 Cradle, обобщённая с «риска ответа» до «риска действия».
9. Лимиты стоимости и частоты — на задачу, на агента, на арендатора, на окно.
10. Целевое окружение — входит ли production вообще в область этого прогона.
11. Идемпотентность — не порождал ли уже этот idempotency_key эффект.

На выходе — RuntimeDecision, а не булево значение.

Шлюз 2 — после исполнения

Работает после возврата инструмента и до фиксации перехода.

1. Схема вывода инструмента — соответствует ли результат объявленному контракту.
2. Существование ожидаемого ресурса — то, что должно теперь существовать, существует.
3. Ожидаемое состояние — ресурс в том состоянии, которое запрашивало действие.
4. Доменные инварианты — доменная модель осталась внутренне согласованной.
5. Отсутствие запрещённых эффектов — ничего за пределами объявленного радиуса не изменилось.
6. Свежесть observation — проверяющее чтение достаточно свежее, чтобы иметь смысл.
7. Полнота доказательств — утверждение подкреплено.
8. Постусловия — формальные условия, привязанные к действию, выполняются.
9. Доступность компенсации — если верификация провалилась, есть ли путь назад.

Критично: верификатор должен читать из независимого источника везде, где это возможно, — не тем же вызовом, который выполнил запись.

Именно поэтому архитектура предпочитает, в порядке приоритета:

dry run → prepare / commit → транзакция → staged write → ключ идемпотентности → обратимое действие → компенсация → подтверждение до commit.

«Чистый инструмент без побочных эффектов» — полезный идеал. Реальные интеграции — платёжные провайдеры, почта, деплои, сторонние API — часто не могут его обеспечить. Архитектура должна быть честна об этом, а не отмахиваться.

7. Символьный слой

Целевая архитектура. Символьный слой намеренно множественен. Это не одна технология.

Схемы

Pydantic, JSON Schema, типы TypeScript, Zod, типизированные доменные модели. Они отвечают на вопрос «корректно ли это сформировано?», но не на вопрос «верно ли это?».

Движок политик

Авторизация, политики организации, правила окружения, разрешения на действия, контроль бюджета и риска. Кандидаты: Open Policy Agent, Cedar, JSON Logic или небольшой декларативный формат политик внутри Cradle. Технологию нельзя выбирать до аудита текущего стека — Cradle написан на TypeScript/Node, что делает встраиваемый вычислитель привлекательнее отдельного сайдкара.

Онтология и граф знаний

RDF/RDFS, OWL, SHACL, property graph или обычное реляционное моделирование. Различия:

• онтология определяет классы, отношения и ограничения;
• граф знаний хранит конкретные сущности и их связи;
• ризонер выводит следствия и находит противоречия;
• движок валидации проверяет соответствие данных формам.

Это четыре разные задачи. Их смешение — самый частый способ провалить проект с онтологией.

Доменные валидаторы

Обычный код остаётся легитимным и часто оказывается правильным ответом: расчёт налогов, алгоритмы классификации ТН ВЭД, пороговые правила, арифметика дат, запросы во внешние органы, транзакционные инварианты. Не нужно пытаться выразить всё аксиомами.

8. OWL, RDFS и SHACL — прагматично

RDF представляет знание тройками: subject → predicate → object.

RDFS задаёт базовый словарь: классы, подклассы, свойства, domain, range.

OWL добавляет логические аксиомы: непересекающиеся классы, кардинальность, эквивалентность, обратные / транзитивные / симметричные / асимметричные / функциональные свойства.

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

Ограничение, которое формирует наш дизайн:

Операционная бизнес-логика почти всегда закрытомирна: если разрешения нет в системе, действие не проходит. Поэтому OWL не следует представлять как универсальный business rule engine. Для операционной валидации практичнее SHACL, движок политик, ограничения БД и валидаторы приложения. OWL стоит оставить для того, в чём он действительно хорош: классификация, отношения подчинения, проверка непротиворечивости выверенного словаря.

9. Универсальная онтология исполнения

Целевая архитектура. Собственный словарь Cradle — независимый от предметной области, описывающий само исполнение агента.

Agent          proposes        Proposal
Proposal       contains        Action
Action         targets         Resource
Action         invokes         Tool
Action         requires        Permission
Action         isGovernedBy    Policy
Policy         evaluates       Context
Tool           produces        Observation
Observation    supports        Fact
Fact           isSupportedBy   Evidence
Decision       evaluates       Proposal
Verification   checks          StateTransition
StateTransition changes        ResourceState
HumanApproval  authorizes      Decision
AuditEvent     records         RuntimeEvent

Ограничения над этим словарём:

• каждое исполненное Action должно ссылаться на Decision с вердиктом allow;
• высокорисковые и необратимые Actions должны ссылаться на HumanApproval;
• каждый зафиксированный StateTransition должен ссылаться на Verification;
• каждый проверенный Fact должен ссылаться на Evidence или доверенный источник;
• Observation никогда нельзя трактовать как проверенный Fact;
• отклонённые Proposals не должны доходить до исполнения;
• исполняющая идентичность должна совпадать с идентичностью, авторизованной решением;
• повторное исполнение с тем же idempotency_key не должно дублировать эффекты.

Обратите внимание: эти ограничения проверяемы без всякого RDF. Это правила целостности над записями среды. Графовое представление — один из возможных способов реализации, а не предпосылка.

10. Domain packs

Целевая архитектура. Онтология исполнения универсальна. Доменное знание подключается поверх.

domain-pack/
  manifest.yaml
  ontology/
  schemas/
  policies/
  validators/
  tools/
  verifiers/
  examples/
  tests/

id: customs.hs-router
name: Customs and HS Classification
version: 0.1.0
entities:
  - Product
  - HSCode
  - RegulatoryRule
  - Permit
  - Authority
  - LegalSource
policies:
  - source-priority
  - restricted-goods-routing
  - missing-attribute-escalation
verifiers:
  - hs-code-exists
  - legal-source-current
  - required-permit-resolution

Пакет версионируется, тестируется изолированно, и каждое Decision фиксирует, на какой версии пакета оно принято.

Кандидаты: таможня и торговля (товары, коды ТН ВЭД, правила классификации, разрешения, ограничения, органы, источники права), инфраструктура и качество ПО (сервисы, инциденты, деплои, коммиты, окружения, тесты, согласования, правила отката), здравоохранение (пациенты, наблюдения, клинические действия, противопоказания, роли, согласие, эскалация).

11. Разбор примера — HS Router

1. OCR извлекает описание товара из отгрузочного документа.
2. LLM нормализует его в структурированные характеристики товара.
3. Характеристики становятся кандидатами в факты, каждый со ссылкой на источник.
4. Генератор кандидатов предлагает несколько кодов ТН ВЭД.
5. Правила классификации (обычный код) проверяют различающие признаки.
6. Если обязательных характеристик не хватает, Decision получает статус needs_clarification — а не догадку.
7. Источники права проверяются по приоритету и на актуальность.
8. Разрешения и ограничения выводятся из регуляторной модели.
9. Итоговое Decision несёт доказательства и происхождение.
10. LLM пишет человекочитаемое объяснение — и не может изменить формальное решение.

{
  "proposal": {
    "product_type": "unmanned_aerial_vehicle",
    "candidate_hs_codes": ["8806.21", "8806.22"],
    "confidence": 0.78
  },
  "decision": {
    "status": "needs_clarification",
    "missing_facts": [
      "maximum_takeoff_weight",
      "maximum_range"
    ],
    "permitted_to_finalize": false
  }
}

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

12. Разбор примера — UptimeHarbor

1. Мониторинг фиксирует отказ.
2. Агент предлагает диагноз.
3. Агент предлагает изменение кода или инфраструктуры.
4. Шлюз 1 проверяет репозиторий, целевое окружение и права.
5. Изменение прогоняется в изолированном окружении.
6. Тесты и браузерные проверки порождают observations.
7. Верификатор проверяет, решён ли исходный инцидент.
8. Деплой в production требует явного решения политики и, если настроено, подтверждения человека.
9. Пост-деплой верификация проверяет здоровье сервиса и поведение для пользователя.
10. Провал верификации запускает откат или эскалацию.

Формальные правила, отличающие это от CI-пайплайна с прикрученной LLM:

• прохождение тестов ≠ решение инцидента;
• верификация на staging не авторизует деплой в production;
• production не должен работать на непроверенном коммите;
• результат деплоя должен проверяться из независимого источника;
• один инцидент не должен порождать дублирующие конфликтующие исправления.

13. Модель побочных эффектов

Целевая архитектура. Каждый Tool объявляет side_effect_class, и класс определяет требуемый контроль.

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

14. Доверие и происхождение

Каждый значимый результат несёт:

source · actor · timestamp · model и версия · tool и версия · версия policy · версия ontology / domain-pack · хеш входа · хеш выхода · evidence_refs · verification_status · confidence, где осмысленно

Аудит-леджер должен быть append-only или иным образом защищён от незаметного изменения — хеш-цепочка (prev_hash на каждое событие) остаётся самым дешёвым правдоподобным механизмом и работает на существующем хранилище SQLite.

Поля версий — не бюрократия. Когда политика меняется, вы всё равно должны быть способны объяснить решение, принятое в прошлом квартале, по действовавшим тогда правилам.

15. Human-in-the-loop

Человек — не запасной вариант на случай отказа машины. Подтверждение является объектом среды со своим жизненным циклом.

{
  "approval_id": "approval_123",
  "decision_id": "decision_456",
  "approver_id": "user_789",
  "scope": "production_deployment",
  "status": "approved",
  "expires_at": "2026-08-01T12:00:00Z"
}

Поддерживаемые формы: approve · reject · request changes · approve once · approve within scope · approve until expiration.

Существующий operator inbox Cradle — зародыш этого. Работа состоит в обобщении его от «подтвердить ответ» к «подтвердить Decision» и в явном задании области действия и срока.

16. Предлагаемая архитектура компонентов

Целевая архитектура — логические компоненты. На раннем этапе это модули одного приложения, а не микросервисы.

• Agent Gateway — точка входа для прогонов агентов
• Context Resolver — сборка контекста с отметкой свежести
• Proposal Service — создание и хранение Proposals
• Schema Validator — структурная валидация
• Identity and Permission Resolver — кто действует и от чьего имени
• Policy Engine — вычисление политик по контексту
• Domain Constraint Engine — подключаемо: валидаторы, SHACL, ризонеры
• Ontology Registry — версии словаря
• Domain Pack Registry — обнаружение, загрузка, версионирование пакетов
• Tool Gateway — единственная точка прохода для всех побочных эффектов
• Execution Sandbox — изолированное исполнение рискованных действий
• Observation Store — сырой вывод инструментов
• Evidence Store — контент-адресуемые артефакты
• Verification Engine — проверки постусловий
• State Transition Manager — commit / abort
• Approval Service — подтверждения человеком
• Audit Ledger — append-only журнал событий
• Repair Loop — ограниченные циклы исправления
• Runtime API and SDK — публичный контракт

Самый ценный из них — Tool Gateway. Без единой точки прохода для побочных эффектов все остальные гарантии носят рекомендательный характер.

17. Предлагаемые API

Показаны на Python для читаемости; Cradle написан на TypeScript, поэтому реальные контракты были бы схемами Zod плюс выводимыми типами, по соглашениям существующей кодовой базы.

class Proposal(BaseModel):
    id: str
    task_id: str
    agent_id: str
    action: ActionRequest
    facts: list[CandidateFact]
    evidence_refs: list[str]
    confidence: float | None

class RuntimeDecision(BaseModel):
    proposal_id: str
    verdict: Literal["allow", "deny", "repair", "clarify", "require_approval"]
    reasons: list[str]
    policy_results: list[PolicyResult]
    required_actions: list[str]

class ExecutionObservation(BaseModel):
    execution_id: str
    tool_id: str
    raw_result_ref: str
    observed_at: datetime
    side_effects: list[ObservedSideEffect]

class VerificationResult(BaseModel):
    execution_id: str
    status: Literal["verified", "failed", "inconclusive"]
    checks: list[VerificationCheck]
    evidence_refs: list[str]

18. Соображения по хранению

Одного хранилища не хватит. Разделять по задачам:

Четыре вещи стоит проговорить прямо:

• векторная база — не онтология;
• граф знаний — не замена транзакционному хранилищу;
• ризонер OWL — не движок авторизации;
• RAG — не верификация.

19. Дорожная карта реализации

Фаза 1 — типизированные контракты исполнения. ✅ Реализовано. Proposal, Decision, Observation, Verification как реальные сохраняемые сущности. Валидация схем. Явные пред- и постусловия у действий. Audit events.

Фаза 2 — tool gateway под управлением политик. ✅ Реализовано. Централизованный вызов инструментов, права, уровни риска, ключи идемпотентности, правила подтверждения, поддержка dry-run.

Фаза 3 — среда верификации. ✅ Реализовано, с пустым реестром верификаторов. Независимые проверки постусловий, захват доказательств, обработка отказов, хуки компенсации. Откат — только через компенсацию.

Фаза 4 — онтология исполнения. Не начата. Базовый словарь, манифест domain pack, версионирование, отображение объектов среды в графовые сущности. Реестр доменных пакетов в коде есть, но формата манифеста и словаря — нет.

Фаза 5 — первый domain pack. Частично реализована, раньше фазы 4. Пилот — HS Router: пакет оценивает provisions и exemptions ЕАЭС в трёхзначной логике против известных характеристик товара, поэтому нехватка характеристики становится явным вопросом, а не молчаливым решением (§11). Он оборачивает существующий сервис HS Codes Router, эндпоинты которого зарегистрированы как read_only-инструменты. Не хватает: собственно словаря сущностей и упаковки.

Фаза 6 — опциональный семантический вывод. Не начата. RDF/RDFS, валидация SHACL, OWL там, где ограничения действительно ему подходят, графовые запросы по происхождению.

20. Риски и non-goals

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

Non-goals:

• сделать языковую модель детерминированной;
• закодировать всё знание в OWL;
• заменить код приложения онтологией;
• автоматически одобрять любое действие агента;
• доказать корректность поведения внешней системы там, где независимая верификация недоступна;
• считать локальное развёртывание достаточной мерой безопасности.

21. Открытые вопросы

• Какова текущая внутренняя абстракция инструментов и может ли MCP служить единым Tool Gateway?
• Где должно выполняться вычисление политик — в процессе или отдельным сервисом?
• Какие объекты среды уже есть в схеме Drizzle, а под какие нужны новые таблицы?
• Как сегодня сохраняются прогоны агентов и достаточно ли этой записи для аудита?
• Обобщается ли существующий operator inbox в Approval Service?
• Как версионировать и доставлять domain packs в on-premise установки?
• Каким операциям нужны сильные транзакции, а не компенсация?
• Какие факты требуют внешней верификации и в каких органах?
• Важна ли RDF-совместимость для первого заказчика или это чисто архитектурный вкус?
• Стоит ли реализовать первый граф реляционно?
• Что идёт пилотом первым — HS Router или UptimeHarbor?
• Какие текущие системные промпты содержат бизнес-правила, которым место в коде или политиках?

22. Минимальная первая реализация

Один вертикальный срез, реализуемый без RDF, OWL и графового хранилища:

Вызов инструмента под управлением политик с проверкой постусловий.

1. Агент предлагает действие.
2. Вход валидируется по типизированному контракту.
3. Движок политик возвращает allow или deny.
4. Инструмент исполняется через централизованный шлюз.
5. Верификатор независимо читает целевую систему.
6. Среда сохраняет Proposal, Decision, Observation, Verification и AuditEvent.
7. Провал верификации возвращается как отказ, даже если сам инструмент отчитался об успехе.

Пункт 7 — весь тезис в одной строке. Всё остальное — domain packs, онтологии, семантический вывод — расширение цикла, который сначала должен заработать в простейшей форме.

Agent Proposal
      ↓
Typed Contract
      ↓
Policy Decision
      ↓
Controlled Tool Gateway
      ↓
Observation
      ↓
Independent Verification
      ↓
Verified State Transition

23. Соседние системы

Текущее состояние. С чем Cradle сравнивают и о чём сравнение на самом деле. Единица сравнения — механизм, а не продукт.

LangGraph — не конкурент

LangGraph — это то, что у покупателя уже стоит. Cradle встаёт под ним, между графом и инструментами. Его human-in-the-loop настоящий: interrupt() останавливает исполнение на вызове инструмента, состояние графа переживает паузу через persistence layer, человек одобряет, правит аргументы или отклоняет.

Чего в его документации нет: границ этого одобрения, срока действия, гарантии однократности, запрета самоодобрения и журнала, устойчивого к правке.

Одной строкой: LangGraph отвечает на вопрос «как агент шёл». Cradle отвечает на вопрос «почему ему было можно».

Настоящий сосед — AWS Dogwood

Dogwood, открытый под Apache 2.0 в августе 2026, расширяет Cedar на последовательности вызовов инструментов и поддержан в Amazon Bedrock AgentCore Policy. Он делает то же, что Cradle: детерминированный слой вне модели, где предложенный вызов принимается или отклоняется до исполнения.

AWS сам называет свои ограничения, и они проводят границу:

Следствие: работа на своём железе — не второстепенное удобство. Это линия раздела с ближайшим соседом.

Что сравнению не подлежит

Векторная база — не онтология. Граф знаний не заменяет транзакционное хранилище. OWL-ризонер — не движок авторизации. RAG — не верификация.