Глава 17. Слой политик и каталог возможностей¶

1. Почему без слоя политик эталонная среда исполнения остается слишком наивной¶

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

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

В нашем сквозном сценарии разбора обращений поддержки это проявляется сразу после главы 16. Среда исполнения уже умеет принять запрос, собрать контекст, вызвать модель и дойти до шлюза. Но в момент, когда агент собирается открыть срочный тикет, записать сводку в память или запросить еще один внешний шаг, системе нужен не просто цикл, а явное решение о допустимости и риске.

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

Поэтому следующий обязательный слой эталонной реализации — слой политик.

Его задача не в том, чтобы “тормозить систему”. Его задача в том, чтобы решения про доступ, риск и допустимость не были размазаны по случайным if в коде.

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

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

2. Слой политик должен отвечать на маленькие и понятные вопросы¶

Слабый слой политик пытается быть “умным мозгом системы”. Сильный слой политик делает наоборот: он решает ограниченный набор ясных вопросов.

Например:

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

Когда эти вопросы оформлены явно, среда исполнения становится объяснимее, а изменения в ограничителях перестают быть хаотичными.

3. Каталог возможностей нужен не как реестр имен, а как контрактный слой¶

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

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

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

flowchart LR
    A["Запрос запуска"] --> B["Оркестратор среды исполнения"]
    B --> C["Слой политик"]
    B --> D["Каталог возможностей"]
    C --> E["Разрешить / запретить / запросить подтверждение"]
    D --> F["Контракт возможности"]
    E --> G["Слой исполнения"]
    F --> G

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

4. Поверхность инструментов это не то же самое, что управляемая поверхность возможностей¶

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

Это различие важно.

Слабая реализация говорит так:

• вот список инструментов, которые модель может вызывать.

Более сильная реализация говорит так:

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

Именно поэтому каталог возможностей должен стоять выше сырых определений инструментов. Он не дает рантайму перепутать:

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

5. Что полезно хранить в каталоге возможностей¶

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

Из-за этого зрелый каталог часто полезно дополнить такими полями:

• режим сессии возможности: stateless / stateful;
• допускаются ли промежуточные запросы данных;
• испускаются ли события хода выполнения;
• как ведет себя истечение сессии;
• требует ли продолжение нового подтверждения или может идти под уже выданным решением;
• можно ли возможность автоматически повторно инициализировать удаленную сессию.

Без этих полей слой политик может формально разрешить возможность, но не суметь нормально управлять тем, как ее живая сессия среды исполнения ведет себя на практике.

Таксономия схем рабочих процессов у Anthropic добавляет сюда еще одно недостающее измерение управления.¹ Слой политик должен решать не только то, разрешена ли возможность сама по себе. Он еще должен решать, в каких схемах оркестрации ее вообще допустимо вызывать.

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

Например, контракт политики может требовать явного ответа на то, что возможность:

• безопасна внутри prompt chaining, но не внутри неограниченного цикла;
• допустима в routing только для некоторых классов запросов;
• может использоваться в parallelization только если ветки работают только на чтение;
• доступна делегированным рабочим агентам в orchestrator-workers или остается только у родительского рантайма.

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

Практически полезный набор полей обычно такой:

• имя возможности;
• владелец;
• mode: read / write / high_risk;
• transport: mcp / gateway / sandboxed_exec;
• exposure: direct / brokered / restricted;
• входная схема;
• формат выхода;
• требования к подтверждению;
• требования к идемпотентности;
• значения timeout и retry по умолчанию.

С таким контрактом рантайм уже может вести себя предсказуемо, а не подстраиваться под каждую возможность на ходу.

5.1. Политика выбирает не только инструмент, но и руки¶

После разделения brain / hands / session слой политик получает еще одну обязанность: он должен решать не только, разрешена ли capability, но и какими hands ее можно исполнить.⁸

Один и тот же logical action может иметь разные профили:

• read-only через brokered internal gateway;
• запись через high-risk tool с approval и idempotency key;
• shell-like operation только в ephemeral sandbox без внешнего egress;
• delegated subagent execution без наследования секретов по умолчанию.

Поэтому capability catalog полезно расширять полями execution_profile, sandbox_profile_id, egress_profile, credential_scope, debug_surface и rollback_boundary. Тогда policy decision становится не просто allow, а маршрутом: какой harness может продолжить работу, какие hands доступны, какая session evidence должна быть записана и где проходит blast-radius boundary.

5.2. Аналитический агент это governed query engine, а не свободный SQL-автопилот¶

Отдельно стоит выделить класс возможностей, который часто выглядит безобидно, потому что “только читает данные”: аналитический агент, который отвечает на бизнес-вопросы, строит SQL, выбирает метрики или работает поверх semantic layer. На практике это не просто query_database. Это управляемый query engine с контрактом на смысл метрик, область данных, допустимые агрегации, стоимость запроса и видимость результата.

Современные аналитические платформы уже двигаются в эту сторону. Snowflake Cortex Analyst опирается на semantic views, verified query suggestions, роли доступа и выполнение сгенерированного SQL внутри governance boundary Snowflake.⁹ Databricks Genie Spaces строят разговорный аналитический опыт вокруг trusted assets и инструкций пространства, а Power BI Copilot работает поверх semantic model и существующих разрешений рабочей области.¹⁰¹¹

Для книги важен не vendor-specific продукт, а архитектурный вывод: аналитический агент должен попадать в capability catalog как analytics_query, metric_explain или semantic_model_lookup, а не как универсальная SQL-рука. Его контракт должен фиксировать:

• semantic_model_id или набор разрешенных semantic views;
• dataset_scope и tenant boundary;
• разрешенные метрики, dimensions и grain;
• можно ли генерировать raw SQL или только parameterized query plan;
• максимальную стоимость, лимит строк и timeout;
• правила маскирования, suppressed columns и small-cell suppression;
• требуется ли human review для новых метрик, cross-domain joins или export наружу;
• какие query plan, generated SQL, source tables и policy decision попадут в trace.

Иначе система легко получит “read-only” агент, который фактически может раскрывать чувствительные срезы, соединять домены без владельца, выдавать неутвержденные KPI или запускать дорогие запросы. Зрелый слой политик должен уметь сказать не только “можно читать warehouse”, а “можно ответить на этот аналитический вопрос через этот semantic model, с этой ролью, этими лимитами и этой доказательной записью”.

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

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

Именно такая форма нужна и системам агентов с сильным слоем политик.

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

• поставить запуск на паузу;
• показать ожидающее действие и его контекст;
• дождаться внешнего решения;
• продолжить выполнение со структурированным результатом.

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

Полезно сразу различать две схемы подтверждения:

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

Второй путь не надо воспринимать как “подтверждение убрали”. Его лучше мыслить как делегированный контроль с более жесткими требованиями к доказательствам:

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

7. Решение политики должно быть объектом, а не просто логическим значением¶

Очень полезная инженерная привычка: решение политики не должно сводиться к True/False.

Чаще полезнее возвращать что-то вроде:

• allow
• deny
• approval_required
• sanitize_and_continue
• escalate

И дополнительно:

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

Это резко повышает объяснимость и делает телеметрию намного полезнее.

7.1. Политика должна управлять не только разрешением, но и реакцией контроля¶

DeepMind AI Control Roadmap полезно формулирует еще одну обязанность слоя политик: control system должна не только сказать, можно ли действие, но и выбрать режим реакции.⁵ В их модели контроль строится поверх threat model, мониторинга agent actions/plans, supervisor-систем, prevention/response gates и метрик coverage, recall и time-to-response.

Для эталонного runtime это означает, что policy decision должен уметь возвращать не только allow или deny, но и control response:

• allow_with_monitoring для низкорисковых и обратимых действий;
• pause_for_supervisor для действий, где нужен human или classifier-mediated review;
• block_synchronously для высокорисковых действий до внешнего мира;
• quarantine_session для поведения, которое похоже на misinterpretation, overeagerness или попытку обойти границы;
• escalate_incident для событий, где контроль уже обнаружил возможный ущерб.

Это важная граница: не всякая опасность выглядит как adversarial misuse. Иногда агент просто слишком рьяно оптимизирует локальную цель, неправильно понял задачу или продолжает путь, который продуктово выглядит полезным, но системно разрушителен. Поэтому слой политик должен связывать решение с реакцией, ответственным владельцем, доказательствами, expected response time и audit trail.

AWS AgentCore Gateway показывает практический вариант такого слоя вокруг MCP tools: policy и Lambda interceptors стоят вне model loop, поэтому control path не зависит от того, как агент объясняет свой следующий вызов.⁶ Policy на Cedar дает deterministic allow/deny decision по principal, action, resource и context, а request/response interceptors закрывают динамическую часть: проверку bearer token, act-on-behalf token exchange, context injection, tool authorization, payload transformation и response filtering. Для эталонного runtime это полезная подсказка: tool call должен проходить через pre-call decision point, downstream call и post-call response filter, а trace должен хранить policy decision, denial reason, sanitized request/response, interceptor version и audit event.

8. Пример контракта политики¶

Ниже очень простой, но практичный шаблон:

policy:
  run_precheck:
    require_tenant: true
    deny_if_principal_missing: true
  capabilities:
    search_docs:
      decision: allow
    create_ticket:
      decision: approval_required
      approver: manager
    run_shell:
      decision: deny
  memory_write:
    allow_kinds:
      - validated_fact
      - session_summary

Его сила не в полноте, а в явности. Ты можешь спорить с конкретным правилом и понимать, где оно применяется.

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

9. Пример контракта каталога возможностей¶

Каталог полезно мыслить примерно так:

capabilities:
  search_docs:
    owner: knowledge_platform
    mode: read
    transport: mcp
    exposure: direct
    timeout_seconds: 5
    approval: none
  create_ticket:
    owner: support_platform
    mode: write
    transport: gateway
    exposure: brokered
    timeout_seconds: 15
    approval: manager
    idempotency_key_required: true
  run_shell:
    owner: platform_runtime
    mode: high_risk
    transport: sandboxed_exec
    exposure: restricted
    timeout_seconds: 10
    approval: always

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

10. Структурированные ответы важны потому, что контракты должны переживать встречу с кодом¶

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

Именно поэтому артефакты политик все чаще стоит делать структурно явными по таким полям, как:

• capability_session_id;
• capability_session_mode;
• resume_policy;
• on_session_expiry;
• progress_event_policy;
• elicitation_policy.

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

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

• approval_mode
• approval_delegate
• classifier_verdict
• escalate_to_human_if
• subagent_handoff_policy

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

Та же дисциплина нужна и для делегированных рабочих агентов. Если рантайм поддерживает путь orchestrator-workers, слой политик должен уметь явно сказать:

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

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

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

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

Эталонный рантайм теперь несет эти предположения прямо в артефактах исполнения: run_start, approval_requested, tool_execution, run_complete, записи подтверждений и экспорт сессии могут сохранять один и тот же контекст делегированной авторизации. Это важно, потому что поэтапный выпуск и расследование не должны восстанавливать делегированную идентичность по побочным следам.

Свежий материал OpenAI по структурированным ответам полезен и для слоя политик.⁴

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

Поэтому системам с сильным слоем политик полезно делать структурно явными такие артефакты:

• решения политик;
• запросы подтверждения;
• результаты подтверждений;
• входы и выходы возможностей.

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

11. Простой кодовый каркас решения политики¶

Ниже каркас, который показывает, что рантайм получает не просто разрешение, а структурированное решение.

from dataclasses import dataclass


@dataclass
class PolicyDecision:
    action: str
    reason: str
    policy_id: str
    approval_mode: str = "human"
    escalate_to_human: bool = False
    requires_approval: bool = False


def evaluate_capability(name: str) -> PolicyDecision:
    if name == "search_docs":
        return PolicyDecision(action="allow", reason="low_risk_read", policy_id="cap_001")
    if name == "create_ticket":
        return PolicyDecision(action="approval_required", reason="write_action", policy_id="cap_014", requires_approval=True)
    return PolicyDecision(action="deny", reason="unsupported_capability", policy_id="cap_999")

Даже такой простой код уже задает правильную форму для телеметрии, потоков подтверждения в интерфейсе и расследований.

12. Простой кодовый каркас поиска возможности¶

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

from dataclasses import dataclass


@dataclass
class CapabilitySpec:
    name: str
    mode: str
    transport: str
    exposure: str
    timeout_seconds: int


def get_capability(name: str) -> CapabilitySpec | None:
    registry = {
        "search_docs": CapabilitySpec("search_docs", "read", "mcp", "direct", 5),
        "create_ticket": CapabilitySpec("create_ticket", "write", "gateway", "brokered", 15),
    }
    return registry.get(name)

Это скучный слой. И это хорошо. Слой каталога как раз и должен быть стабильным и обозримым.

13. Частые ошибки¶

Проблемы здесь очень типовые:

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

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

14. Быстрый тест зрелости для слоя политик и каталога возможностей¶

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

Более сильная планка такая:

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

Если большинство этих условий не выполняется, рантайм уже может существовать, но контрактное ядро системы пока не собрано.

14.1. Практикум: связать capability contract с SLO, eval gate и golden path¶

Каталог возможностей становится по-настоящему полезным только тогда, когда он перестает быть перечнем инструментов и начинает связывать разные управленческие плоскости системы. Взрослый контракт возможности должен отвечать не только на вопрос “как вызвать действие”, но и на вопросы “кто отвечает за это действие”, “какое качество мы обещаем”, “какая оценка допускает его к выпуску”, “какие трассы доказывают корректность” и “при каких условиях волна должна быть остановлена”.

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

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

capability_release_contract:
  capability_name: support.order.create_ticket
  capability_version: 2026-06-01
  owner_team: customer_ops_platform
  business_owner: support_operations
  risk_tier: medium
  tool_principal: agent_support_ticket_writer
  allowed_rollout_waves:
    - internal_shadow
    - operator_assisted
    - limited_customer_beta
  required_policy_decisions:
    precheck:
      policy: support_request_scope_policy
      required_verdict: allow
    tool_use:
      policy: support_ticket_write_policy
      required_verdicts:
        - allow
        - require_confirmation
    data_access:
      policy: customer_data_minimization_policy
      required_verdict: allow_with_constraints
  required_trace_events:
    - run_start
    - policy_precheck
    - capability_selected
    - tool_policy_decision
    - tool_execution
    - verification_result
    - run_complete
  slo_bindings:
    availability: slo.support.ticket_creation.availability
    correctness: slo.support.ticket_creation.correctness
    latency: slo.support.ticket_creation.latency
    human_review_queue: slo.support.confirmation_queue.age
  eval_gates:
    before_internal_shadow:
      suite: eval.support.ticket_creation.regression
      required_pass_rate: 0.98
      required_zero_critical_failures: true
    before_operator_assisted:
      suite: eval.support.ticket_creation.policy_edges
      required_pass_rate: 0.99
      required_zero_critical_failures: true
    before_customer_beta:
      suite: eval.support.ticket_creation.production_replay
      required_pass_rate: 0.995
      required_zero_critical_failures: true
  golden_path_requirements:
    must_support_pause_and_resume: true
    must_have_idempotency_key: true
    must_have_unknown_result_path: true
    must_have_operator_visible_summary: true
  rollout_blockers:
    - missing_policy_bundle_version
    - missing_idempotency_key
    - unknown_tool_principal
    - verification_result_absent
    - confirmation_queue_age_slo_breached
    - critical_eval_regression

В этой записи нет ничего магического. Ее сила в том, что она делает разрыв между архитектурой, эксплуатацией и выпуском видимым. Если support.order.create_ticket проходит через каталог, но не имеет slo_bindings, команда не сможет честно сказать, какое качество она обещает. Если нет eval_gates, способность к выпуску будет оцениваться по впечатлению. Если отсутствует required_trace_events, расследование начнется уже после инцидента. Если не задан tool_principal, контроль доступа будет зависеть от инфраструктурной случайности.

Для читателя технической книги важно показать, как такая запись используется в процессе, а не только как она выглядит. Хороший путь внедрения состоит из четырех шагов.

Первый шаг — привязать capability к золотому пути. Возможность не должна быть “доступной вообще”. Она должна быть доступной в конкретных сценариях, ролях и волнах. Если одна и та же возможность используется в разных путях, это не проблема, но каждое использование должно иметь свою выпускную рамку. Создание тикета в сценарии поддержки и создание тикета в сценарии внутренней эскалации могут иметь один адаптер, но разные политики, разные SLO и разные условия подтверждения.

Второй шаг — сделать SLO частью контракта, а не внешним dashboard. SLO полезен только тогда, когда рантайм знает, какие события питают его измерение. Например, задержка создания тикета может считаться от tool_policy_decision до verification_result, а возраст очереди подтверждений — от approval_requested до approval_resolved. Если это не зафиксировано, разные команды будут считать разные интервалы и спорить уже во время инцидента.

Третий шаг — связать eval gate с конкретным переходом волны. Одна оценка может быть достаточной для внутренней тени, но недостаточной для customer beta. Внутренняя тень проверяет, что трассы собираются и политика не ломает штатный путь. Операторская волна добавляет подтверждение и качество объяснения. Ограниченная клиентская волна требует production replay, отсутствие критических регрессий и понятный путь неизвестного результата. Это разные вопросы, и их нельзя закрывать одной общей фразой “evals passed”.

Четвертый шаг — сделать блокировщики машинно проверяемыми настолько, насколько возможно. Не все можно автоматизировать сразу, но признаки вроде отсутствующего idempotency_key, неизвестного tool_principal, пустого verification_result или неверной версии policy bundle не должны зависеть от ручного чтения логов. Они должны становиться красным сигналом еще до расширения волны.

Полезно также добавить короткую матрицу владения:

Такая матрица не заменяет ответственность, а убирает двусмысленность. Если capability меняет риск, меняется не только строка в каталоге. Должны измениться eval gate, условия волны, ожидания по SLO и, возможно, путь подтверждения. Если это не происходит, каталог начинает врать.

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

• В каких golden path она разрешена?
• Какой policy bundle принял последнее решение о ее использовании?
• Какие SLO она питает или может нарушить?
• Какая eval suite блокирует ее следующий выпускной переход?
• Какой rollback или containment playbook используется, если результат неизвестен?

Если ответы разбросаны по людям, чатам и dashboard, слой возможностей еще не стал контрактным. Он только называется каталогом.

15. Что сделать сразу¶

Сначала пройди по короткому списку и отдельно отметь все ответы «нет»:

• Есть ли у тебя отдельный слой политик, а не набор if по коду?
• Возвращает ли политика структурированное решение?
• Есть ли единый каталог возможностей?
• Есть ли у возможностей владелец, транспорт, экспозиция и семантика риска?
• Использует ли рантайм каталог, а не прямые вызовы?
• Может ли подтверждение явно поставить запуск на паузу и продолжить его?
• Видны ли решения политик в телеметрии?

Если на несколько вопросов подряд ответ “нет”, каркас у тебя уже есть, но контрактное ядро пока еще не собрано.

16. Что делать дальше¶

Сначала сделай решения политик и контракты возможностей явными, а потом проверь, готова ли эта же система к первому поэтапному выпуску.

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

• Глава 16. Базовая схема среды исполнения
• Глава 18. Чеклист промышленного запуска
• Часть VII. Эталонная реализация
• Источники

17. Полезные справочные страницы¶

• Схема набора политик и контракта подтверждения
• Схема артефактов жизненного цикла
• Эталонный пакет

Эта глава служит контрактным шарниром для всего кластера управления средой исполнения. Дальше полезнее всего идти в главу 18 за шлюзами поэтапного выпуска и в главу 21 за реагированием контура заверения, построенным на тех же путях подтверждений и политик.

• Глава 16. Базовая схема среды исполнения
• Глава 18. Чеклист промышленного запуска
• Часть VII. Эталонная реализация
• Источники