Модуль XV — интеграции вывода и уведомления

Модуль XV — это маршрутизатор уведомлений control plane: когда любой модуль превращает оповещение в finding на шине событий, этот модуль решает, какому тенантному маршруту оно соответствует, формирует очищенное уведомление, подавляет дубликаты и штормы и отправляет его вживую в каналы, которые компания уже использует. Он владеет логикой решить что/кому/когда; коннекторы вывода владеют логикой как доставлять — он потребляет этот транспорт, но никогда его не переизобретает.

Что это такое

Каждый модуль продукта сообщает об оповещении как о finding с минимумом данных на шине (finding.reported) с пространственно-именованным Kind — надёжность (health_subject_down), расходы (finops_budget), безопасность (security_guardrail), регрессия eval (eval_regression), резидентность (compliance_residency_violation), ритм оркестрации, голос и другое. Модуль XV подписан только на этот единый общепродуктовый канал оповещений и маршрутизирует по Kind, серьёзности, исходному модулю и субъекту. Он сознательно не подписан на сырую телеметрию вроде cost.sampled или edge.observed: оповещение о расходах приходит как finding finops_budget, а не как cost sample. Это и есть seam, который превращает findings всего продукта в действенные уведомления.

Контракт и сущности

Модуль объявляет две тенантно-ограниченные сущности в общей модели данных:

Сущность	Режим	Что содержит
route	изменяемая, аудируемая	Правило маршрутизации: предикат по типам событий, glob-ам finding-kind (например health_*), минимальной серьёзности, исходным модулям и видам субъектов → именованное назначение (destination), с пооконными окнами дедупликации и троттлинга для маршрута и приоритетом. Не хранит никакого секрета назначения — только несекретное имя назначения.
delivery	только добавление	Журнал доказательств каждой попытки доставки: маршрут, назначение, вид finding, серьёзность, ссылка на субъект, краткий заголовок, корреляционный хеш и класс исхода (delivered, failed, no_dispatcher, unknown_destination).

На каждый finding модуль вычисляет включённые маршруты тенанта в порядке приоритета; каждое оставленное пустым измерение предиката означает любой, а glob-сопоставление поддерживает точные или prefix*-формы. Сопоставление происходит внутри read view, сетевая доставка выполняется строго вне любой транзакции хранилища, и затем исход записывается в журнал «только добавление». Создание, изменение или удаление маршрута, а также отправка тестового уведомления — это привилегированные, самоаудируемые действия, атрибутированные реальному принципалу. Маршруты route и delivery публикуются в отдельном beta-справочнике маршрутов модулей, а не в стабильном основном контракте; их форма на уровне полей живёт в типизированных интерфейсах продукта.

Что он потребляет и производит

• Потребляет finding.reported — единый общепродуктовый канал оповещений. Это маршрутизатор, а не зонд или счётчик: он никогда не опрашивает инфраструктуру и ничего не измеряет.
• Производит исходящие уведомления через seam отправки, опирающийся на коннекторы вывода (Slack/Teams, PagerDuty/Opsgenie, подписанный webhook и назначение SIEM, покрывающее Splunk/Elastic через CEF/LEEF/syslog/OTLP). Уведомление несёт только уже безопасные для отображения поля finding — заголовок, kind, серьёзность, ссылку на субъект и корреляционный хеш — и никогда не несёт payload, prompt, секрет или PII. Минимум данных — это свойство протокола передачи, а не пост-фактум фильтр. Секрет назначения живёт только в конфигурации коннектора, которую обеспечивает оператор, и здесь на него ссылаются по несекретному имени.

Честные ограничения

• Стандартный бинарник поставляется с диспетчером в режиме deny-closed. Пока оператор не обеспечит назначения, диспетчер подключён, но пуст: несопоставленная доставка записывается как no_dispatcher, а неверно сконфигурированное или назначение неизвестного вида разрешается в unknown_destination в журнале. Он никогда не имитирует успех — недоставка всегда видна.
• Исходящий webhook — это коннектор-назначение, а не webhook OpenAPI. Это канал вывода, в который пушит control plane, а не колбэк, который вы регистрируете в API продукта.
• Дедупликация и троттлинг подавляют отправку, а не исход. Дедуплицированное или подвергнутое троттлингу уведомление сознательно не записывается в журнал доставки (чтобы он никогда не раздувался). Каждая реальная попытка доставки, напротив, записывается — delivered, failed, no_dispatcher и unknown_destination в равной мере — так что недоставка всегда видна и никогда не отбрасывается молча.
• Сырая ошибка коннектора никогда не сохраняется и не логируется — только несекретный класс исхода — потому что транспортная ошибка может нести секрет назначения в своём URL.

Связанное

• Каталог модулей — где находится модуль XV и разделение Govern/Actuate.
• Push в ваш SIEM — драйвер S2S-push (modules/siemforward), который переформатирует findings и запечатанный журнал аудита в родной диалект башни (OCSF/CEF/LEEF/syslog/OTLP) и едет на надёжной доставке платформы событий — push-дополнение к назначениям выше.
• Справочник шины событий — событие finding.reported и его payload FindingReport.
• Карта доступа и ресурсов — соседний справочник Core/Intelligence.
• Пересылка аудита в Splunk — подключение назначения SIEM.
• Управление и одобрение — действия по findings, которые маршрутизирует этот модуль.
• Честность и ограничения — позиция deny-closed по умолчанию во всём продукте.