Normalization Runbook

1. Операционный обзор

Функция:

  • даёт optional semantic rewrite;

  • не должна влиять на базовый deterministic render;

  • при сбоях должна безопасно деградировать к исходному deterministic output.

Критичность:

  • средняя

2. Владение и модель поддержки

Основной владелец:

  • владелец AI adapter / normalizer layer

Смежные владельцы:

  • владелец render workflow

  • владелец composition workflow

  • владелец engine integration

3. Ключевые сигналы и наблюдаемость

На что смотреть:

  • repeated provider failures;

  • parsing errors из normalization responses;

  • placeholder mismatch errors;

  • user-visible mismatch between source snapshot and normalized freshness status;

  • неожиданный рост derived normalization failures.

4. Типовые сбои

Типовые failure modes:

  • missing configuration Функция normalization недоступна.

  • stale source snapshot Пользователь смотрит на outdated normalized result.

  • low-quality semantic rewrite Результат stylistically или semanticly непригоден.

  • placeholder breakage Block normalization отклоняется engine validation.

5. Реакция на инцидент

Порядок действий:

  1. Проверить AI settings.

  2. Проверить representative normalization sample.

  3. Для composition path отдельно проверить placeholder preservation failure.

  4. Убедиться, что render path сам по себе работает штатно.

  5. При необходимости рекомендовать пользователю вернуться к raw/rendered output.

6. Режимы деградации

Допустимые режимы деградации:

  • отключить normalization;

  • продолжать работу только с deterministic render;

  • отключить composition normalization, сохранив text normalization, если ломается именно block-preserving path.

7. Восстановление и проверка

После исправления:

  1. Повторно выполнить normalization на representative sample.

  2. Проверить, что status сообщает об актуальном normalized result.

  3. Для composition path убедиться, что derived blocks публикуются без placeholder violations.

  4. Проверить reuse cached derivatives.

8. Когда эскалировать

Эскалировать нужно, если:

  • provider failures стали системными;

  • normalized outputs массово ухудшились после изменения prompt policy;

  • placeholder-preservation check часто ломается на нормальных блоках;

  • GUI stale-state стал вводить пользователей в заблуждение.

9. Контакты эскалации

  • Team Lead: владелец AI workflow

  • Core owner: владелец engine integration

  • UI owner: владелец render/composition workflows