# Pilot Validation Checklist

Документ фиксирует проверку AWatch-rus перед реальным пилотом. Цель проверки:
подтвердить, что уже реализованные сценарии можно показать заказчику без
добавления нового функционала и без ложных заявлений о DLP, SIEM или EDR.

## Executive сценарий

- Главный управленческий вывод отображается первым.
- Руководитель видит KPI, Risk Narrative и Recommended Actions без технических
  ИБ-деталей по умолчанию.
- Explainable KPI отвечает на вопрос, почему индекс активности имеет текущее
  значение.
- Risk Narrative объясняет, что происходит, почему это риск и что делать дальше.
- Ролевые ограничения не дают роли `executive` видеть расследовательскую и
  техническую ИБ-детализацию без смены роли.
- В демо используются только синтетические данные.

## Workforce сценарий

- Отображается индекс активности и объяснение факторов.
- Доступно сравнение подразделений и ответственных.
- Видны тренды daily, weekly и monthly, если данные есть.
- Отдельно показываются признаки перегрузки и недозагрузки.
- Coverage и freshness показывают надежность KPI.
- При неполных данных система снижает доверие к KPI, а не выдает уверенный
  вывод.
- Отчеты не формулируют автоматическую кадровую оценку сотрудника.

## Security сценарий

- ИБ видит UEBA Score v1, risk score, severity и reason codes.
- Список incident candidates содержит объяснимые причины попадания в очередь.
- Security View отделен от управленческого Workforce Dashboard.
- pfSense readiness отображается только как `contract_only`, если задействован
  соответствующий слой контрактов.
- Интерфейс не заявляет AWatch-rus как полноценный SIEM или DLP.
- Все выводы rule-based, без ML и LLM.

## Forensics сценарий

- Расследователь видит карточку расследования, timeline, evidence и экспорт
  Markdown-отчета.
- Связка user, host, app и network event показывается только в рамках доступных
  demo/contracts данных.
- В demo-режиме отсутствуют реальные ФИО, логины, IP-адреса, hostname и домены.
- Система помогает собрать материалы, но не формирует юридически обязательный
  вывод без проверки ответственным лицом.

## Agent сценарий

- Rust Agent baseline описан и проверяется через документацию.
- Rust-primary направление не трактуется как полное удаление PowerShell.
- Runtime/fallback/installer/repair PowerShell scripts остаются
  documented fallback/support layer до отдельного burn-in/canary/rollback
  и acceptance gate.
- Для пилота определены источники данных, ожидаемое покрытие и допустимая
  задержка.
- Потеря части данных снижает confidence и фиксируется как operational gap.
- Массовое развертывание агента выполняется волнами после согласования с ИТ.
- Agentless-направления считаются roadmap или planned, если не подтверждены
  текущей поставкой.

## Reporting сценарий

- `/api/reports` и портальные отчеты возвращают данные в рамках роли.
- Markdown-отчет формируется на демонстрационных данных.
- В отчете видны KPI, Explainable KPI, Risk Narrative и Recommended Actions.
- При деградации источников отчеты должны возвращать контролируемый degraded
  или stale статус, а не зависать.
- Оператор может открыть runbook и понять порядок диагностики.

## Evidence перед запуском пилота

- Выполнен `scripts/pilot-validation-smoke.mjs`.
- Выполнен актуальный smoke портала на целевом стенде.
- Проверены скриншоты из `docs/screenshots/`.
- Проверены ссылки README и ключевых pilot-документов.
- Зафиксированы открытые gaps в `docs/PILOT_GAP_ANALYSIS_RU.md`.