[drive-download] Полный манускрипт 200226+.docx

Google Docs neutral 34 чанков ~53 мин чтения
1. Введение<br> 1.1. Цели и задачи системы<br> 1.1.1. Управляемость кампании через индексы<br> Система строится так, чтобы состояние кампании описывалось небольшим набором понятных индексов (PRS, SSI, DI, NI, LI, CT), а не россыпью несвязанных метрик. Каждый индекс привязан к конкретным управленческим решениям: смена режима, изменение частоты контактов, переразклад ресурсов между регионами и каналами. Это позволяет ЛПР видеть не «зоопарк графиков», а компактную картину риска и нагрузки и, опираясь на неё, быстро выбирать сценарий действий.<br> 1.1.2. Связка «смыслы → действия → режимы»<br> Базовая идея — не отделять смысловую работу (нарративы, волны) от операционной (контент‑фабрика, регионы) и от режимного управления риском. Каждая крупная смысловая волна описывается в виде Wave Brief, превращается в тактические действия по каналам, а их совокупный эффект отслеживается через индексы и при необходимости переводит систему в другой режим (Normal/Attention/Stress/Crisis). Таким образом, смысловые решения напрямую отражаются в режиме работы штаба и требованиях к темпу, формату и объёму коммуникаций.<br> 1.2. Принципы дизайна<br> 1.2.1. Минимально достаточная сложность<br> Модель сознательно ограничена минимальным набором слоёв и индексов, которых достаточно, чтобы управлять риском и устойчивостью кампании, но которые не требуют тяжёлой научной инфраструктуры. Вся «глубокая» математика и сложные методы (полный EWS, спектральный анализ, продвинутые модели распространения мнений) остаются за рамками, чтобы система могла быть реализована силами небольшой команды и работать в условиях ограниченных данных.<br> 1.2.2. Прозрачность для ЛПР и исполнителей<br> Все ключевые индексы и режимы должны быть объяснимы в двух–трёх фразах любому участнику — от министра до регионального координатора. Для руководства предусмотрен отдельный «одностраничный» слой: три индекса (PRS, SSI, ok_rate), четыре режима и набор действий, что снижает барьер для принятия решений и уменьшает риск неправильной интерпретации сигналов. Для исполнителей индексы сводятся к простым правилам: что делать, если регион попал в P3, если CT перегрет, если ok_rate упал ниже порога.<br> 1.2.3. Приоритет устойчивости над скоростью<br> Система настроена так, чтобы избегать реактивной «гонки за повесткой» ценой выгорания аудитории и штаба. В дизайн заложен гистерезис режимов и механизмы учёта перегрева (CT, Fatigue‑flag), которые позволяют сознательно замедляться, когда скорость начинает разрушать доверие и внимание. Приоритетом считается не максимальное количество сообщений, а поддержание устойчивого диалога и сохранность доверия к источникам, даже если это требует временного снижения активности.<br> 1.3. Связь с PSSR Core<br> 1.3.1. Перенесённые элементы (режимы, PRS, Cog2‑идея)<br> Из ядра PSSR берутся три ключевых концепции:<br> - режимный двигатель (Normal/Attention/Stress/Crisis) с гистерезисом, как способ переводить сложную ситуацию в дискретные управленческие режимы;<br> - интегральный индекс PRS (Communication Stress Index) как компактный показатель совокупного напряжения повестки и риска срыва коммуникации;<br> - упрощённый когнитивный слой Cog2‑лайт (внимание, усталость, поляризация), позволяющий учитывать не только объём контактов, но и психофизиологическое состояние аудитории.<br> 1.3.2. Исключённые элементы (полный EWS, Якоби, SDM‑полный)<br> Осознанно исключены трудоёмкие и требовательные к данным компоненты: полный ранний предупредительный контур (EWS) с анализом дисперсии, автокорреляций и сложных паттернов; детальная динамика через матрицы Якоби и расчёт чувствительности по всем слоям; а также полный SDM (Stability & Decision Model) с оптимизацией по множеству сценариев. Такая «обрезка» позволяет сохранить управляемость и реализуемость системы в реальном административном контексте, не теряя при этом основной логики риск‑управления и режимного контроля.<br> 2. Карта слоёв системы<br> 2.1. Общее описание слоёв управления<br> Система управления коммуникацией строится как набор взаимосвязанных слоёв, каждый из которых отвечает за свой тип решений и рисков.<br> - L‑Structure описывает кто и как работает: оргструктура штаба, процессы, каналы.<br> - L‑Narrative описывает что именно говорим: смыслы, волны, нарративы.<br> - L‑Cognitive фиксирует в каком состоянии аудитория: внимание, усталость, поляризация.<br> - L‑DataIntegrity отвечает за надёжность данных: отчётность, мониторинг, SSOT.<br> - L‑Influence описывает через кого и где говорим: реестр площадок, их качество и риски.<br> Все индексы и режимы опираются на комбинацию сигналов из этих слоёв, а управленческие решения принимаются с учётом их согласованности.<br> #2.1.1. Схема взаимодействия слоёв<br> Работа слоёв организована как замкнутый цикл:<br> 1. L‑Narrative формирует ядро смыслов и волны.<br> 2. L‑Structure превращает их в план действий по каналам и регионам.<br> 3. Через L‑Influence выбираются конкретные площадки и аккаунты, через которые волны пойдут.<br> 4. L‑Cognitive и индексы фиксируют реакцию аудитории (внимание, усталость, поляризацию).<br> 5. L‑DataIntegrity обеспечивает, чтобы все данные о действиях и реакции были корректными и полными.<br> 6. На основе этих данных пересчитываются индексы (PRS, SSI, DI и др.), режимы и корректируется как содержание (Narrative), так и механика (Structure).<br> Таким образом, смысловые решения всегда «заземлены» в операционку, а операционные решения опираются на проверенные данные, а не на ощущение.<br> 2.2. L‑Structure (структура и процессы)<br> #2.2.1. Каналы и носители (онлайн/оффлайн)<br> В этом подслое описывается вся коммуникационная инфраструктура:<br> - онлайн‑каналы (сайты, соцсети, мессенджеры, рассылки);<br> - офлайн‑носители (встречи, брифинги, печатные материалы, наружка, «полевые» форматы).<br> Для каждого канала фиксируются: тип контента, допустимая частота, основная аудитория и ограничения (юридические, технические, ресурсные), что позволяет в дальнейшем сопоставлять нагрузку (CT) и эффективность.<br> #2.2.2. Фабрика контента и цепочки согласований<br> Здесь описывается производственный контур: кто генерирует черновики (аватары, авторы), кто редактирует, кто согласует и в какие сроки.<br> - задаются стандартные шаги approval‑цепочки и целевые SLA;<br> - определяется, какие материалы могут идти по упрощённой схеме (типовые сообщения, шаблоны кризиса).<br> Это позволяет связать нагрузку на людей и процессы с индексом SSI и формально определить момент перегруза и необходимость сокращения планов.<br> #2.2.3. Региональные контуры и роли<br> Описываются роли региональных координаторов, их связь с центральным штабом и формат обмена данными: отчётность, сигналы снизу, согласование волн.<br> - фиксируется, какие решения принимаются на региональном уровне, а какие требуют центра;<br> - задаются требования к качеству отчётности и использованию реестра площадок.<br> Такой описанный контур снижает риск хаотичной самодеятельности и имитации выполнения задачи на уровне регионов.<br> 2.3. L‑Narrative (смыслы и волны)<br> #2.3.1. Ядро смысла и Wave Brief<br> Ядро смысла — это компактная формулировка того, что именно система должна донести: ключевые сообщения, ценностные опоры, красные линии. Для каждой крупной темы готовится Wave Brief, включающий:<br> - цель волны (что должно измениться в восприятии/поведении);<br> - ключевые формулировки (do/don’t say);<br> - целевые аудитории и примеры форматов.<br> Wave Brief становится «ТЗ» для фабрики контента и регионов и связывает смысловой слой с операционным.<br> #2.3.2. Набор ключевых нарративов<br> На уровне кампании выделяется ограниченный набор опорных нарративов (легитимность, безопасность, участие, справедливость и т.п.), каждый из которых разворачивается через отдельные волны. Это позволяет не распыляться на бесконечный поток разрозненных сообщений, а держать фокус на нескольких устойчивых смысловых линиях и измерять их влияние через индексы и исследования.<br> #2.3.3. Правила адаптации нарративов по регионам<br> Для регионов задаются чёткие правила: что можно адаптировать (язык, примеры, локальные кейсы), а что менять нельзя (ядро смысла, ключевые формулировки). Это снижает риск появления локальных противоречивых трактовок и позволяет сопоставлять влияние одних и тех же нарративов в разных территориях.<br> 2.4. L‑Cognitive (когнитивное состояние аудитории)<br> #2.4.1. Внимание, усталость, поляризация (Cog2‑лайт)<br> Когнитивный слой фиксирует три агрегированных показателя:<br> - внимание (A): насколько аудитория вовлечена и замечает сообщения;<br> - поляризация (P): насколько мнения по ключевым темам расходятся и радикализируются;<br> - усталость (F): ощущение перенасыщения, раздражения, «выключения» из коммуникации.<br> Эти показатели оцениваются по доступным маркерам: динамика вовлечения, тональность комментариев, результаты опросов, данные мониторинга отношения к каналам.<br> #2.4.2. Сигналы усталости и раздражения<br> На уровне практики фиксируются простые сигналы: падение органического охвата при сохранении частоты, рост доли негативных/саркастических реакций, запросы «хватит» в обратной связи. Эти сигналы используются как триггеры для Fatigue‑flag и смены форматов/частоты в перегретых сегментах, чтобы не выжигать внимание аудитории.<br> 2.5. L‑DataIntegrity (целостность данных)<br> #2.5.1. Источники и риски искажения (отчётность, мониторинг)<br> В этом слое описываются все основные потоки данных: отчёты регионов, данные мониторинга медиа/соцсетей, внутренние журналы активности. Для каждого потока фиксируются типичные риски: «рисованная» отчётность, неполные выгрузки, задержки, человеческие ошибки, предвзятость источников.<br> Цель слоя — признать, что данные по умолчанию не идеальны, и встроить механизмы их проверки и улучшения до того, как на них начинают опираться индексы и решения.<br> #2.5.2. Место аудита ссылок и SSOT<br> Ключевой практический элемент — конвейер аудита ссылок (link_audit), который автоматически проверяет доступность, релевантность и уникальность материалов, заявленных в отчётах. Результаты аудита становятся частью единого источника истины (SSOT) для всей системы, который используется и для расчёта индексов, и для оценки работы регионов. Это снижает пространство для манипуляций, позволяет честно видеть картину и делает индикаторы устойчивости менее зависимыми от человеческого фактора.<br> 2.6. L‑Influence (субъекты влияния)<br> #2.6.1. Типы площадок (СМИ, паблики, инфлюенсеры, сетки)<br> Слой описывает карту игроков, через которых фактически доходит сигнал до аудитории:<br> - классические СМИ (ТВ, радио, онлайн‑издания);<br> - крупные и средние паблики в соцсетях;<br> - персональные инфлюенсеры и лидеры мнений;<br> - скрытые или полускрытые сетки аккаунтов.<br> Для каждой площадки фиксируются базовые характеристики: охват, тематика, тип аудитории, история поведения и риски.<br> #2.6.2. Необходимость паспортизации и скоринга<br> Чтобы уйти от хаоса и «интуитивного» выбора площадок, вводится паспорт площадки (`accounts`) и trust‑score/tier‑оценка, основанная на устойчивых метриках (качество аудитории, динамика роста, репутационные риски). Это позволяет:<br> - планировать кампании через проверенный пул площадок A/B;<br> - ограничивать работу с сомнительными каналами (C/D);<br> - привязывать качество площадок к KPI регионов и эффективности кампании.<br> 3. Индексная модель<br> 3.1. Требования к индексам<br> 3.1.1. Интерпретируемость для ЛПР<br> Каждый индекс должен быть объясним руководителю в нескольких предложениях: что он измеряет, в каком диапазоне изменяется и какие решения запускает при превышении порогов. Это значит, что итоговые значения нормируются (например, в диапазон 0–1 или Low/Med/High) и привязываются к простым правилам: «если PRS > X — переключаемся в Stress», «если SSI > Y — режем план публикаций». Сложность расчётов может быть высокой внутри системы, но внешний интерфейс индексов должен оставаться простым и стабильным.<br> 3.1.2. Устойчивость к шуму и манипуляциям<br> Индексы проектируются так, чтобы не реагировать на единичные аномалии (один скандальный пост, одна некорректная цифра в отчёте), а отражать устойчивые изменения состояния системы. Для этого используются сглаживание по времени, пороги чувствительности и проверенные источники данных (через L‑DataIntegrity), а также защита от искусственно «подрисованных» показателей через аудит и перекрёстные проверки. Такой подход снижает риск как ложных тревог, так и искажения картины из-за намеренной или ненамеренной манипуляции данными.<br> 3.2. SSI — Structural Stress Index штаба<br> 3.2.1. Определение и назначение SSI<br> SSI отражает уровень структурного напряжения штаба: насколько текущая нагрузка по задачам, согласованиям и данным близка к пределу его пропускной способности. Значение SSI в диапазоне 0–1 показывает, насколько система «напряжена» организационно: от комфортной работы до состояния, когда любое дополнительное требование может привести к сбоям или хаосу. Индекс используется для принятия решений о сокращении планов, упрощении процедур и переключении режимов работы (особенно перехода в Stress).<br> 3.2.2. Компоненты SSI (данные/SLA/CT)<br> SSI строится как агрегат трёх компонент:<br> - качество и полнота данных (доля необработанных отчётов, задержки загрузки, доля «серых зон»);<br> - выполнение SLA по ключевым процессам (approval, публикация, обработка запросов регионов);<br> - перегрев по Contact Temperature для ключевых сегментов (когда темп коммуникации выше того, что аудитория и команда могут устойчиво выдерживать).<br> Каждая компонента нормируется, затем взвешивается, чтобы итоговый SSI отражал именно структурный стресс, а не разовый сбой в одном месте.<br> 3.2.3. Диапазоны и пороги SSI (норма/риск/критика)<br> Для практического использования вводятся зоны:<br> - зона нормы (например, SSI < 0.6): процессы справляются, можно наращивать активность;<br> - зона риска (0.6–0.8): растущая нагрузка, нужно аккуратно планировать волны и следить за очередями;<br> - зона критики (> 0.8): перегруз, требуется автоматически снижать объём задач и упрощать цепочки согласования.<br> Конкретные числовые пороги могут уточняться на основании пилотного периода, но принцип остаётся: SSI не просто сигнализирует о проблеме, а привязан к заранее определённым управленческим действиям.<br> 3.3. DI — Discrepancy Index<br> 3.3.1. Определение рассогласования «официоз ↔ поле»<br> DI измеряет расхождение между официальным нарративом (что говорит система) и тем, как ситуацию воспринимает и обсуждает аудитория. Это не «оценка лояльности», а индикатор того, насколько публичное поле и официальные сообщения идут в резонансе или в конфликте: высокое значение DI означает, что официальные формулировки не убеждают, вызывают скепсис или игнорируются.<br> 3.3.2. Источники для DI (Pulse, комментарии, ad‑hoc)<br> Для расчёта DI используются несколько типов данных:<br> - результаты быстрых опросов и «пульсовых» замеров отношения к ключевым тезисам;<br> - анализ комментариев, обсуждений и медиапокрытия по тем же темам (тональность, ключевые аргументы, повторы);<br> - целевые ad‑hoc исследования по спорным вопросам, инициируемые при росте тревоги.<br> Сопоставляя, насколько доминирующие аргументы и эмоции в поле совпадают или расходятся с официалкой, система формирует числовую оценку расхождения.<br> 3.3.3. Пороговые значения DI и действия по ним<br> Высокий DI — не повод просто «усилить официалку», а сигнал, что текущая формулировка или формат не работают.<br> - низкий DI: нарратив принят, можно работать в штатном режиме;<br> - средний DI: требуется уточнение аргументации, смена примеров, адресная работа с группами;<br> - высокий DI: необходимо пересобрать сообщение (язык, формат, канал) и возможно корректировать саму политику или ожидания.<br> Решения по DI фиксируются в регламентах, чтобы индекс не превратился в «инструмент обвинений», а был рабочим сигналом для корректировки.<br> 3.4. NI — Noise Index<br> 3.4.1. Определение «искусственного шума»<br> NI оценивает уровень информационного шума вокруг кампании: объём и интенсивность сообщений, которые не добавляют смыслового содержания, но забивают внимание аудитории или искажают картину. Важно отделять естественный фон (обычные новости и бытовое обсуждение) от искусственно поднятых волн, связанных с бот‑сетями, псевдоповесткой и фрагментарными скандалами без устойчивой базы.<br> 3.4.2. Примеры: бот‑сетей, мусорных всплесков<br> К типичным проявлениям высокого NI относятся:<br> - резкие всплески однотипных сообщений из малодостоверных источников;<br> - массовые репосты неоригинального контента без осмысленных комментариев;<br> - цепочки публикаций, явно не связаны с реальными событиями, но создающие ощущение «скандала».<br> Такие паттерны часто связаны с организованными кампаниями или попытками отвлечь внимание от значимых тем.<br> 3.4.3. Использование NI для фильтрации повестки<br> NI не используется для оправдания игнорирования неудобных, но важных тем; он служит для отделения реальных проблем от созданного на уровне обращений и соцсетей «шума». При высоком NI система:<br> - снижает вес подозрительных источников в индикаторах;<br> - концентрируется на подтверждённых фактах и устойчивых паттернах;<br> - может рекомендовать сознательно не подыгрывать шуму, если он не несёт содержательного риска.<br> Это помогает избегать навязанных повесток и сохранять фокус на действительно значимых вопросах.<br> 3.5. PRS‑лайт — Communication Stress Index<br> 3.5.1. Смысл PRS как общего риска повестки<br> PRS‑лайт — это интегральный индекс, который агрегирует ключевые сигналы (SSI, DI, NI и региональные показатели) в одну шкалу «напряжения повестки». Его задача — дать простой ответ на вопрос: насколько сейчас близко состояние коммуникационной среды к переходу в кризис и требуется ли смена режима.<br> 3.5.2. Простейшая формула PRS (через SSI/DI/NI)<br> В упрощённом варианте PRS строится как взвешенное сочетание:<br> - структурного стресса (SSI);<br> - рассогласования официоза и поля (DI);<br> - уровня шума (NI), при этом NI влияет сильнее, когда исходит из высокодоверенных источников или бьёт по ключевым темам.<br> Весовые коэффициенты выбираются так, чтобы PRS реагировал не на любой всплеск одного фактора, а на сочетание нескольких сигналов, что снижает вероятность ложных тревог.<br> 3.5.3. Уровни PRS (Low/Med/High) и их трактовка<br> Для практики вводятся три уровня:<br> - Low: среда стабильна, повестка контролируема — режим Normal;<br> - Med: накапливаются риски или локальные всплески — режим Attention, возможно Attention‑Light;<br> - High: комбинация высокого стресса, рассогласования и шума — основания для перехода в Stress или Crisis, в зависимости от характера инцидентов.<br> Каждый уровень PRS привязан к заранее определённому набору действий (изменение частоты, форматов, усиление мониторинга, включение кризисных протоколов), чтобы индекс был не «красивой цифрой», а рабочим рычагом управления.<br> 4. Contact Temperature и Cog2‑лайт<br> 4.1. Contact Temperature (CT)<br> 4.1.1. Определение CT по сегментам/каналам<br> Contact Temperature (CT) — это показатель того, насколько интенсивно и часто конкретный сегмент аудитории контактирует с кампанией через все каналы. CT рассчитывается отдельно по ключевым сегментам (молодёжь, госслужащие, малый бизнес и т.п.) и по основным каналам (соцсети, офлайн‑мероприятия, медиа), чтобы видеть, где нагрузка находится в комфортной зоне, а где приближается к перегреву.<br> 4.1.2. Расчёт CT (частота × сила контактов)<br> Базовая логика CT — сочетание частоты контактов и их «силы» (длительность, эмоциональная интенсивность, требуемое внимание). Частота учитывает количество контактов в единицу времени (сообщения, публикации, встречи), сила — сколько когнитивного ресурса требует взаимодействие (длинные тексты, сложные темы, видеоконференции и т.п.). Для каждого сегмента CT агрегирует эти параметры за окно (например, неделю), нормируется и даёт значение по шкале «низко–средне–высоко».<br> 4.1.3. Карта CT по регионам/аудиториям<br> Результаты CT визуализируются в виде карты: по оси «регионы», по оси «ключевые сегменты» или каналы, в ячейках — уровень температуры. Это позволяет быстро увидеть, где аудиторию почти не трогают (риски недоохвата), а где, наоборот, переносят на себе основную тяжесть коммуникации и приближаются к усталости и раздражению.<br> 4.2. Пороговые зоны CT<br> 4.2.1. Нормальная нагрузка<br> В нормальной зоне CT аудитория регулярно получает сообщения, но не испытывает ощущение «засыпали всем подряд»; уровни внимания и доверия остаются стабильными, а вовлечённость не падает. Для таких сегментов допустимо сохранять или даже слегка наращивать частоту при условии, что контент остаётся релевантным и не избыточным.<br> 4.2.2. Зона риска перегрева<br> Когда CT приближается к верхней границе нормы, начинают проявляться ранние признаки message fatigue: рост доли игнорируемых сообщений, слабая реакция на повторяющиеся темы, первые сигналы раздражения. В этой зоне уже стоит снижать повторяемость однотипных сообщений и переходить к более адресным, ценностным или полезным форматам, чтобы не доводить сегмент до полного выгорания.<br> 4.2.3. Перегрев (overload)<br> При высоком CT аудитория демонстрирует классические симптомы перегруза: активное избегание сообщений, отписки, жалобы, отрицательная реакция на любые обращения по теме. В этой фазе попытка «дожать» информацией обычно только ухудшает доверие и увеличивает психологическую реактивность, поэтому задача — уменьшить нагрузку и переключить формат взаимодействия.<br> 4.3. Fatigue‑flag<br> 4.3.1. Правило: CT выше порога 2–3 дня подряд<br> Fatigue‑flag — это бинарный сигнал, который срабатывает, если CT по сегменту удерживается в зоне риска или перегрева несколько дней подряд (например, 2–3 дня). Это отличает кратковременный всплеск (однократная акция, важное сообщение) от устойчивой перегрузки, которая ведёт к накоплению усталости и снижению доверия.<br> 4.3.2. Обязательный «день разрежения» и смена форматов<br> При срабатывании Fatigue‑flag вводится обязательный «день разрежения» для данного сегмента: снижается частота сообщений и/или меняется их характер (больше объяснений, благодарностей, сервисного контента, меньше агитации и тревожных тем). Это правило защищает аудиторию от хронического перенапряжения и помогает сохранить долгосрочную восприимчивость к важным сообщениям.<br> 4.4. Управление форматами по CT<br> 4.4.1. Смягчение форматов при перегреве<br> Если CT высок, система переключается на более «мягкие» форматы: короткие, понятные сообщения, истории людей, ответы на вопросы, вместо плотного потока однотипных лозунгов или сложных объяснений. При этом приоритет отдаётся сообщениям, которые снижают тревогу и дают практическую пользу, а не усиливают ощущение давления и информационного шума.<br> 4.4.2. Дифференциация по сегментам<br> CT считается по сегментам, поэтому снижение нагрузки не обязательно должно быть одинаковым везде: можно разрядить перегретые группы (например, активные пользователи соцсетей) и одновременно усилить работу с недоохваченными. Такой дифференцированный подход помогает оптимизировать общий объём коммуникации, не теряя эффективности и не доводя чувствительные аудитории до выгорания.<br> 4.5. Cog2‑лайт (A/P/F)<br> 4.5.1. Внимание (A): доля вовлечённых<br> Показатель A отражает, насколько аудитория реально замечает и обрабатывает сообщения: это доля тех, кто не только видит, но и хотя бы минимально взаимодействует (читает, кликает, досматривает). Снижение A при высокой частоте контактов — явный признак перегруза или нерелевантности контента.<br> 4.5.2. Поляризация (P): разброс мнений<br> Показатель P агрегирует данные о разбросе и конфликтности мнений вокруг ключевых тем: рост доли крайних позиций, усиление агрессивных споров, формирование «лагерей». Высокая P означает, что повестка воспринимается как конфликтная и разделяющая, что увеличивает риск эскалации при неосторожных коммуникациях.<br> 4.5.3. Усталость (F): признаки когнитивного/эмоционального выгорания<br> Показатель F фиксирует признаки message fatigue и общего выгорания: раздражение по поводу «очередного сообщения», повышенная готовность игнорировать даже полезную информацию, рост циничных или отстранённых реакций. Исследования показывают, что высокая усталость ведёт к снижению доверия к источникам и к психологической реактивности — активному сопротивлению рекомендациям.<br> Вместе A, P и F дают упрощённый, но практичный когнитивный профиль аудитории, который используется при планировании волн и выборе режима работы, особенно в сочетании с CT и индексами риска.<br> 5. Региональные индексы и сегментация<br> 5.1. Индекс легитимности (LI)<br> 5.1.1. Компоненты: доверие к процедуре, нарративы, инциденты<br> Индекс легитимности (LI) по региону отражает, насколько население воспринимает происходящее как «правильное» и «законное» — не только юридически, но и по ощущениям fairness и прозрачности. LI собирается из трёх групп сигналов:<br> - доверие к процедуре и институтам (опросы, фокус‑группы, обратная связь о «честности» и «понятности» процесса);<br> - доминирующие нарративы в регионе (поддержка/скепсис/обвинения в адрес процесса и организаторов);<br> - локальные инциденты, подрывающие доверие (конфликты на участках, ошибки, скандалы, медийные истории).<br> Каждый компонент нормируется и взвешивается так, чтобы индекс отражал не только «формальную законность», но и реальное принятие процесса людьми.<br> 5.1.2. Расчёт и интерпретация LI по региону<br> LI задаётся в диапазоне, например, от 0 до 1 или 0 до 100, где низкие значения означают серьёзные проблемы с восприятием легитимности, а высокие — устойчивое доверие. Для расчёта используются комбинированные данные: социология (если есть), анализ публичного дискурса, частота и тяжесть негативных инцидентов.<br> - высокий LI: регион принимает правила игры, отдельные инциденты не раскачивают систему;<br> - средний LI: есть значимая доля сомневающихся, нарративы о «нечестности» периодически всплывают;<br> - низкий LI: устойчивые нарративы о несправедливости, недоверие к процедуре и организаторам, высокий риск каскадных реакций.<br> LI используется как один из ключевых критериев для отнесения региона к P1/P2/P3.<br> 5.2. Индекс тревожности / каскадного риска<br> 5.2.1. Факторы тревожности (тональность, интенсивность)<br> Индекс тревожности отражает уровень эмоционального напряжения и вероятность того, что локальные проблемы могут быстро перерасти в каскад — цепочку конфликтов или инфошум, уходящий из‑под контроля. В его основу входят:<br> - тональность обсуждений (рост доли тревожных, злых, панических сообщений);<br> - интенсивность (частота упоминаний тревожных тем, скорость распространения сообщений);<br> - концентрация негативных сигналов в отдельных группах или территориях внутри региона.<br> В отличие от LI (который про доверие к системе), тревожность больше про текущий уровень эмоциональной «накачки» и готовности к резким реакциям.<br> 5.2.2. Связь с PRS и DI<br> Индекс тревожности тесно связан с PRS и DI:<br> - при высоком PRS и высокой тревожности регион становится кандидатом на статус P3 (красный), даже если формально нет крупных инцидентов;<br> - высокий DI при растущей тревожности означает, что официалка не убеждает и не гасит тревогу, а может восприниматься как «отговорка».<br> Таким образом, тревожность является важным «ускорителем» — она показывает, насколько быстро потенциальные проблемы могут превратиться в реальные кризисы при неблагоприятном развитии событий.<br> 5.3. Классификация P1/P2/P3<br> 5.3.1. Критерии порогов LI/тревожности<br> На основе LI и индекса тревожности регионы делятся на три класса:<br> - P1 (зелёные)— высокий LI, низкая или умеренная тревожность: стабильные регионы, где достаточно стандартного режима работы;<br> - P2 (жёлтые)— средний LI и/или растущая тревожность: зоны повышенного внимания, требующие усиления разъяснений и мониторинга;<br> - P3 (красные)— низкий LI и высокая тревожность: регионы с риском каскадных реакций и кризисов, где коммуникации и операции должны подчиняться более жёстким протоколам.<br> Конкретные пороги (например, LI < 0.4 и тревожность > 0.6 для P3) задаются в регламенте и уточняются по мере накопления данных, но логика остаётся: P‑класс — это компактный способ для ЛПР видеть карту риска по стране.<br> 5.3.2. Переходы между уровнями и выдержка по времени<br> Чтобы избежать «дребезга» (частых переключений), переходы между P‑уровнями происходят не мгновенно, а при устойчивом достижении порогов в течение определённого времени (например, нескольких дней или недель). Это позволяет отличить кратковременную вспышку (один инцидент, быстро погашенный) от устойчивого изменения состояния региона.<br> Журнал переходов P1/P2/P3 фиксируется, чтобы можно было анализировать, какие действия приводили к улучшению или ухудшению статуса и корректировать стратегию.<br> 5.4. Визуализация регионов<br> 5.4.1. Heatmap по LI и PRS<br> Для наглядности состояния регионов используется тепловая карта (heatmap), где по одной оси откладывается LI, по другой — PRS, а цвет ячейки отражает сочетание устойчивости и риска.<br> - зелёные зоны — высокий LI и низкий PRS;<br> - жёлтые — средний LI или PRS;<br> - красные — низкий LI и/или высокий PRS.<br> Такая визуализация позволяет ЛПР за несколько секунд увидеть, где ситуация благополучна, а где требует немедленного внимания и перераспределения ресурсов.<br> 5.4.2. Отображение P1/P2/P3 на карте<br> Дополнительно регионы раскрашиваются по P‑классам на географической карте: P1 — зелёный, P2 — жёлтый, P3 — красный. Это превращает сложные индексы в интуитивно понятную картинку: «где горит», «где тлеет», «где стабильно».<br> Такая карта может выводиться на главный экран дашборда руководства и использоваться как отправная точка для обсуждения: какие регионы требуют выезда, дополнительного объяснения, усиления мониторинга или временного ужесточения режимов коммуникации.<br> 6. Режимный двигатель<br> 6.1. Набор режимов<br> 6.1.1. Normal: фоновая работа<br> Базовое состояние системы, когда PRS низкий, региональные LI стабильны, инциденты единичны и не каскадируются. В этом режиме реализуются плановые волны, стандартные частоты контакта и обычные процедуры согласования без специальных ограничений.<br> 6.1.2. Attention: усиленная чувствительность<br> Режим повышенного внимания включается при росте PRS или локальных сигналах риска, но до системного кризиса. В Attention усиливаются мониторинг, Discovery‑запросы и разъясняющая коммуникация; руководство и ключевые команды работают с большей частотой апдейтов и более жёстким ситуационным контролем.<br> 6.1.3. Attention‑Light: ложная тревога (подрежим Attention)<br> Подрежим для ситуаций, когда есть всплеск упоминаний или тревожных сигналов, но факты и LI не подтверждают развитие кризиса. Система повышает чувствительность, аккуратно проверяет сигналы и коммуницирует осторожно, избегая как избыточной паники, так и полного игнора.<br> 6.1.4. Stress: устойчивое напряжение<br> Режим устойчивого напряжения включается при сочетании высоких PRS, заметного DI и/или череды инцидентов, которые не дотягивают до полноформатного кризиса, но уже перегружают штабы. В Stress резко снижается допустимый уровень «творчества», усиливается централизация формулировок и вводятся упрощённые цепочки согласования.<br> 6.1.5. Crisis: режим стратегической защиты<br> Crisis объявляется при серьёзных инцидентах типа A или резком скачке PRS/тревожности, когда доверие и управление повесткой под угрозой. В этом режиме включаются кризисные протоколы, создаётся единый коридор сообщений, большинство нестандартных активностей приостанавливается, фокус смещается на честное объяснение, удержание доверия и снижение риска эскалации.<br> 6.2. Условия входа в режим<br> 6.2.1. Пороги по PRS и LI<br> Переходы между режимами задаются порогами PRS и региональными LI:<br> - Normal → Attention: PRS переходит из зоны Low в Med, LI в большинстве регионов остаётся выше порога, но появляется несколько P2 зон;<br> - Attention → Stress: PRS устойчиво высокий (Med/High), LI проседает в ряде ключевых регионов, растёт доля P3;<br> - Stress → Crisis: PRS достигает High и/или LI резко падает в одном или нескольких стратегических регионах.<br> Точные численные значения (например, PRS > 0.7, LI < 0.4) фиксируются в таблице порогов и могут корректироваться по опыту.<br> 6.2.2. Комбинации PRS + инциденты A/B/C<br> Помимо «фона» (PRS/LI) учитывается тип инцидента:<br> - инцидент A (угроза безопасности, серьёзный сбой процедуры) почти автоматически поднимает режим до Crisis;<br> - повторяющиеся инциденты B (легитимность, фейки, утечки) при высоком PRS поднимают режим до Stress;<br> - массовые C‑инциденты (локальные конфликты, медийные скандалы) при низком PRS могут ограничиться Attention.<br> Таким образом, режим определяется не одной цифрой, а комбинацией индексов и типа событий.<br> 6.2.3. Простые EWS‑сигналы (рост DI/частоты упоминаний)<br> В качестве ранних предупредительных сигналов (EWS‑лайт) используются:<br> - резкий рост DI по ключевым темам (официалка и поле расходятся);<br> - скачок негативной тональности и частоты упоминаний бренда/темы (в 2–3 раза к базовому уровню);<br> - ускорение распространения негативных сообщений в соцсетях и медиа (вирусные посты, новые хэштеги).<br> При срабатывании таких сигналов система может временно перейти в Attention‑Light для проверки, не дожидаясь роста PRS до формальных порогов.<br> 6.3. Гистерезис режимов<br> 6.3.1. Верхние и нижние пороги для входа/выхода<br> Чтобы избежать частых колебаний режимов туда‑сюда, вводится гистерезис: пороги входа в более жёсткий режим выше, чем пороги возврата в мягкий. Например, для перехода в Stress требуется PRS > 0.6, а возвращение в Attention допускается только при PRS < 0.5 в течение заданного времени. Это даёт системе запас устойчивости и снижает чувствительность к кратковременным всплескам.<br> 6.3.2. Временные окна Tup/Tdown<br> Помимо уровней индексов, учитывается длительность:<br> - Tup — минимальное время, в течение которого условия повышенного режима должны держаться, чтобы переход состоялся (например, PRS > порога 6–12 часов);<br> - Tdown — минимальное время устойчивого улучшения, чтобы вернуться назад (например, 24–48 часов).<br> Такая настройка позволяет отличить краткую волну обсуждения от реального устойчивого изменения ситуации.<br> 6.3.3. Примеры сценариев «без дребезга»<br> Пример: резкий скачок PRS из‑за одного громкого материала, но через несколько часов индексы и тональность возвращаются в норму — при наличии Tup система останется в Attention‑Light и не «подскочит» сразу в Stress. Другой пример: PRS постепенно снижается, но LI в важном регионе всё ещё низкий — из‑за Tdown система не «провалится» обратно в Normal, пока устойчивость не подтвердится.<br> 6.4. Действия в разных режимах<br> 6.4.1. Разрешённые/запрещённые форматы и каналы<br> Для каждого режима задаются белые и чёрные списки форматов:<br> - в Normal допустимы эксперименты, юмор, сложные форматы, широкая палитра каналов;<br> - в Attention ограничиваются провокационные и неоднозначные форматы, усиливаются официальные и разъясняющие каналы;<br> - в Stress и особенно в Crisis запрещаются высокорискованные форматы (сатирические, конфликтные, сложные трактуемые формулировки), приоритет отдается проверенным каналам с высокой управляемостью и доверием.<br> 6.4.2. Изменение частоты касаний<br> Частота контактов с аудиторией также привязана к режиму:<br> - в Normal — плановые частоты, сглаженные по CT;<br> - в Attention — возможен временный рост частоты разъясняющих сообщений в чувствительных сегментах, но с учётом Fatigue‑flag;<br> - в Stress и Crisis — количество сообщений может уменьшаться, но каждое становится более содержательным и выверенным, чтобы не усиливать message fatigue и не создавать ощущение паники.<br> 6.4.3. Связка с планированием волн и кризисными сценариями<br> Режим напрямую влияет на планирование:<br> - при переходе в Attention часть будущих волн пересматривается (смещается акцент на стабилизацию, объяснение, поддержку P2/P3 регионов);<br> - в Stress некоторые плановые активности откладываются или упрощаются, освобождая ресурсы для работы с инцидентами и тревожными темами;<br> - в Crisis запускаются заранее подготовленные кризисные сценарии (playbook’и) по типам инцидентов, а все новые волны проходят через Crisis Cell и подчиняются логике «стратегической защиты» — удержание доверия, честное признание неопределённости и понятные шаги по выходу из ситуации.<br> 7. Связь с PSSR Core / TOM II<br> 7.1. Заимствованные элементы<br> 7.1.1. Концепция PRS, SSI, DI, NI<br> Из PSSR Core перенята логика построения набора композитных индексов, которые вместе описывают состояние системы: общий риск повестки (PRS), структурный стресс штаба (SSI), рассогласование официоза и поля (DI) и уровень искусственного шума (NI). Как и в классических композитных риск‑индексах, каждый из них агрегирует несколько подкомпонент с прозрачными весами, а итоговые значения нормируются в понятный диапазон и привязываются к управленческим порогам. Это позволяет оперировать не десятками сырых метрик, а компактным набором управляемых индикаторов риска.<br> 7.1.2. Гистерезис режимов и SDM‑подход<br> От PSSR заимствован принцип гистерезиса: пороги входа в более жёсткий режим выше порогов выхода из него, а решения о переключении принимаются с учётом временных окон. Это снижает чувствительность системы к краткосрочным колебаниям и делает поведение режимного двигателя более предсказуемым и устойчивым. Также перенята базовая идея SDM‑подхода (Stability & Decision Model): рассматривать смену режимов как управляемый процесс балансировки между риском и устойчивостью, а не как реакцию «с места» на каждый сигнал.<br> 7.1.3. Cog2 и cross‑coupling как идея<br> Из когнитивного слоя PSSR берётся идея учитывать не только факты и структуру, но и когнитивное состояние людей (внимание, усталость, поляризация) и его влияние на устойчивость. Вместо полной реализации сложных моделей cross‑coupling используется упрощённый Cog2‑лайт: A/P/F‑показатели и CT влияют на индексы и правила планирования волн, а изменения в структуре и повестке со временем отражаются в когнитивных метриках. Таким образом, сохраняется принцип «связанных слоёв», но в значительно более лёгкой и реализуемой форме.<br> 7.2. Исключённые элементы<br> 7.2.1. Полный аппарат EWS (Var/ACF/kurtosis/DTW)<br> Из PSSR Core сознательно исключены тяжёлые ранние предупредительные сигналы (EWS), требующие богатых временных рядов и серьёзной аналитической инфраструктуры: анализ дисперсии, автокорреляции, асимметрии, сложные расстояния между траекториями (DTW) и др. В условиях ограниченных данных и времени такие методы либо дают слишком много ложных сигналов, либо требуют ресурсов, которых у кампании нет; вместо этого используются простые EWS‑лайт (скачки DI, частоты упоминаний, негативной тональности).<br> 7.2.2. Матрицы Якоби, MSI/IE в полном виде<br> Полные динамические модели с матрицами Якоби, расчётом чувствительности по всем слоям и подробными индексами MSI/IE (устойчивость/эластичность влияния) опущены. Такие инструменты важны для фундаментальных исследований системного риска, но для оперативного штаба из 10–15 человек они избыточны и трудно объяснимы для ЛПР. Вместо этого используются более простые индексы и пороговая логика, которые дают достаточную управляемость без необходимости глубокой математической экспертизы в каждой смене.<br> 7.2.3. Слоевые модели элит (L‑Elite, L‑Clan и др.)<br> Сложные слои, описывающие взаимодействия элитных групп, кланов и скрытых центров влияния (L‑Elite, L‑Clan и т.п.), также оставлены за рамками рабочей системы. Несмотря на аналитическую ценность, их корректная параметризация требует отдельной политологической и социологической работы, а результат сложно формализовать в виде оперативных регламентов для кампании. В текущей архитектуре фокус сделан на тех слоях, которые можно измерять и менять управленческими решениями штаба в реальном времени: структура, повестка, когнитивное состояние, данные и площадки.<br> 1. Структура штаба и ролей<br> 1.1. Центральное ядро<br> 1.1.1. Руководитель штаба<br> Руководитель штаба несёт общую ответственность за коммуникационную стратегию, выбор режима (Normal/Attention/Stress/Crisis) и приоритизацию ресурсов. Он утверждает ключевые решения по волнам, даёт мандат на включение Crisis Cell и обеспечивает связь с политическим руководством и другими ведомствами.<br> 1.1.2. Операционный координатор<br> Операционный координатор отвечает за повседневную «сборку» работы штаба: планирование дня, запуск и контроль задач, синхронизацию контент‑фабрики, мониторинга, Regional Desk и Approval‑центра. Это «переходник» между стратегическими решениями руководителя и конкретными действиями команд, в том числе в режиме повышенной нагрузки.<br> 1.2. Контент‑фабрика<br> 1.2.1. Аватары и их роли<br> Аватары — закреплённые «голоса» (персоны), от имени которых системно ведётся коммуникация в разных каналах (официальные аккаунты, тематические страницы, лидеры мнений). Для каждого аватара описаны тон, допустимые темы, примерные форматы и уровень допустимой вариативности, чтобы сохранять целостность образа при работе нескольких авторов и ИИ‑инструментов.<br> 1.2.2. Редакторы/фактчек/юристы<br> Редакторы и фактчекеры обеспечивают смысловую и фактическую корректность материалов, контролируют соблюдение Wave Brief и стиля, вычищают потенциально токсичные или двусмысленные формулировки. Юристы подключаются к сложным и чувствительным сообщениям (правовые риски, ответственность, формулировки по инцидентам), чтобы минимизировать юридические и репутационные последствия.<br> 1.2.3. Продюсеры по каналам<br> Продюсеры отвечают за конкретные каналы (например, Telegram/соцсети, ТВ/радио, офлайн‑мероприятия), адаптируя контент под формат, аудиторию и технические ограничения. Они же следят за сеткой публикаций, согласуют тайминг с Approval‑центром и мониторингом и обеспечивают единый стиль в рамках своего канала.<br> 1.3. Approval‑центр<br> 1.3.1. Состав и зоны ответственности<br> Approval‑центр — небольшая команда, которая даёт финальное «добро» на публикацию контента и запуск волн: старший коммуникатор, юрист (по необходимости), представитель руководителя штаба. Для разных типов материалов определены разные уровни и глубина согласования (например, для типовых сообщений — упрощённая процедура, для кризисных — полный состав).<br> 1.3.2. Варианты упрощённого approval<br> В условиях перегруза или в нижних режимах (Normal/мягкий Attention) используется упрощённый approval: заранее утверждённые шаблоны, доверенные автопубликации для низкорискованных материалов и «белые списки» форматов. Это позволяет разгрузить узкое горлышко согласований, сохраняя контроль за критически важными сообщениями.<br> 1.4. Мониторинг и аналитика<br> 1.4.1. Операторы планового мониторинга<br> Операторы планового мониторинга ведут постоянное наблюдение за медиа, соцсетями и ключевыми источниками, формируя ежедневные срезы и базовые метрики (охваты, тональность, темы). Они обеспечивают «фоновый радар» для штаба и являются первым уровнем фиксации возможных отклонений от нормы.<br> 1.4.2. Ad‑hoc аналитики (Discovery)<br> Ad‑hoc аналитики подключаются по запросу штаба или руководства для быстрых углублённых разборов (discovery): выяснить, что стоит за всплеском, какие нарративы и источники тянут тему, какова география и целевые группы. Они используют расширенный инструментарий (LLM, кластеризацию, дополнительные источники) и выдают короткие брифы с выводами и рекомендациями.<br> 1.5. Regional Desk<br> 1.5.1. Координаторы по регионам<br> Координаторы отвечают за связь с региональными командами: получение отчётности, передачу Wave Brief и инструкций, сбор сигналов «с земли» и сопровождение проблемных регионов (P2/P3). Они помогают выравнивать понимание задач, объяснять решения по режимам и KPI, а также обеспечивают обратную связь о реализуемости планов.<br> 1.5.2. Каналы связи с регионами<br> Формализуются постоянные каналы: регулярные созвоны/брифинги, отдельные чаты/почтовые рассылки, единое хранилище документов и шаблонов. Для экстренных ситуаций прописываются быстрые каналы эскалации (от региона в штаб и обратно) и формат фиксации таких коммуникаций.<br> 1.6. Crisis Cell<br> 1.6.1. Состав кризисной группы<br> Crisis Cell — узкий круг лиц, который активируется при переходе в режим Crisis: руководитель штаба (или его доверенный), ключевой коммуникатор, юрист, представитель оперативного блока/ведомства, представитель мониторинга и, при необходимости, представитель регионов. Состав подобран так, чтобы в одной комнате были полномочия, информация и компетенции для быстрых решений и согласованных сообщений.<br> 1.6.2. Порядок активации/деактивации<br> В регламенте заранее описывается, кто и при каких условиях может инициировать активацию Crisis Cell (например, при инциденте типа A или резком скачке PRS/LI), и кто принимает финальное решение. Также фиксируется порядок деактивации: условия возврата к обычной структуре, передача накопленных решений в стандартные контуры и проведение пост‑кризисного разбора.<br> 2. Ежедневный цикл штаба<br> 2.1. Утренний слот<br> 2.1.1. Обновление индексов и CT<br> В начале дня мониторинг и аналитика обновляют ключевые индексы (PRS, SSI, DI, NI, LI по регионам) и карту CT по сегментам и каналам, чтобы штаб видел актуальное состояние системы. Эти данные выводятся на общий дашборд и становятся отправной точкой для определения режима дня и объёма работы.<br> 2.1.2. Определение режима дня и приоритетов<br> Руководитель штаба и операционный координатор, опираясь на обновлённые индексы и сообщения о ночных/утренних инцидентах, фиксируют режим (Normal/Attention/Stress/Crisis) на текущие сутки. Одновременно определяются 3–5 приоритетов дня: какие темы, регионы и каналы требуют особого внимания и ресурсов.<br> 2.2. Планирование дня<br> 2.2.1. Выбор и настройка волн по сегментам<br> На основе режима и приоритетов выбираются волны, которые будут идти сегодня: какие Wave Brief активировать, какие — отложить, где усилить разъяснение или стабилизацию. Для каждой волны уточняются целевые сегменты, CT‑ограничения, ключевые сообщения и форматы (особенно при Attention/Stress).<br> 2.2.2. Расклад по P1/P2/P3<br> План раскладывается по регионам с учётом их P‑класса:<br> - P1 получают базовый объём активности;<br> - P2 — усиленные разъяснения и мониторинг;<br> - P3 — более плотную и осторожную работу, с приоритетом стабильности и доверия.<br> Окончательный план фиксируется в рабочем документе (или системе задач) и доводится до контент‑фабрики, Regional Desk и мониторинга.<br> 2.3. Текущая работа<br> 2.3.1. Контроль исполнения плана<br> В течение дня операционный координатор и продюсеры по каналам отслеживают выполнение плана: какие материалы уже выпущены, какие зависли на approval, где есть отставание или перегруз. Для этого используются простые операционные дашборды: очереди, статусы, соблюдение SLA по согласованию и публикациям.<br> 2.3.2. Реакция на сигналы Discovery<br> В параллели работает Discovery‑контур: по мере поступления ad‑hoc запросов от руководства или регионов аналитики проводят быстрые разведки и выдают брифы. Если бриф показывает значимый риск (рост негативной тональности, новые нарративы, всплески в P2/P3), координатор может скорректировать план дня: добавить волны, изменить фокус, пересмотреть формулировки.<br> 2.4. Вечерний срез<br> 2.4.1. Сводка индексов, инцидентов и исполнения<br> В конце дня собирается короткий отчёт: как изменились основные индексы, какие инциденты произошли, какие волны и активности были выполнены, где возникли проблемы (approval, регионы, площадки). Это может быть 15–30‑минутный созвон или письменный брейф, в зависимости от режима (в Stress/Crisis — чаще и детальнее).<br> 2.4.2. Предварительные решения на следующий день<br> На основе вечернего среза фиксируются предварительные решения: нужно ли менять режим, какие темы будут приоритетными завтра, какие регионы требуют отдельного внимания или выезда. Это снижает эффект «чистого листа» утром и помогает команде готовиться заранее, особенно в период устойчивого напряжения.<br> 2.5. Журнал событий<br> 2.5.1. Формат записи (кто/что/когда/на каком режиме)<br> Ведётся простой журнал ключевых событий: дата/время, режим, событие (инцидент, смена режима, запуск/остановка волны), кто принял решение и на основании каких сигналов. Формат может быть таблицей или формой в системе, но должен позволять быстро восстановить ход событий и решений.<br> 2.5.2. Использование для ретроспективы и обучения<br> Журнал используется для пост‑фактум анализа: что сработало, что нет, где индексы давали заранее сигналы, но решения запаздывали. Такие ретроспективы помогают улучшать пороги, процедуры и обучение команды, превращая каждую кампанию в источник опыта для следующей.<br> 3. Approval‑flow и HITL‑перегруз<br> 3.1. Стандартный маршрут материала<br> 3.1.1. От идеи до публикации<br> Стандартный поток: автор/аватар → редактор/фактчек → (при необходимости юрист) → Approval‑центр → продюсер канала → публикация. На каждом шаге фиксируются статусы и время, чтобы можно было измерять, где именно материал задерживается и как это влияет на SLA.<br> 3.1.2. Контроль версий и правок<br> Все правки и версии материалов хранятся централизованно (в системе или общем репозитории), чтобы избежать потерь текста, дублирования и конфликтов между редакциями. Это особенно важно в кризис, когда несколько людей могут параллельно работать над одним сообщением.<br> 3.2. SLA и метрики очередей<br> 3.2.1. Целевые SLA по каналам/типам контента<br> Для разных типов контента определяются целевые времена согласования (SLA): например, типовая новость — до 2 часов, кризисное сообщение — до 30 минут, сложный аналитический материал — до суток. Эти SLA согласуются с руководством и отражают баланс между скоростью и качеством/безопасностью.<br> 3.2.2. Визуализация очередей на дашборде<br> Очереди материалов в approval показываются на дашборде: количество элементов в очереди, среднее время ожидания, «возраст» самых старых задач, загрузка каждого согласующего. Это превращает approval из «чёрного ящика» в управляемый процесс, где перегруз можно увидеть до того, как начнут массово срываться сроки.<br> 3.3. Триггер перегруза approval<br> 3.3.1. Порог по длине очереди<br> Если количество материалов в очереди превышает заданный порог (например, X штук) для своего режима, система фиксирует состояние перегруза и отправляет сигнал координатору и руководителю. Пороги могут отличаться для Normal и Stress/Crisis, но сам факт фиксированного лимита важен для дисциплины.<br> 3.3.2. Порог по среднему SLA<br> Второй триггер — превышение целевого среднего времени согласования (например, SLA × 1.5 в течение N минут/часов). Это позволяет ловить «вялотекущие» перегрузы, когда очередь ещё невелика, но каждая задача обрабатывается слишком долго.<br> 3.3.3. Автоматические действия: снижение плана, отключение сложных форматов<br> При срабатывании триггеров запускаются заранее прописанные действия:<br> - временное снижение количества новых задач (урезание плана публикаций);<br> - приостановка сложных или низкоприоритетных форматов;<br> - перевод части материалов на упрощённый approval (шаблоны, предодобренные сообщения).<br> Это защищает систему от паралича и даёт команде шанс «расшить» очереди.<br> 3.4. Особенности при Stress/Crisis<br> 3.4.1. Упрощённые цепочки согласования<br> В Stress и особенно в Crisis действуют упрощённые цепочки:<br> - заранее подготовленные и предодобренные шаблоны сообщений, которые можно выпускать без полного круга согласований;<br> - сокращённые маршруты (например, минуя часть уровней), когда это не создаёт юридических или политических рисков.<br> Это позволяет выпускать критические сообщения за минуты, а не часы, без хаоса в полномочиях.<br> 3.4.2. Централизация формулировок<br> В высоких режимах ключевые формулировки (по инцидентам, чувствительным темам) централизуются: Crisis Cell или ядро штаба готовит и обновляет «коридор сообщений», от которого нельзя существенно отклоняться. Это снижает риск противоречивых заявлений, утечек и неконтролируемых интерпретаций в условиях повышенного внимания и давления.<br> 4. Режимы работы — операционная реализация<br> 4.1. Normal<br> 4.1.1. Цели и KPI Normal‑режима<br> В Normal‑режиме цель — устойчивое присутствие в повестке, наращивание доверия и узнаваемости без перегрева аудитории и штаба. KPI: выполнение плана волн, стабильные или растущие LI в регионах, низкий PRS, отсутствие системных инцидентов и перегруза SSI.<br> 4.1.2. Стандартный набор волн и частот<br> Используются заранее спланированные волны (ядро смысла, сервисная информация, позитивные истории, объяснения), с частотой, согласованной с CT для сегментов. Допускаются пилоты и эксперименты в формате и креативе, пока не нарушаются базовые правила стиля и не создаётся лишний шум.<br> 4.2. Attention<br> 4.2.1. Усиление мониторинга и Discovery<br> При Attention усиливается плановый мониторинг (более частые срезы, фокус на тревожных темах и P2/P3) и активнее используется Discovery‑контур для точечных разведок. Цель — быстро понять природу всплесков, новые нарративы и потенциальные источники каскада, не переходя сразу в кризисные протоколы.<br> 4.2.2. Увеличение доли разъясняющего контента<br> Нагрузка по числу сообщений не обязательно растёт, но изменяется их структура: увеличивается доля разъяснений, Q&A, «что это значит для меня», снижается доля декоративного и развлекательного контента. Задача — снижать тревожность и неопределённость, не усиливая страх и не создавая ощущение паники.<br> 4.3. Attention‑Light<br> 4.3.1. Условия включения (рост PRS без подтверждения)<br> Attention‑Light включается, когда PRS и медиасигналы растут (DI, частота упоминаний, негативная тональность), но факты и LI не подтверждают наличие реального кризиса. Это промежуточный режим: система повышает чувствительность и аккуратно проверяет сигналы, но не раскручивает кризисную машину раньше времени.<br> 4.3.2. Ограничения по тону и формам (без резкой риторики)<br> При Attention‑Light вводится мягкое ограничение: не использовать резкую, конфликтную или апокалиптическую риторику, не выпускать новые «острые» форматы по теме, пока Discovery не прояснит картину. Коммуникация строится в тоне «мы видим, мы проверяем, расскажем, как только будут факты», чтобы не усилить тревогу и не дать повода для обвинений в манипуляции.<br> 4.4. Stress<br> 4.4.1. Ужесточение координации между уровнями<br> В Stress‑режиме координация центра и регионов, а также между ведомствами становится более жёсткой: единый набор тезисов по ключевым темам, обязательные согласования по чувствительным вопросам, более частые координационные созвоны. Spontaneous‑самодеятельность и «личные трактовки» публичных заявлений минимизируются.<br> 4.4.2. Сокращение экспериментов и юмористических форматов<br> В условиях устойчивого напряжения сокращаются эксперименты с тоном и форматом, особенно ироничные и провокационные — чтобы не усугублять эмоции и не давать поводов для обиды или искажения. Фокус смещается на спокойные, объясняющие, уважительные коммуникации, поддерживающие чувство контроля и предсказуемости.<br> 4.5. Crisis<br> 4.5.1. Кризисные протоколы и коридор сообщений<br> При переходе в Crisis активируется Crisis Cell и заранее прописанные кризисные протоколы: кто говорит, что говорит, в какие сроки и через какие каналы. Формируется «коридор сообщений» — набор одобренных формулировок и ключевых тезисов, за пределы которого публичным спикерам выходить нельзя без отдельного решения.<br> 4.5.2. Применение SDM‑лайт (защитный режим контента)<br> Включается защитная логика SDM‑лайт:<br> - приоритет правдивости и понятности над «пиар‑выгодой»;<br> - отказ от любых сообщений, которые могут быть легко выдернуты из контекста и использованы против;<br> - ограничение объёма сообщений — меньше, но более точные, своевременные и прозрачные апдейты.<br> Цель — удержать доверие и минимизировать дальнейший ущерб, даже если приходится признавать неопределённость или ошибки.<br> 5. CRISIS MODE и инциденты<br> 5.1. Типология инцидентов A/B/C<br> 5.1.1. Примеры инцидентов типа A<br> Тип A — инциденты, напрямую затрагивающие безопасность людей или целостность ключевой процедуры: серьёзные нарушения на участках, угрозы жизни и здоровью, крупные аварии в день голосования, утечки критически важных персональных данных. Такие события почти автоматически поднимают режим до Crisis и требуют немедленного включения Crisis Cell.<br> 5.1.2. Примеры инцидентов типа B<br> Тип B — инциденты, подрывающие легитимность и доверие, но не несущие прямой угрозы жизни: масштабные фейки о фальсификациях, организованные кампании дискредитации, утечки внутренней переписки, вызывающей сомнения в честности процесса. При накоплении B‑инцидентов или их сочетании с высоким PRS типичный режим — Stress с элементами кризисной коммуникации по конкретным эпизодам.<br> 5.1.3. Примеры инцидентов типа C<br> Тип C — локальные или репутационные события: конфликт на встрече, одиночные скандалы, спорные высказывания отдельных представителей, локальные технические сбои, быстро устранённые. Обычно такие инциденты отрабатываются в рамках Attention, но при их «цепочке» и неверной коммуникации они могут подтолкнуть PRS вверх.<br> 5.2. Алгоритмы реагирования 30/60/180 минут<br> 5.2.1. Шаги первых 30 минут<br> Первые 30 минут после обнаружения серьёзного инцидента:<br> - фиксация факта, запуск внутреннего оповещения (штаб, Crisis Cell);<br> - сбор подтверждённой минимальной информации (что произошло, где, кого затронуло);<br> - подготовка и выпуск первого короткого сообщения: «знаем, разбираемся, действуем», без догадок и деталей.<br> 5.2.2. Действия до 60 минут<br> В течение часа:<br> - уточнение фактов, ролей и ответственности;<br> - определение спикера и ключевых тезисов;<br> - подготовка и доставка первого более содержательного заявления (через сайт, соцсети, брифинг), синхронизированного с офлайн‑действиями.<br> Цель — показать управляемость и прозрачность, не заполняя вакуум слухами.<br> 5.2.3. Развёрнутые действия до 180 минут<br> За 3 часа:<br> - запуск полноценного много канального ответа: сайт, соцсети, медиа, работа с ключевыми стейкхолдерами;<br> - выпуск разъясняющих материалов (Q&A, факты, контекст) и обновлённой информации по мере её появления;<br> - настройка постоянного цикла обновлений (например, каждые 1–2 часа) до стабилизации.<br> После этого кризисная коммуникация переходит в более устойчивый режим, но первые 3 часа критичны для формирования базового нарратива.<br> 5.3. Взаимодействие с офлайн‑контуром<br> 5.3.1. Каналы связи с силовыми/административными органами<br> В кризисе коммуникация не может существовать отдельно от реальных действий: нужны прямые и быстрые каналы связи с силовыми структурами, акиматами, избиркомами и другими вовлечёнными органами. Формализуются контактные точки, порядок эскалации и ожидания по срокам предоставления информации.<br> 5.3.2. Формат обмена информацией<br> Определяются стандартные форматы обмена: короткие оперативные бюллетени, совместные сводки, согласованные позиции по ключевым вопросам. Это снижает риск противоречивых сигналов от разных структур и помогает удерживать единую картину в публичном пространстве.<br> 5.4. Связка инцидентов и режимов<br> 5.4.1. Какие инциденты повышают режим<br> Прописано, какие сочетания тяжести и частоты инцидентов требуют смены режима:<br> - один крупный A → немедленно Crisis;<br> - несколько B подряд при высоком PRS → переход в Stress;<br> - цепочка C в одном регионе и рост тревожности/DI → минимум Attention, возможно перевод региона в P3.<br> Это уменьшает произвол и делает реакцию предсказуемой для всех участников.<br> 5.4.2. Условия возврата к более мягким режимам<br> Возврат возможен только при одновременном выполнении нескольких условий: снижение PRS, стабилизация LI и индекса тревожности, отсутствие новых инцидентов соответствующего типа в течение заданного Tdown. Это не позволяет слишком быстро «объявить победу» и открыть ворота для новой волны проблем — режим понижается только при устойчивом улучшении.<br> 6. Мониторинг и Discovery‑контур<br> 6.1. Плановый мониторинг<br> 6.1.1. Роль Brand/Scan и других систем<br> Brand/Scan‑класс системы даёт непрерывный фон: трекинг упоминаний, тональности и динамики по брендам, ключевым лицам, темам и регионам. Эти инструменты используются как базовый радар: они собирают данные из медиа и соцсетей, строят графики по упоминаниям/тональности и отправляют алерты при всплесках.<br> 6.1.2. Плановые темы и отчёты<br> Для планового мониторинга задаётся фиксированный пул тем (ядро смысла, чувствительные сюжеты, ключевые инциденты, оппоненты) и регулярные отчёты: ежедневные срезы, недельные обзоры, спец‑репорты по регионам. Структура отчётов стандартизирована (топ‑сюжеты, источники, тональность, карта по регионам), чтобы их было удобно привязывать к индексам и решениям.<br> 6.2. Ad‑hoc Discovery (по запросу)<br> 6.2.1. Формат запроса (бот/форма: поля и варианты)<br> Запрос на Discovery подаётся через бота или web‑форму: тема/ключевые слова, регион, период, тип запроса (быстрый обзор, оценка риска, карта нарративов), срочность и адресат. Это дисциплинирует постановку задач и позволяет аналитикам быстро понять, что требуется штабом.<br> 6.2.2. Workflow: Bot → Expand → Search → Fetch → Classify → Report<br> Стандартная цепочка:<br> - Bot принимает запрос и нормализует его;<br> - Expand — LLM расширяет его синонимами, эвфемизмами, языковыми вариантами;<br> - Search — запрос уходит в News/Web API, соцсети и другие источники;<br> - Fetch — сбор и первичная фильтрация релевантных документов;<br> - Classify — автоматическая классификация по темам, тональности, регионам, типам источников;<br> - Report — LLM + аналитик формируют короткий бриф для штаба с рисками и рекомендациями.<br> Такой pipeline повторяет современные практики медиа‑интеллидженса и инфодемик‑мониторинга.<br> 6.3. Источники данных и API<br> 6.3.1. News/Web API и поисковые агрегаторы<br> Используются коммерческие и открытые News/Web API и агрегаторы для новостей, онлайн‑СМИ и блогов (включая paywalled‑источники, если есть доступ). Это обеспечивает широкий охват и снижение зависимости от ручного поиска.<br> 6.3.2. Telegram/соцсети через провайдеров/скреперы<br> Данные соцсетей и Telegram берутся через специализированных провайдеров или легальные скреперы, которые дают доступ к сообщениям, комментариям, метаданным и базовой аналитике. Они критичны для кризисов и быстрых всплесков, которые могут не попасть в традиционные медиа.<br> 6.3.3. Официальные сайты и RSS<br> Официальные сайты госорганов, акиматов, избиркомов и других структур подключаются через RSS/Atom и простые парсеры. Это даёт надёжный источник «официальной версии» для сопоставления с полем и построения DI.<br> 6.4. Роль LLM в Discovery<br> 6.4.1. Расширение запросов (синонимы, эвфемизмы, RU/KZ)<br> LLM помогает расширять запросы: подбирает синонимы, эвфемизмы, сленг, а также варианты на русском, казахском и других языках, которые реально используются в поле. Это особенно важно для «мемных» обозначений, обходов фильтров и локальных формулировок.<br> 6.4.2. Кластеризация сюжетов и эмоций<br> LLM‑подсказки используются в связке с классическими методами кластеризации: помогают выделять сюжеты и эмоциональные кластеры (гнев, страх, насмешка и т.п.) внутри массивов сообщений. Это позволяет не только считать тональность, но и видеть структуру нарративов.<br> 6.4.3. Выделение новых формулировок и мемов<br> LLM может автоматически находить новые часто повторяющиеся выражения, мемы, прозвища, хэштеги и формулировки, которые становятся маркёрами нарратива. Эти находки пополняют словари мониторинга и используются в Wave Brief и контр‑нарративах.<br> 6.4.4. Генерация брифов и рекомендаций для штаба<br> По итогам Discovery LLM помогает собирать компактные брифы: «о чём шум», «кто говорит», «какие риски», «что можно сделать», которые затем проверяются аналитиком. Это снижает нагрузку на людей и ускоряет цикл от сигнала до управленческого решения.<br> 7. L‑DataIntegrity: аудит ссылок и отчётности<br> 7.1. Проблематика отчётности ради отчёта<br> 7.1.1. Типичные нарушения (битые/закрытые/нерелевантные ссылки)<br> Типичные проблемы: битые ссылки (404/500), закрытый доступ (приватные посты, внутренние страницы), нерелевантный контент (ссылка есть, но не про заявленную активность), массовый копипаст одного и того же материала в разные отчёты. Всё это создаёт ложное ощущение активности и искажает картину работы регионов.<br> 7.1.2. Влияние на индексы и решения<br> Если такие ссылки без фильтра попадают в индексы, они завышают показатели активности, снижают чувствительность PRS/SSI и мешают честно видеть проблемы. В результате решения принимаются на основе «бумажной» картины, а не реального воздействия.<br> 7.2. Конвейер проверки ссылок<br> 7.2.1. Чтение новых строк из Google Sheets / формы<br> Все отчёты регионов стекаются в единую таблицу/форму (например, Google Sheets), откуда автоматический процесс периодически считывает новые строки с URL и метаданными. Это отправная точка для последующих проверок.<br> 7.2.2. Техническая проверка (HTTP‑коды, редиректы, доступность)<br> Первый слой — технический: для каждого URL проверяются HTTP‑код, финальный адрес после редиректов, время ответа, наличие блокировок или капчи. Это позволяет быстро отсечь битые, недоступные или явно проблемные ссылки.<br> 7.2.3. Контентный минимум (наличие текста, соответствие теме)<br> Далее проверяется контентный минимум: есть ли на странице текст/медиа достаточного объёма, соответствует ли тема заявленной активности (по ключевым словам, названию региона, дате). Для этого можно использовать лёгкий NLP‑анализ и проверку на ключевые слова из отчётной строки.<br> 7.2.4. Детекция дубликатов и массовых копипаст<br> Система ищет дубликаты: одинаковые URL в разных строках, очень похожий текст/метаданные (шаблонные репосты, рефреш одного релиза). Это позволяет не засчитывать массовый копипаст как десятки отдельных достижений.<br> 7.3. Структура `link_audit`<br> 7.3.1. Поля: url, status, quality_score, flags, verdict<br> Для каждой проверенной ссылки создаётся запись `link_audit` с полями:<br> - `url` — исходный адрес;<br> - `status` — технический статус (ok, error_404, private, timeout и т.п.);<br> - `quality_score` — численный показатель качества/релевантности;<br> - `flags` — список флагов (duplicate, low_content, off_topic и др.);<br> - `verdict` — итоговое решение (OK/FAIL/REVIEW).<br> Это становится частью SSOT и может использоваться всеми контурами.<br> 7.3.2. Связь с отчётной строкой и регионом<br> `link_audit` связывается с исходной отчётной строкой (ID записи, регион, период, тип активности), что позволяет автоматически пересчитывать показатели региона и кампании. Так регион видит, какие именно ссылки не прошли и почему.<br> 7.4. Региональный compliance<br> 7.4.1. Метрики ok_rate, fail_rate, avg_quality<br> Для каждого региона считаются:<br> - `ok_rate` — доля ссылок с вердиктом OK;<br> - `fail_rate` — доля FAIL;<br> - `avg_quality` — средний quality_score по принятым ссылкам.<br> Эти метрики входят в оценку работы региона и могут учитывать как честность, так и качество активности.<br> 7.4.2. Пороговые зоны и автоматические алерты<br> Вводятся пороги: при падении `ok_rate` ниже X% или росте `fail_rate` выше Y% автоматически уходят алерты региону и Regional Desk, а при систематическом нарушении — сигнал руководству. Это стимулирует регионы следить за качеством отчётности, а не только за количеством строк.<br> 7.5. Управленческие правила<br> 7.5.1. Что засчитывается/не засчитывается автоматом<br> Автоматически засчитываются только ссылки с вердиктом OK и достаточным quality_score; FAIL не учитываются ни в KPI, ни в индексах. Для них могут действовать санкции или ограничения, если нарушения повторяются.<br> 7.5.2. REVIEW и выборочная ручная проверка<br> Для ссылок с вердиктом REVIEW (пограничные случаи, сложные форматы) применяется выборочная ручная проверка по заданной выборке (например, X% от общего числа). Это позволяет улучшать алгоритмы и не наказывать регионы за технические особенности, которые автоматике трудно трактовать.<br> 7.5.3. SLA исправления и пересдачи для регионов<br> Регионы получают SLA на исправление: в течение, например, 3–5 дней после отчёта они могут заменить FAIL‑ссылки валидными или пояснить ситуацию. Невыполнение SLA фиксируется в отдельном индикаторе compliance и может влиять на оценку работы и поддержку региона ресурсами.<br> 1. Дашборд руководства<br> 1.1. Главный экран<br> 1.1.1. Режим дня и PRS<br> В верхнем блоке — текущий режим (Normal/Attention/Stress/Crisis) и значение PRS‑лайт, с кратким текстовым пояснением («фон стабилен», «усиленное внимание», «устойчивое напряжение», «кризис»). Это позволяет ЛПР за секунды понять обстановку и ожидаемый стиль работы штаба.<br> 1.1.2. Карта P1/P2/P3 с LI/PRS<br> Ниже — интерактивная карта регионов с раскраской по P1/P2/P3 и всплывающими значениями LI и регионального вклада в PRS. Такой geo‑дашборд делает видимыми «точки напряжения» и помогает фокусировать внимание и ресурсы.<br> 1.1.3. SSI штаба и CT по ключевым сегментам<br> Отдельный блок показывает SSI (структурный стресс штаба) и CT по нескольким ключевым сегментам аудитории (например, «молодёжь», «госслужащие», «МСП»). Это даёт сигнал о перегрузе как внутри команды, так и снаружи, влияя на решения по объёму и формату коммуникаций.<br> 1.2. Панель L‑Influence<br> 1.2.1. Распределение площадок по tier<br> Быстрый виджет: сколько площадок в A/B/C/D по стране и по выбранному региону, с тенденцией (улучшается/ухудшается). Это отражает «здоровье» инфраструктуры влияния.<br> 1.2.2. Топ площадок и проблемные площадки по регионам<br> Список топ‑площадок (по охвату и Trust Score) и проблемных (низкий Trust, флаги, инциденты), с фильтрацией по регионам. Руководитель видит, где опираются на надёжные каналы, а где есть риск «фантомных» или токсичных аудиторий.<br> 1.3. Панель L‑DataIntegrity<br> 1.3.1. ok_rate/fail_rate по регионам<br> Теплокарта или бар‑чарт `ok_rate` и `fail_rate` по регионам, с подсветкой аутлайеров. Это позволяет быстро увидеть, где отчётность системно проблемная и требует вмешательства.<br> 1.3.2. Динамика качества отчётности<br> График динамики `avg_quality` и расхождения между заявленной и реально подтверждённой активностью. Он помогает оценивать эффект регламентов и обучения регионов.<br> 2. Операционный дашборд штаба<br> 2.1. Approval‑центр<br> 2.1.1. Очереди по статусам и SLA<br> Операционный дашборд показывает очереди материалов по статусам (черновик, на согласовании, готов к публикации, опубликован) и средние времена обработки по каждому шагу. Цветовые индикаторы показывают, где SLA превышены и где формируется «бутылочное горлышко».<br> 2.1.2. Перегруз и автоматические сигналы<br> При превышении порогов по длине очереди или SLA визуально и через алерты сигнализируется перегруз approval‑центра. Это может автоматически запускать сценарии упрощения процедур и сокращения плана.<br> 2.2. Мониторинг/Discovery<br> 2.2.1. Лента ad‑hoc запросов и статусы<br> Отображается лента Discovery‑запросов (тема, регион, срочность) и их статусы: в работе, ожидание ответа, завершено, эскалация. Это позволяет штабу видеть, какие вопросы «висят» и где может задерживаться принятие решений.<br> 2.2.2. Последние high‑risk сюжеты<br> Отдельный блок подсвечивает сюжеты с высоким риском: всплески негативной тональности, новые нарративы, связанные с P2/P3 регионами или чувствительными темами. Лента обновляется в реальном времени и служит для оперативных обсуждений в ходе дня.<br> 2.3. Региональный блок<br> 2.3.1. Выполнение планов по размещениям<br> Показывается выполнение планов размещений по регионам: сколько активностей запланировано и выполнено, по каким сегментам и площадкам. Это помогает координаторам и руководству видеть отстающих и перегруженных.<br> 2.3.2. Качество площадок и ссылок по регионам<br> Здесь же отображаются `ok_rate`, `avg_quality` и распределение tier площадок, на которые опирается регион. Это связывает количественные KPI с качеством инфраструктуры и отчётности.<br> 3. Регламент работы с регионами<br> 3.1. Формат отчётности<br> 3.1.1. Структура таблиц/форм, обязательные поля<br> Регламент описывает структуру отчётной формы: дата, регион, тип активности, `platform_id` из `accounts`, URL, охват/метрики, краткое описание, целевой сегмент. Чёткий перечень обязательных полей снижает вариативность и облегчает автоматическую обработку.<br> 3.1.2. Примеры корректного заполнения<br> Прилагаются примеры «правильных» строк для разных типов активностей (официальное сообщение, мероприятие, работа через инфлюенсера), а также типичные ошибки. Это помогает регионам быстро выровнять практику.<br> 3.2. Требования к ссылкам<br> 3.2.1. Допустимые типы ссылок и площадок<br> Разрешённые: ссылки на материалы в официальных аккаунтах, медиа, согласованных инфлюенсерах и площадках из реестра A/B/C. Отдельно описываются правила для офлайн‑активностей (фото/видео/отчёты на официальных ресурсах).<br> 3.2.2. Недопустимые случаи (личные профили, закрытые/удалённые)<br> Запрещено использовать личные закрытые профили, временные сторис без сохранения, ссылки, ведущие на удалённый контент, а также площадки из запрещённого tier D. Такие случаи автоматически получают FAIL в `link_audit` и не засчитываются.<br> 3.3. Использование реестра площадок<br> 3.3.1. Выбор площадки из `accounts`<br> При планировании и отчётности регион обязан выбирать площадку из `accounts`; если нужной площадки нет, требуется инициировать её добавление. Это обеспечивает единый учёт и применение Trust Score.<br> 3.3.2. Процедура добавления новой площадки<br> Регламент описывает, как добавить новую площадку: заявка (формальные данные и ссылки), первичный скоринг, возможный тестовый период. До завершения процедуры площадка может иметь ограниченный статус (probation).<br> 3.4. Обратная связь и санкции<br> 3.4.1. Еженедельные отчёты по качеству региона<br> Штаб формирует для регионов еженедельные отчёты: `ok_rate`, `fail_rate`, `avg_quality`, доля размещений на A/B‑площадках, типичные ошибки. Это превращает контроль качества в регулярную обратную связь, а не только повод для претензий.<br> 3.4.2. Листы пересдачи и корректирующие действия<br> При систематических проблемах регион получает «лист пересдачи»: перечень исправляемых пунктов (замена FAIL‑ссылок, приведение к требованиям, улучшение выбора площадок) и сроки. Невыполнение может вести к управленческим последствиям (ограничение автономии, усиленный контроль, приоритетная поддержка по обучению).<br> 4. Плейбуки по режимам<br> 4.1. Normal Mode Playbook<br> 4.1.1. Типовые сценарии и сообщения<br> В Normal используются сценарии «поддержания фона»: регулярные волны по ядру смысла, сервисные сообщения, позитивные истории, отчёты о результатах, планы на будущее. Сообщения строятся в спокойном, объясняющем тоне, с акцентом на прозрачность, пользу и предсказуемость.<br> 4.1.2. Примеры успешных кейсов<br> Плейбук содержит подборку кейсов, где плановые волны приводили к росту доверия и снижения DI/тревожности, с разбором: какие форматы, частоты и площадки сработали. Это база для обучения новых сотрудников и регионов.<br> 4.2. Attention Mode Playbook<br> 4.2.1. Форматы разъяснений, Q&A, FAQ<br> При Attention активируются шаблоны разъясняющих материалов: «что происходит», Q&A по критическим темам, обновляемые FAQ, инфографика, короткие видео‑объяснения. Плейбук содержит готовые структуры: какие вопросы обязательно покрыть, как объяснять сложные решения и ограничения.<br> 4.2.2. Работа с тревогой и недоверием<br> Рекомендуется повышенный уровень эмпатии, признание неопределённости, объяснение логики действий и указание, когда и какие обновления будут. Используются техники снижения психологической реактивности: выбор формулировок, избегание морализаторства и давления.<br> 4.3. Attention‑Light Playbook<br> 4.3.1. Шаблон поведения при ложной тревоге<br> Плейбук задаёт поведение при подозрении на ложную тревогу: быстрое признание, что сигнал проверяется, обещание сообщить результат проверки и отсутствие драматизации. Внутри команды — усиление мониторинга и Discovery, но без публичного раздувания темы.<br> 4.3.2. Примеры “overreaction” и как их избегать<br> Отдельный раздел посвящён ошибкам чрезмерной реакции: преждевременные жёсткие заявления, агрессивная полемика, ввод чрезмерных ограничений без фактов. Плейбук предлагает альтернативные формулировки и шаги, которые позволяют сохранять контроль, не усугубляя ситуацию.<br> 4.4. Stress Mode Playbook<br> 4.4.1. Ужесточение сообщений и координации<br> В Stress усиливается централизованный контроль сообщений: вводятся обязательные тезисы, единые формулировки, частые брифинги с ключевыми спикерами. Плейбук описывает, какие темы требуют согласования через Crisis Cell или руководство и какие форматы временно ограничиваются.<br> 4.4.2. Перестройка волн на стабилизацию<br> Часть плановых активностей сворачивается или переносится; новые волны фокусируются на стабилизации: «что остаётся неизменным», «что мы контролируем», «какие меры приняты». Плейбук предлагает примеры таких стабилизирующих сообщений и рекомендаций по тону.<br> 4.5. Crisis Mode Playbook<br> 4.5.1. Шаблоны сообщений по A/B/C‑инцидентам<br> Для типов A/B/C подготовлены сценарные плейбуки с шаблонами: первая «holding statement», уточняющее сообщение, Q&A, обновления. В каждом шаблоне — слоты для фактов, времени следующего апдейта, контактов и ссылок на дополнительные источники.<br> 4.5.2. Разделение внешних/внутренних коммуникаций<br> Плейбук чётко разделяет внешние (медиа, соцсети, граждане) и внутренние коммуникации (сотрудники, партнёры, регионы). Для внутренних сообщений предусмотрены отдельные брифы и FAQ, чтобы избежать ситуации, когда сотрудники узнают о кризисе из новостей.<br> 5. Стресс‑тест «Идеальный шторм»<br> 5.1. Описание сценария<br> 5.1.1. Комбинация тех/соц/инфо отказов<br> Сценарий «Идеальный шторм» комбинирует одновременно технические сбои (частичный отказ IT/каналов), социальные факторы (всплеск тревоги/протестной активности) и информационные удары (фейки, утечки, атаки по доверенным площадкам). Цель — проверить систему на пределе, а не только по отдельным осям.<br> 5.1.2. Цели теста (выявление разрывов)<br> Основная задача — выявить разрывы в координации, режимном двигателе, approval‑флоу, взаимодействии с регионами и офлайн‑структурами. Тест показывает, где план «на бумаге» не срабатывает в динамике реальных решений.<br> 5.2. Подготовка к тесту<br> 5.2.1. План, роли, тестовые данные<br> Готовится сценарный план с временной шкалой, распределяются роли (штаб, регионы, Crisis Cell, внешние стейкхолдеры), подготавливаются тестовые данные и «вбросы». Важно заранее настроить, какие системы будут использоваться (дашборды, каналы связи) и что имитируется.<br> 5.2.2. Инструкции участникам<br> Участники получают инструкции: рамки игры, правила, что считать «реальным» и как фиксировать решения. При этом сохраняется элемент неожиданности, чтобы не превратить тест в театральную постановку.<br> 5.3. Проведение теста<br> 5.3.1. Ход событий по временной шкале<br> Сценарий разворачивается по ступеням: сначала один инцидент, затем нарастающие события (дополнительные фейки, отказы, реакция регионов). На каждом шаге фиксируются решения, время реакции, смена режимов и взаимодействие между командами.<br> 5.3.2. Фиксация реакций системы<br> Важно собирать не только лог событий, но и наблюдения: где возникли задержки, непонимание полномочий, противоречивые сообщения. Это создаёт основу для качественного разбора после теста.<br> 5.4. Критерии успешности<br> 5.4.1. Режимы и гистерезис отработали без дребезга<br> Успех — если режимный двигатель не «дребезжит», а переходит между режимами по понятным правилам, без резких необоснованных скачков туда‑обратно. Это показывает, что пороги и окна Tup/Tdown настроены адекватно.<br> 5.4.2. Fallback‑процедуры сработали<br> Проверяется, смогли ли команда и системы перейти на резервные каналы, процедуры и шаблоны (например, при отказе части IT или недоступности ключевых лиц). Если да — стресс‑тест подтверждает реальную устойчивость, а не только теоретическую готовность.<br> 5.4.3. Отчётность не разрушена<br> Даже в пике нагрузки должны сохраняться минимум данных: журнал событий, ключевые решения, основные коммуникации. Это необходимо для последующего анализа и для внешней отчётности, если требуется.<br> 5.5. Итоговый отчёт<br> 5.5.1. Выводы и выявленные слабые места<br> По итогам составляется структурированный отчёт: сильные стороны, слабые места, узкие горлышки, конфликты полномочий, технические и процедурные сбои. Документ привязывается к конкретным эпизодам сценария и метрикам.<br> 5.5.2. План корректировок<br> На основе отчёта формируется план изменений: доработка плейбуков, пересмотр порогов и ролей, улучшение дашбордов, дополнительное обучение. Регулярные повторения теста позволяют измерять прогресс и встроить стресс‑тестирование в культуру управления кампанией.<br> 6. Шаблоны и приложения<br> 6.1. Формы и анкеты<br> 6.1.1. Форма ad‑hoc запроса (бот/форма)<br> Форма Discovery‑запроса включает поля: инициатор (ФИО/подразделение), тема/ключевые слова, регион, период, цель запроса (обзор, оценка риска, карта нарративов), срочность, желаемый формат ответа (1‑страничный бриф, расширенный отчёт). Дополнительно можно указать ссылки на исходные материалы или скриншоты, если запрос родился из конкретного эпизода.<br> 6.1.2. Форма добавления площадки в `accounts`<br> Форма заявки в реестр площадок содержит: платформу, handle/URL, описание площадки, регион/язык аудитории, примерный охват, тип владельца, примеры контента, ссылки на аналитические данные (если есть). Отдельный блок — предварительная самооценка рисков (тематика, возможные конфликты, прошлые скандалы).<br> 6.2. Шаблоны отчётов<br> 6.2.1. Ежедневный операционный отчёт<br> Структура: режим дня, ключевые индексы (PRS, SSI, DI, CT по сегментам), основные события и инциденты, выполненные волны/активности, статус очередей в approval, краткие выводы и решения. Такой отчёт должен помещаться на 1–2 страницы и быть готов к утреннему слоту.<br> 6.2.2. Еженедельный региональный отчёт<br> По региону: P‑статус, LI и тревожность, выполнение планов по размещениям, `ok_rate/fail_rate/avg_quality`, структура использованных площадок по tier, ключевые нарративы недели и инциденты. В конце — блок обратной связи: рекомендации штаба и план корректирующих действий.<br> 6.3. Примеры записей `accounts` и `link_audit`<br> 6.3.1. Записи с verdict OK/FAIL/REVIEW<br> Для обучения приводятся анонимизированные примеры:<br> - OK: валидная ссылка на согласованную площадку, релевантный контент, достаточный объём.<br> - FAIL: 404, приватный пост, не по теме, площадка из tier D.<br> - REVIEW: нестандартный формат, агрегаторы, контент, сложный для автоматической оценки.<br> 6.3.2. Типовые комбинации flags и их трактовка<br> Пособие описывает, как трактовать `flags`: например, `low_content + duplicate` (копипаст короткого релиза), `off_topic`, `suspicious_platform`. Для каждой комбинации указано, когда возможен перевод из REVIEW в OK/FAIL после ручной проверки.<br> 6.4. Словарь терминов<br> 6.4.1. Индексы (SSI, DI, NI, PRS, LI, CT)<br> Словарь даёт краткие, операционные определения индексов: что измеряет, диапазон, базовые пороги и пример управленческого действия при выходе за них. Формулировки рассчитаны на ЛПР и региональных координаторов, без лишней математики.<br> 6.4.2. Режимы (Normal/Attention/Stress/Crisis)<br> Для каждого режима указаны условия включения, основные принципы коммуникации и ключевые ограничения (форматы, тон, согласование). Это позволяет участникам быстро вспомнить, «что можно и что нельзя» в текущем режиме.<br> 6.4.3. Слои (структурный, смысловой, когнитивный, данные, площадки)<br> Описание L‑Structure, L‑Narrative, L‑Cognitive, L‑DataIntegrity, L‑Influence в виде кратких абзацев: за что отвечает слой, какие решения в нём принимаются, какие индексы и инструменты к нему привязаны. Словарь помогает новым участникам быстрее освоиться в архитектуре системы и языке штаба.