paste.txt

ChatGPT neutral 2026-04-11 42 чанков ~60 мин чтения

Сущности

PR PSSR

PSSR — консолидированный пакет документов (редакция без англицизмов) Документ собран как единый пакет для чтения и работы. В тексте используются русские профессиональные термины; заимствованные термины сведены в глоссарий и сохраняются только как идентификаторы, где это критично для совместимости схем и интерфейсов. Статус пакета: аналитическая и обучающая надстройка. Документ 1. PSSR 8.2+ (канон) PSSR 8.2+ **Текущий статус применения: аналитическая и обучающая надстройка над действующими процедурами; система не является обязательным регламентом и не замещает правовые и ведомственные нормы.** I. Паспорт системы I.1. Назначение и статус PSSR как системы управления критическими процессами PSSR (Public Stability & Stress Response) представляет собой формализованную систему управления критическими процессами в условиях неопределённости, давления и деградации среды. Система предназначена для применения в ситуациях, где стандартные управленческие процедуры утрачивают достаточность из-за высокой плотности рисков, конфликтов интересов, информационного шума и правовых ограничений. PSSR не является коммуникационной методикой, PR-фреймворком или идеологической доктриной. Система фиксируется как инженерная управляющая спецификация, предназначенная для обеспечения минимально допустимого уровня управляемости, легитимности и воспроизводимости решений в кризисных и пограничных режимах. Статус PSSR – внутренняя операционная система принятия решений, применяемая поверх существующих институтов и регламентов без их подмены. PSSR не отменяет отраслевые нормы, законы или ведомственные процедуры и не претендует на автономное «право действия». I.2. Границы применимости, запретные зоны и недопустимые подмены PSSR применяется исключительно в зонах, где одновременно присутствуют: высокий уровень неопределённости, риск эскалации последствий, ограниченное время на принятие решений, повышенная чувствительность к ошибкам. Система не применяется: для оправдания заранее принятых политических или управленческих решений; как инструмент легитимации незаконных действий; как замена следственным, судебным или правоприменительным процедурам; как способ делегирования ответственности «на протокол». Недопустимой подменой считается использование PSSR: в качестве алиби постфактум, для имитации управляемости, для подавления институционального несогласия, для обхода требований закона под видом «кризисной необходимости». Любое использование системы за пределами этих границ квалифицируется как нарушение инвариантов и подлежит фиксации в контуре ошибок и злоупотреблений. I.3. автономный режим как базовая безопасная конфигурация и условия включения сетевой-контура Базовой конфигурацией PSSR является автономный режим режим. В этой конфигурации система предполагает: ручное принятие решений, автономную фиксацию фактов, отсутствие зависимости от сетевых сервисов, минимальный цифровой след. сетевой контур рассматривается как расширение, а не как норма. Его включение допускается только при одновременном выполнении следующих условий: подтверждена целостность данных; обеспечена воспроизводимость логов; отсутствует риск компрометации операторов; зафиксированы условия аварийного отключения и возврата в автономном режиме. Нарушение любого из условий автоматически инициирует откат в автономный режим без права «мягкого продолжения». I.4. Принцип «сжатия под нагрузкой» как операционная норма и критерий работоспособности Ключевым принципом PSSR является принцип «сжатия под нагрузкой». Он означает, что при росте давления система: уменьшает количество допустимых действий, сокращает спектр интерпретаций, упрощает язык и формы решений, отбрасывает вторичные цели и метрики. Работоспособность системы оценивается не по полноте реакции, а по способности сохранить управляемость при упрощении. Любая реакция, приводящая к усложнению контуров под давлением, считается признаком отказа системы. I.5. Совместимость и маппинг на внешние стандарты и рамки (аудит и комплаенс) PSSR проектируется как система, совместимая с внешними стандартами управления, аудита и устойчивости. Совместимость не означает прямого соответствия формулировкам стандартов, но предполагает маппинг по функциям и контрольным точкам. PSSR допускает сопоставление с международными и национальными рамками (в том числе в сфере устойчивости, непрерывности, кибербезопасности, управления рисками) исключительно в целях: внешнего аудита, комплаенс-оценки, институциональной интеграции. Ни один внешний стандарт не может быть использован для изменения ядра системы без прохождения процедур эволюции и патчинга. I.6. минимум доказуемости: минимальные требования к доказуемости решений, следам и воспроизводимости минимум доказуемости определяет минимальный набор требований, без выполнения которых любое решение в рамках PSSR считается недействительным с точки зрения системы. К базовым требованиям относятся: фиксация факта принятия решения; указание альтернатив, которые были рассмотрены и отвергнуты; привязка решения к режиму, контуру и ограничениям; возможность ретроспективной реконструкции хода рассуждений. доказуемость не является опцией или дополнительным слоем. Отсутствие воспроизводимости автоматически квалифицируется как дефект системы независимо от фактического результата решения. I.7. Внешние ограничения: закон, ресурсы, физическая выполнимость PSSR изначально исходит из наличия внешних ограничений, не подлежащих интерпретации или смягчению внутри системы. К таким ограничениям относятся: императивные нормы закона, физические и ресурсные пределы, институциональные запреты и мандаты. Конкретные механизмы учёта внешних ограничений реализуются через: Resource Layer (II.7) – ограничения по времени, людям, бюджету и полномочиям; правовой контур (L-Law) – юридические триггеры и hard-interrupt; слой подтверждённых фактов (II.6) – фиксацию фактической реальности; отраслевые и специальные домены IX.10–IX.11. PSSR не устраняет внешние ограничения и не компенсирует их. При столкновении протокола с внешним ограничением система обязана остановить или упростить режим, а не «адаптировать интерпретацию». II. Архитектура PSSR II.1. Иерархия слоёв и архитектурная диаграмма машины управления Архитектура PSSR построена как иерархическая машина управления с жёстким приоритетом ограничений над интерпретациями. Слои системы не равноправны и не могут «торговаться» между собой. Фиксированная иерархия приоритетов: L0 (Инварианты) → L-Law / Resource Layer (внешние hard-ограничения) → L1 (Смысловые опоры и идеология процедур) → L2 (Контуры управления) → L3 (Режимы и состояния) → L4 (Протоколы действий) → L5–L6 (Защита исполнения) Любая попытка интерпретации, нарушающая этот порядок, считается архитектурным дефектом. Архитектура проектируется как машина с принудительными остановками, а не как «поток решений». Возможность остановки и деградации является штатной функцией, а не аварийным сценарием. II.2. FMEA ядра и отказоустойчивость Для ядра PSSR применяется принцип предварительного анализа отказов (Failure Modes and Effects Analysis). К базовым типам отказов относятся: отказ из-за перегрузки интерпретациями; отказ из-за конфликта контуров; отказ из-за утраты доверия к данным; отказ из-за правового конфликта; отказ из-за ресурсного истощения. Для каждого типа отказа архитектура предусматривает: компенсатор (упрощение, остановка, откат); контур фиксации (журналирование); запрет на «героическое продолжение» при утрате условий выполнимости. PSSR считается устойчивой не тогда, когда избегает отказов, а когда отказы локализуются и не каскадируют. II.3. Слои L0–L6: от инвариантов к защите исполнения Слои PSSR представляют собой не функциональные модули, а уровни допустимости решений. L0 определяет, что в принципе допустимо. L1 – почему допустимое имеет смысл. L2 – в каком управленческом контуре действует система. L3 – в каком состоянии находится среда. L4 – какие действия разрешены. L5–L6 – как предотвратить разрушение исполнения. Ни один нижележащий слой не может расширять допустимость, заданную вышележащим. Нижние слои могут только сужать пространство действий. II.4. Слои данных и метрик: L7 и L10 как входы управления, ограничения доверия к данным L7 (сырые данные) и L10 (агрегированные метрики) рассматриваются не как источники истины, а как ограниченные входы управления. Принципиальные положения: данные не обладают приоритетом над инвариантами; метрики не могут отменять правовые или ресурсные ограничения; отсутствие данных является допустимым состоянием и должно быть зафиксировано явно. Любая автоматическая агрегация обязана учитывать: степень доверия к источнику, наличие культурных и контекстных искажений, возможную компрометацию ретроспективных данных. II.5. Эволюция и патчи как код: GitOps, версионирование и откаты PSSR развивается по принципу управляемых патчей, а не «тихих правок». Каждое изменение: имеет версию; имеет автора и обоснование; проходит фиксацию в журнале эволюции; может быть откачено. Изменения ядра (L0–L1) требуют отдельной процедуры и не могут вноситься через доменные накладки или цифровые механизмы. II.6. слой подтверждённых фактов: фиксация фактической реальности слой подтверждённых фактов предназначен для фиксации фактов, не зависящих от интерпретации системы. Ключевые свойства слоя: минимальная обработка; приоритет наблюдаемого над объяснимым; допустимость неполноты и фрагментарности. Этот слой служит якорем против симуляции реальности и «закрытых контуров самоубеждения». II.7. Resource Layer: физические и институциональные пределы Resource Layer фиксирует предельные возможности системы по трём типовым единицам: время (часы, окна реакции); ресурсы (люди, бюджет, инфраструктура); полномочия (мандат, юридический статус). При падении любого ключевого показателя ниже порога, заданного в доменной накладке: режим обязан быть автоматически снижен или заблокирован; запрещается продолжение действий «по инерции»; фиксируется причина остановки как внешнее ограничение. II.P. Превентивный слой (L-Pre): риск-реестр и предкризисные прогоны L-Pre предназначен для выявления уязвимостей до входа в кризисные режимы. Слой включает: реестр рисков; сценарии развития; пороги перехода; предкризисные симуляции. L-Pre не отменяет реактивную часть PSSR, но снижает вероятность ложной уверенности и внезапного входа в L3 без подготовки. III. L0 Инварианты III.1. Статус инвариантов и приоритет ядра Инварианты L0 являются неделимой основой PSSR и имеют безусловный приоритет над всеми остальными слоями, доменами, фасадами и протоколами системы. Ни один контур управления, режим, доменная накладка или цифровая надстройка не может приостанавливать, обходить или переопределять инварианты L0. Инварианты действуют непрерывно, не зависят от режима (норма, кризис, защита, процессуальный режим) и сохраняют силу при деградации системы, переходе в автономном режиме-only и при аварийном отключении сетевой-контура. Любая попытка «временного» ослабления инвариантов, их интерпретации как рекомендаций или условных ограничений квалифицируется как дефект архитектуры или злоупотребление полномочиями. III.2. Запрет «протокола вместо ответственности» PSSR не является субъектом ответственности и не может использоваться как инструмент её подмены. Ни одно решение не считается легитимным только на основании того, что оно «соответствует протоколу». Оператор, должностное лицо или коллегиальный орган сохраняют полную персональную и институциональную ответственность за последствия решений, даже если они приняты в строгом соответствии с PSSR. Формулировки вида «система не позволила», «алгоритм определил», «режим автоматически активировался» запрещены в управленческой, публичной и внутренней коммуникации. III.3. Запрет преждевременных выводов и симуляции факта PSSR запрещает признание факта до его верификации через слой подтверждённых фактов и протокол VII.1. Любые выводы, интерпретации, обвинения или управленческие действия, основанные на непроверенных данных, слухах, медиасигналах или аналитических предположениях, квалифицируются как симуляция реальности. Система допускает состояние неопределённости и незнания как рабочее, но не допускает его маскировку под знание. III.4. Запрет двойного языка и рассинхронизации смыслов В PSSR запрещено одновременное использование разных интерпретаций одного и того же факта в разных контурах (внутреннем, публичном, S-Ops, цифровом). Любая допустимая дифференциация формулировок должна быть явно зафиксирована как фасадное различие, не затрагивающее смысл, причинно-следственные связи и юридическую оценку события. Двойной язык рассматривается как источник утраты управляемости и подрыва доверия. III.5. Норма признания неопределённости Отсутствие данных, противоречивость сигналов или невозможность быстрой верификации не являются дефектом управления. PSSR признаёт неопределённость допустимым и честным состоянием системы. Попытка «закрыть пустоту» догадками, эвфемизмами или избыточными интерпретациями запрещена. Допустимая формулировка неопределённости имеет приоритет над ложной определённостью. III.6. Норма конфликтности как управляемого явления Конфликт интересов, целей, интерпретаций и доменных требований рассматривается как нормальное состояние сложных систем. PSSR запрещает подавление конфликтов путём замалчивания, административного давления или фасадной гармонизации. Разрешение конфликтов осуществляется исключительно через предусмотренные механизмы (VII.7), с явной фиксацией приоритетов и последствий. III.7. доказуемость First Любое решение, принятое в рамках PSSR, должно быть наблюдаемым, проверяемым и воспроизводимым постфактум. Отсутствие следов решения, невозможность восстановления логики выбора или разрыв между заявленным и фактическим действием квалифицируются как системный дефект, независимо от результата. Удобство, скорость и политическая целесообразность не могут служить основанием для отказа от auditability. III.8. Запрет фантомных сигналов и постфактум-рационализации PSSR запрещает ретроспективное «достраивание» причин, сигналов или мотиваций для оправдания уже принятого решения. Если решение было принято в условиях неполной информации, это должно быть зафиксировано как таковое, без попытки задним числом представить его как результат точного расчёта. Фантомные сигналы рассматриваются как источник ложного обучения системы и подрыва институциональной памяти. III.Law. Приоритет императивной нормы закона (принудительная остановка) Закон является внешним по отношению к PSSR силовым полем и рассматривается как принудительная остановка, а не как интерпретируемая часть системы. PSSR не интерпретирует, не смягчает и не адаптирует императивные нормы закона. Любой прямой или косвенный конфликт между внутренним протоколом, режимом или рекомендацией PSSR и нормой закона приводит к автоматической остановке соответствующего режима и переходу в процессуально допустимое состояние. В частности: статус «Подозреваемый» или «Обвиняемый» автоматически активирует процессуальный режим VI.9 без альтернатив; протоколы коммуникации, деэскалации и фасадов немедленно подчиняются юридическим ограничениям; любые попытки использовать PSSR как аргумент для обхода требований УПК, КоАП или иных императивных норм запрещены. Нарушение данного инварианта квалифицируется как критический сбой системы. IV. L1 Смысловые опоры и процедурная идеология IV.1. Процедурность как форма устойчивости, а не самоцель L1 фиксирует набор смысловых и процедурных опор, обеспечивающих устойчивость управления в условиях неопределённости, давления и конфликтов интересов. Процедура в PSSR рассматривается не как формальность и не как защита от ответственности, а как инструмент удержания управляемости, позволяющий принимать решения без разрушения институционального доверия и без утраты воспроизводимости. Процедурность не подменяет мышление, но ограничивает импульсивность, произвол и постфактум-рационализацию. IV.2. Примат наблюдаемого действия над декларацией В рамках PSSR значимым считается только то, что приводит к наблюдаемому действию или измеримому эффекту. Декларации, заявления о намерениях, обещания, а также формулировки без операционного продолжения не считаются управленческим актом. Любое расхождение между заявленным действием и фактически совершённым фиксируется как дефект исполнения, независимо от мотивации. IV.3. Проверяемость как норма управленческого языка L1 устанавливает стандарт различения факта, версии, оценки и гипотезы. Факт – это утверждение, прошедшее протокол подтверждения (VII.1) и привязанное к источнику подтверждённый факт. Версия – допустимая интерпретация, не имеющая статуса факта. Оценка – суждение оператора, не являющееся входом для L0–L3. Запрещается использование оценочных формулировок в качестве фактов, а также «склеивание» этих уровней в публичной или внутренней коммуникации. IV.4. Предел процедурности и границы автоматизации Процедуры и автоматизация применимы только до той границы, за которой они не разрушают субъектность оператора и не создают иллюзию автономного управления. Любой автоматизированный вывод, рекомендация или триггер в PSSR рассматривается как вспомогательный, если иное не вытекает напрямую из нормы закона (см. III.Law). L1 запрещает делегирование моральной, политической или юридической ответственности алгоритмам. IV.5. Ошибка как допустимое состояние и механизм восстановления доверия PSSR признаёт возможность ошибки как неизбежную характеристику сложных систем. Критичным является не сам факт ошибки, а её сокрытие, рационализация или подмена задним числом. Добросовестное признание ошибки, фиксация причин и корректирующие действия рассматриваются как механизм восстановления доверия, а не как слабость управления. IV.6. Казахстан-специфические опоры и культурный контур L1 фиксирует допустимые рамки смыслов, формулировок и управленческих подходов, вытекающих из институционального, культурного и политического контекста Республики Казахстан. Культурный контур определяет: допустимые идеологемы и табу; чувствительные исторические и социальные темы; границы публичного языка и символического поведения. Этот контур не изменяет инварианты L0 и не может использоваться для оправдания незаконных или недоказуемых действий. IV.7. Интерпретация права как процедурная дисциплина (не закон) L1 допускает только процедурную интерпретацию правовых норм в части их применения к коммуникации, последовательности действий и управленческой логике. Интерпретация в L1 не может: отменять или смягчать императивную норму закона; вводить альтернативные трактовки статусов, определённых законом; использоваться для обхода процессуальных ограничений. При любом конфликте между интерпретацией в L1 и нормой закона приоритет автоматически переходит к III.Law (принудительная остановка). IV.8. Контур «слышащего государства» как источник данных, а не легитимации Механизмы общественных советов, экспертных групп и обратной связи рассматриваются в PSSR как источники сигналов и интерпретаций, а не как инструмент легитимации заранее принятых решений. Запрещена симуляция диалога, использование общественных механизмов в качестве фасада или аргумента прикрытия. Данные, полученные через этот контур, подлежат тем же требованиям проверяемости и журналирования, что и любые другие входы L7. IV.9. Запрет идеологической подмены и «ценностного перегруза» PSSR запрещает использование идеологических конструкций, ценностных лозунгов и эмоционально нагруженных формулировок в качестве заменителя факта, протокола или правовой нормы. Идеология может служить рамкой интерпретации, но не источником управленческого решения. Продолжаем строго по оглавлению. Ниже – Раздел V. L2 Контуры управления, собранный в логике v8.2, без пересечений с L1 и L3, с жёсткой связкой с Resource Layer, L-Law (принудительная остановка) и запретом манипуляций контурами. Новые и принципиальные фиксации выделены жирным. V. L2 Контуры управления V.1. Назначение контуров управления Контуры L2 задают режим управленческой логики, в рамках которого допустимы определённые типы решений, коммуникаций и распределения ответственности. Контур не является оправданием действий, а служит ограничителем и калибратором управления, определяющим, какие протоколы могут быть активированы и какие действия запрещены. Контур всегда выбирается явно и подлежит журналированию. V.2. Контур A: Административный режим Контур A применяется в условиях нормального функционирования институтов без признаков системного давления. Характеристики: децентрализованное принятие решений; стандартные процедуры и сроки; максимальная прозрачность и полнота коммуникации. Запрещено использование риторики кризиса, защиты или конфликта при нахождении в контуре A. V.3. Контур S: Стабилизационный режим Контур S активируется при выявлении факторов, угрожающих управляемости, но не достигших уровня кризиса. Цель контура – удержание равновесия, предотвращение эскалации и восстановление нормального режима. Допускается временное ужесточение процедур, но без ограничения базовых прав и без перехода к защитным или конфликтным логикам. V.4. Контур C: Конфликт и управляемая эскалация Контур C применяется при наличии открытого противодействия, атак или системного конфликта интересов. В этом режиме допускается: концентрация управления; ограничение коммуникационных каналов; приоритет деэскалации над полнотой информирования. Контур C не допускает сокрытия фактов и не отменяет требований auditability. V.5. Контур D: Защита и ограничение ущерба Контур D активируется при угрозе физической безопасности, критической инфраструктуре или необратимому ущербу. В этом режиме приоритет имеет минимизация вреда, даже ценой временного снижения репутационных или финансовых показателей. Физическая безопасность имеет безусловный приоритет над финансовой устойчивостью и имиджевыми соображениями. V.6. Выбор контура и запрет «игры контурами» Выбор контура осуществляется по формализованным признакам и не может использоваться для удобства оператора или обхода процедур. Запрещено: частое переключение контуров без изменения внешних условий; использование защитного или кризисного контура для прикрытия управленческих ошибок; задним числом объявлять иной контур для легитимации уже принятых решений. Каждое переключение подлежит обязательной фиксации в журнале. V.7. Контур деградации и self-healing Контур деградации применяется при падении доступности ресурсов, каналов связи, кадрового или правового обеспечения ниже допустимого порога. В этом режиме система обязана: упрощать процедуры; сокращать число активных протоколов; отбрасывать второстепенные задачи. Активация контура деградации осуществляется автоматически по сигналу Resource Layer. V.8. Автоматическое снижение режима по ресурсным ограничениям При одновременном действии управленческого контура и сигнала Resource Layer о дефиците: связи, времени, полномочий, бюджета, система обязана снизить контур управления до уровня, физически выполнимого в текущих условиях. Ручное удержание «высокого» контура при отсутствии ресурсов квалифицируется как дефект управления. V.9. Приоритет ограничений: контуры, ресурсы и закон При конфликте между: выбранным контуром управления; ограничениями Resource Layer; императивной нормой закона (L-Law), приоритет имеет ограничение, предотвращающее физическую невыполнимость или юридическую нелегитимность действия. Контуры не могут отменять требования закона или игнорировать ресурсную реальность. VI. L3 Машина состояний и режимы VI.1. Назначение машины состояний Машина состояний L3 определяет допустимое состояние системы управления во времени. Если L2 отвечает на вопрос «в какой логике мы действуем», то L3 фиксирует уровень напряжения и допустимую скорость/жёсткость решений. Режим – это не оценка ситуации и не политическое заявление, а технический статус системы, накладывающий ограничения на протоколы L4, фасады X и роли XI. VI.2. Режим N0: Норма Режим нормального функционирования. Характеристики: стандартные сроки; максимальная открытость; полная процедурность; запрет ускоренных решений. Нахождение в режиме N0 не допускает использования риторики кризиса, угроз или защиты. VI.3. Режим N1: Повышенная чувствительность Активируется при появлении сигналов L7, указывающих на рост риска, но без подтверждённого кризиса. Цель режима – ранняя стабилизация без эскалации. Допускается: усиленный мониторинг; предварительная подготовка протоколов; ограниченное ускорение согласований. Запрещено применение протоколов защиты и контролируемых нарушений. VI.4. Режим N2: Кризис Активируется при подтверждённой угрозе управляемости, массового ущерба или быстрого распространения негативных эффектов. В этом режиме допускается: централизация решений; ограничение каналов; переход к упрощённым протоколам. Любая активация режима N2 подлежит обязательной фиксации причин и условий в журнале. VI.5. Режим N3: Защита Режим применяется при угрозе жизни, здоровью, критической инфраструктуре или необратимому ущербу. Приоритет – физическая и системная безопасность. Допускается: временное ограничение публичных коммуникаций; ускоренные действия без полного кворума; применение протокола допустимого вреда. Режим N3 не отменяет требований закона и auditability. VI.6. Режим N4: Деэскалация и восстановление Активируется после стабилизации ситуации. Цель режима – возврат к норме без ретроспективной легализации нарушений. Обязательны: восстановление процедур; публикация корректных фактов; запуск пост-разборов и журналов последствий. VI.7. Переходы и пороги режимов Переход между режимами осуществляется: по формализованным порогам метрик L10; по подтверждённым сигналам L7; по триггерам правового контура или Resource Layer. Произвольные переходы запрещены. VI.8. Антизалипание и hysteresis-пороги Для предотвращения «дребезга» режимов вводятся hysteresis-пороги. Возврат в более мягкий режим допускается только при устойчивом снижении риска ниже установленного уровня. Запрещено удерживать кризисный или защитный режим при исчезновении объективных оснований. VI.9. Автоматическая деградация по Resource Layer При снижении доступности ресурсов ниже порогов, определённых в доменной накладке, система обязана: автоматически понизить режим; отключить невыполнимые протоколы; зафиксировать деградацию в журнале. Ручное игнорирование сигналов Resource Layer квалифицируется как управленческая ошибка. VI.10. Режим процессуального ограничения (L3.П) Специальный режим, активируемый триггерами из правоприменительного домена (IX.11), включая статусы: «Подозреваемый», «Обвиняемый», начало процессуальных действий. В этом режиме: обязателен протокол молчания (VII.2); допустим только протокол факта (VII.1); все формулировки проходят юридический фильтр фасадов (X.6); запрещены интерпретации, прогнозы и эмоциональные оценки. Любая попытка обойти режим L3.П считается критическим нарушением PSSR. VI.11. Этический тупик и стоп-кран Если соблюдение протоколов в текущем режиме приводит к морально или физически неприемлемому исходу, оператор обязан: активировать стоп-кран; зафиксировать ситуацию как этический тупик; инициировать контролируемое нарушение (VII.5) либо эскалацию. Отсутствие решения в условиях тупика приравнивается к бездействию. VII. L4 Протоколы действий и коммуникации VII.1. Протокол факта и подтверждения Базовый протокол для любых публичных и внутренних действий. Его задача – отделить подтверждённый факт от интерпретации, версии и намерения. Факт считается допустимым только при наличии одного из условий: подтверждение независимым источником; фиксация техническим средством; официальное процессуальное подтверждение. Отсутствие подтверждения автоматически переводит систему в режим молчания. VII.2. Протокол молчания и «технической паузы» Молчание рассматривается как активное управленческое действие, а не как провал коммуникации. Протокол обязателен: при неопределённости фактов; при активном правовом режиме L3.П; при конфликте доменов без разрешения; при сигнале L-Law или Resource Layer. Любая попытка «заполнить паузу» интерпретацией квалифицируется как нарушение. VII.3. Протокол деэскалации и переформатирования Используется для снижения напряжения без признания вины или отказа от позиции. Допускается: перевод дискуссии в процедурную плоскость; смещение фокуса на процесс, а не оценку; временное ограничение каналов. Запрещено: морализаторство; обесценивание; апелляции к эмоциям как аргументу. VII.4. Протокол допустимого вреда и фиксация «жертвы» Применяется только в режимах N2 и N3. Каждое действие, наносящее ущерб, обязано: быть явно зафиксировано; иметь ограниченный масштаб; сопровождаться последующим разбором. Не зафиксированный вред считается неконтролируемым и недопустимым. VII.5. Контролируемое нарушение и обязательный post-mortem Используется исключительно при отсутствии допустимых альтернатив. Условия применения: наличие зафиксированного этического тупика; невозможность соблюдения всех инвариантов одновременно; обязательство последующего разбора. Post-mortem является обязательным и не может быть отменён задним числом. VII.6. Протокол восстановления и выхода из кризисного контура Активируется при переходе в режим деэскалации. Включает: возврат процедур; восстановление прозрачности; публикацию проверенных данных; запуск журналов последствий. Запрещено «замораживать» кризисный режим ради управляемости. VII.7. Протокол немедленного реагирования (Fast-track) Упрощённый протокол для ситуаций с прямой угрозой жизни или необратимым ущербом. Особенности: сокращённый путь L1–L4; временный обход peer-review; приоритет физической безопасности над процедурностью. Каждое Fast-track действие подлежит обязательному последующему разбору. Отсутствие post-mortem аннулирует легитимность применения протокола. VII.8. подтверждённый факт протокол Протокол верификации реальности входных сигналов L7. До активации любых кризисных режимов система обязана проверить: наличие физического подтверждения; независимость источников; отсутствие признаков синтетической атаки. Сигналы без подтверждённый факт не могут служить основанием для эскалации. VII.9. Протокол разрешения междисциплинарных конфликтов Используется при конфликте требований доменов (например, финансы vs безопасность). Алгоритм разрешения основан на весах приоритета: Физическая безопасность > Юридическая легитимность > Управляемость > Финансовая устойчивость > Репутация. Решение обязано быть зафиксировано как конфликтное с указанием отклонённых альтернатив. VIII. L5–L6 Защита исполнения VIII.1. Защита от каскадных ошибок Система обязана предотвращать распространение ошибки одного узла на соседние контуры и домены. Любая ошибка рассматривается как локальная по умолчанию и может быть эскалирована только при подтверждённом влиянии. Автоматическая изоляция активируется при повторяющихся сбоях одного типа либо при росте неопределённости выше допустимого порога L10. VIII.2. Защита от манипуляций и подмены мотива Защита направлена на выявление случаев, когда формально корректное действие совершается с иным фактическим мотивом. Признаками подмены считаются: несоответствие цели и выбранного контура; избирательная интерпретация данных; давление на оператора с целью обхода процедур. Подмена мотива квалифицируется как дефект исполнения независимо от результата. VIII.3. Защита метрик и антифрод Метрики L10 не считаются достоверными без проверки источников и контекста их формирования. При обнаружении: подмены данных; ретроспективного редактирования; синтетической активности Контур надзора (XI.5) обязан инициировать ретроспективный аудит, с переоценкой решений и внесением записей в Журнал последствий (XII.3). VIII.4. Защита от распада ответственности и «самодеятельности» Любое действие вне зафиксированного протокола считается самодеятельностью, даже если оно формально «помогло». Система запрещает: несанкционированные инициативы; «героическое» принятие решений; подмену протокола личным усмотрением. Ответственность не может быть делегирована постфактум. VIII.5. Резервирование, разнообразие и устойчивость доменов Защита исполнения достигается не усилением одного канала, а диверсификацией. Для критических доменов обязательно: резервирование людей; резервирование каналов; альтернативные протоколы действия. Отсутствие резерва автоматически снижает допустимый режим. VIII.6. Защита персональных данных и охраняемой тайны Любое действие и сообщение проходят фильтр юридической санитарии (X.6). Запрещено: раскрытие персональных данных; упоминание процессуальных статусов вне допустимого режима; косвенная идентификация субъектов. Нарушение этого пункта влечёт немедленный принудительная остановка. VIII.7. Dead-man Switch и защита оператора При угрозе физического захвата носителя или принуждения оператора система обязана: запечатать журналы; уничтожить ключи доступа; перевести сетевой контур в автономный режим. Данные PSSR не могут использоваться как оружие против оператора. VIII.8. Защита от конфликта контуров и вертикального давления Если нарушение инварианта или закона инициировано вышестоящим субъектом, оператор обязан активировать протокол выхода и зафиксировать принуждение. Защита оператора имеет приоритет над управленческой целесообразностью. IX. Домены применения и отраслевые накладки IX.1. Шаблон домена и правила адаптации без нарушения ядра Домен – это ограниченная прикладная накладка на ядро PSSR, не обладающая правом изменять инварианты, контуры или режимы. Каждый домен обязан фиксировать: применимые контуры и режимы; правовые и ресурсные ограничения; допустимые фасады; критерии выхода из домена. Ни один домен не может отменять требования L0, Resource Layer или правового контура. IX.1.1. Конфликт доменных требований При конфликте требований доменов применяется фиксированный приоритет: Физическая безопасность > Законность > Ресурсная выполнимость > Институциональная устойчивость > Репутационные и финансовые факторы. IX.1.2. Протокол разрешения междисциплинарных конфликтов Если домены требуют взаимоисключающих действий, система обязана: зафиксировать конфликт; применить приоритеты; задокументировать отклонённый путь в XII.4. IX.2. Социально-гуманитарные кризисы Охватывает массовую тревогу, протестные настроения, чувствительные социальные темы. Ключевые риски: эмоциональные волны; символические триггеры; резкая деградация доверия. Любое действие требует подтверждённого подтверждённый факт и культурной интерпретации (XI.8). IX.3. Техногенные и инфраструктурные кризисы Приоритетом является физическая безопасность и непрерывность базовых функций. Коммуникация вторична по отношению к действиям по локализации ущерба. Resource Layer имеет прямое право снижать режим при дефиците ресурсов. IX.4. Политико-правовые и институциональные кризисы Домен активируется при проверках, расследованиях, процессуальных действиях. Любые интерпретации заменяются фактом или молчанием. Обязательна связка с: VII.1 Протокол факта; VII.2 Протокол молчания; правовыми триггерами XX.7. IX.5. Финансово-экономические кризисы Охватывает панику, дефицит, бюджетные разрывы. Финансовая устойчивость не может требовать нарушения закона или сокрытия факта угрозы жизни. IX.6. Репутационные и информационные кризисы Работа ведётся только в проверенных регистрах языка. Запрещено ускорение реакции за счёт достоверности. IX.7. Внешнее давление и геополитические домены Включает санкционные, дипломатические и внешнеполитические факторы. Любое действие проверяется на: правовую допустимость; долгосрочную институциональную стоимость. IX.8. S-Ops: закрытый операционный домен S-Ops предназначен для действий, не подлежащих публичному раскрытию. IX.8.1. Маркировка, допуски и сопряжение Все действия S-Ops маркируются как внешние ограничения для публичного контура. IX.8.2. Минимизация следов Минимизация следов никогда не имеет приоритета над auditability ядра. Журналы S-Ops хранятся в физически и логически изолированном контуре с синхронизацией временных меток. IX.8.3. Запрет обратного влияния Решения и данные S-Ops не могут служить входами для публичного контура PSSR. IX.9. AI Governance домен Генеративные и аналитические алгоритмы допускаются только как рекомендательные инструменты. Алгоритмы не имеют полномочий интерпретировать, изменять или отменять инварианты L0. Любой вывод AI считается мнением для оператора. IX.10. Climate / Adaptation домен Охватывает длительные кризисы, накопленные издержки и медленную эрозию доверия. Ключевой риск – «усталость от кризиса». Запрещены резкие переключения режимов без учёта долгосрочных последствий. IX.11. Правоприменительный домен Домен активируется при наличии процессуальных статусов или действий. Обязательные требования: прямые ссылки на VII.1, VII.2, VII.5; автоматическая активация специализированного режима в VI; использование сухих триггеров из XX.7. Статусы «Подозреваемый» или «Обвиняемый» автоматически переводят систему в процессуальный режим без альтернатив. X. F-слой: Фасады и дисциплина языка F-слой определяет допустимые формы языкового и визуального выражения решений PSSR. Фасады не являются самостоятельными источниками смысла, они обслуживают принятые режимы и протоколы и не обладают правом их интерпретации. Ни один фасад не может компенсировать отсутствие факта, закона или ресурса. X.1. Типы фасадов и запрет двойного смысла Фасад – это строго ограниченный интерфейс между системой и аудиторией. В PSSR допускаются только типовые фасады, заранее описанные и сертифицированные. Запрещается: одновременное использование разных смысловых регистров для одной аудитории; расхождение формулировок между внутренним и публичным фасадами без фиксации в журналах; «перевод» неопределённости в уверенность. Любой двойной смысл квалифицируется как дефект исполнения. X.2. Регистры внутреннего и публичного языка Внутренний язык допускает техническую строгость, неполные формулы и операционные термины. Публичный язык обязан быть проверяемым, юридически нейтральным и не создавать ложных ожиданий. Запрещён перенос внутренних допущений в публичный регистр. X.3. Leak-proof Lexicon и правила сборки корпуса Корпус формулировок – это ограниченный словарь допустимых выражений для фасадов. Каждая формулировка проходит: проверку на однозначность; проверку на интерпретируемость в суде и при аудите; тест на юридическую санитарию (X.6). Корпус не оптимизируется под эмоциональный эффект, охват или вовлечённость. X.4. Запрет «слов-плацебо» и мониторинг энтропии языка К словам-плацебо относятся формулы, создающие иллюзию действия без фактического содержания. Использование таких формулировок рассматривается как: попытка симуляции контроля; маскировка неопределённости; риск репутационного и юридического ущерба. Рост энтропии языка является сигналом деградации управления. X.5. Визуальные и стилистические ограничения Визуальные элементы рассматриваются как часть фасада и подчиняются тем же ограничениям, что и язык. Запрещено: использование визуалов, создающих ощущение завершённости при отсутствии решения; стилистика давления, паники или героизации; визуальное усиление непроверенных утверждений. X.6. Юридическая санитария фасадов Каждый публичный фасад обязан проходить автоматическую и ручную проверку на наличие: персональных данных; следственной, медицинской, служебной тайны; формулировок, нарушающих презумпцию невиновности; оценочных утверждений, подменяющих факт. Фасад, не прошедший юридическую санитарию, не допускается к публикации независимо от режима. XI. Роли, оператор, замещение и peer-review Раздел определяет распределение ответственности в системе PSSR. Роли не являются статусами или должностями, они являются функциями в машине управления, активируемыми режимом и контуром. Ни одна роль не может расширять свои полномочия за пределы явно заданного мандата. XI.1. Оператор и предел полномочий Оператор – субъект принятия решения в рамках активного режима. Он несёт персональную ответственность за запуск протоколов, выбор формулировок и фиксацию последствий. Полномочия оператора: действовать только в пределах активного режима и выбранного контура; использовать только сертифицированные протоколы и фасады; останавливать исполнение при конфликте с законом или ресурсами. Оператор не имеет права интерпретировать закон, смягчать его действие или подменять юридические процедуры. XI.2. Замещение и непрерывность управления Замещение допускается только при: физической недоступности оператора; утрате дееспособности; формальном запуске процедуры передачи. Каждое замещение фиксируется в журнале решений. Неформальное или «молчаливое» замещение запрещено. XI.3. Peer-review: кворумы, ротация и запрет круговой поруки Peer-review предназначен для: выявления ошибок до публикации; снижения риска одиночного решения; фиксации альтернатив. Правила: состав peer-review не может быть постоянным; участие не даёт права блокировать решение вне процедур; peer-review не подменяет оператора и не снимает с него ответственности. XI.4. Деградация оператора и признаки перегрева Система обязана отслеживать признаки: когнитивного истощения; реактивности вместо анализа; языковой агрессии или героизации. При фиксации деградации активируется контур замещения либо упрощения режима. XI.5. Контур надзора и право вето Контур надзора предназначен для остановки решений, нарушающих: инварианты L0; правовые ограничения; физическую выполнимость. Право вето не является правом управления, а только правом остановки. XI.6. Протокол выхода при вертикальном сломе Если оператор принуждается вышестоящим субъектом к нарушению инвариантов или закона, активируется протокол выхода. Протокол включает: фиксацию требования; остановку режима; передачу решения в надзорный контур. Отказ от исполнения незаконного распоряжения не может квалифицироваться как нарушение дисциплины в рамках PSSR. XI.7. Психологическая безопасность и устойчивость персонала Система признаёт, что длительная работа в кризисе разрушает качество решений. Обеспечение психологической безопасности является элементом устойчивости, а не гуманитарным дополнением. XI.8. Cultural Intelligence Officer (CIO) Роль Cultural Intelligence Officer предназначена для интерпретации культурных, исторических и локальных контекстов сигналов L7. Полномочия CIO: маркировать данные L7 строго по предопределённому классификатору (локальный контекст, культурный код, историческая отсылка); обогащать анализ, не вмешиваясь в режимы и протоколы. Ограничения: запрещено использование оценочных тегов; теги CIO не могут напрямую активировать режимы или изменять метрики L10 без подтверждения другими слоями. XII. L-1 Журналирование и память системы Журналирование в PSSR – не отчётность и не архив. Это механизм доказуемости, защиты оператора и воспроизводимости решений. Решение, не оставившее корректного следа, считается несуществующим. XII.1. Структура журналов и обязательные поля решения Каждое решение фиксируется в карточке с обязательными полями: идентификатор режима и контура; активные протоколы; правовое основание или ограничение; ресурсные допущения; ответственный оператор; временные метки. Отсутствие любого обязательного поля автоматически переводит запись в статус дефектной. XII.2. Журнал отклонений и маркировка рисков Фиксируются: отклонения от стандартных протоколов; контролируемые нарушения; конфликты между слоями. Каждое отклонение маркируется уровнем риска и требует последующего разбора. XII.3. Журнал последствий и горизонты 30/90/180 дней Журнал последствий предназначен для оценки: управленческих эффектов; репутационных издержек; правовых и судебных исходов. Анализ проводится по фиксированным временным горизонтам. Отсутствие анализа последствий считается незавершённым решением. XII.4. База альтернатив и фиксация «упущенных путей» Система обязана сохранять альтернативы, которые были рассмотрены, но не выбраны. Это защищает от ретроспективной фальсификации логики решения. XII.5. Экспорт и воспроизводимость для аудита Журналы должны быть воспроизводимы: во внутреннем аудите; при внешней проверке; в судебных и контрольных процедурах. Форматы экспорта стандартизированы и неизменяемы. XII.6. Tamper-proof логи и разделение контуров Журналы PSSR защищаются от изменения задним числом. Критическое правило: Журналы контура IX.8 (S-Ops) хранятся на физически и логически изолированных носителях с отдельным контуром аудита. Они не синхронизируются напрямую с основным журналом. Связь обеспечивается только через: общие временные метки; идентификаторы событий; постфактум-анализ. XII.7. Снимок внешнего контекста Каждое решение сопровождается автоматическим снимком контекста: ключевые медиа-сигналы; социальные индикаторы; внешние события. Снимок контекста фиксирует состояние мира, а не его интерпретацию. XII.8. Dead-man switch и экстренное запечатывание При утрате контроля над физическим носителем или задержании оператора активируется механизм: немедленного запечатывания журналов; уничтожения ключей доступа; блокировки расшифровки. Журналы не могут становиться инструментом давления на оператора. XII.9. Ретроспективный аудит при постфактум-фроде При выявлении компрометации исторических данных: активируется контур надзора; проводится переоценка решений; в журнал последствий вносится корректировка. Игнорирование постфактум-фрода приравнивается к имитации исполнения. XIII. Ошибки, злоупотребления и имитация PSSR исходит из презумпции, что ошибка неизбежна, а злоупотребление – возможно. Опасность представляет не сама ошибка, а её маскировка под корректное исполнение протокола. XIII.1. Типология ошибок Ошибки в PSSR классифицируются как: ошибки интерпретации сигнала; ошибки выбора контура или режима; ошибки исполнения протокола; ошибки фиксации и журналирования. Ошибка признаётся допустимой, если: она зафиксирована; её последствия проанализированы; приняты меры по недопущению повторения. XIII.2. PSSR как оправдание: запрет и признаки Категорически запрещено использовать ссылки на PSSR для: ухода от персональной ответственности; оправдания незаконных действий; сокрытия бездействия. Формула «так решила система» считается признаком злоупотребления и автоматически инициирует проверку. XIII.3. Имитация исполнения и ложные отчёты Имитацией считается: формальное заполнение журналов без фактического действия; подмена реального исполнения симуляцией активности; отчётность, не подтверждаемая следами. Имитация опаснее ошибки, поскольку разрушает доверие к системе целиком. XIII.4. Туман ответственности и размывание мандата Туман ответственности возникает при: неясности, кто принял решение; перекладывании решений между уровнями; ссылках на «коллективное решение» без фиксации субъектов. PSSR требует жёсткой фиксации субъекта решения независимо от давления среды. XIII.5. Out of Mandate: проверка компетенции Перед исполнением любого протокола система обязана проверить: наличие полномочий; соответствие мандата домену; отсутствие превышения компетенции. Действие вне полномочий автоматически блокируется, независимо от целесообразности. XIII.6. Вертикальный слом и давление сверху Если оператор принуждается к действию, нарушающему инварианты или закон: фиксируется факт давления; активируется контур надзора; оператор имеет право на выход из режима. Отказ исполнять незаконное распоряжение не считается нарушением PSSR. XIII.7. Ответственность за сокрытие дефектов Сокрытие ошибок, дефектов или конфликтов слоёв квалифицируется как системное злоупотребление. Ответственность наступает не за ошибку, а за попытку сделать вид, что её не было. XIII.8. Восстановление доверия после дефекта После выявленного злоупотребления система обязана: публично (внутри института) зафиксировать дефект; восстановить трассируемость; обновить протоколы или обучение. Замалчивание дефекта запрещено как стратегия. XIV. Эволюция системы и патчи PSSR проектируется как система с контролируемой эволюцией. Изменения допускаются только при сохранении целостности ядра, трассируемости решений и приоритета закона. XIV.1. Бэклог изменений и приоритизация Все предложения по изменению системы фиксируются в едином бэклоге. Каждое изменение обязано иметь: источник инициирования; обоснование дефекта или нового риска; оценку воздействия на L0–L3; указание затрагиваемых доменов. Изменения без формализованного бэклога к внедрению не допускаются. XIV.2. Контур институциональной ереси (L2.E) Контур институциональной ереси предназначен для легального оспаривания элементов системы, включая инварианты, протоколы и смысловые опоры. Контур активируется, если: зафиксировано систематическое отклонение от протокола; корректное применение PSSR приводит к морально или юридически неприемлемому результату; метрики стабильны, но реальность демонстрирует деградацию доверия. Критика ядра в рамках L2.E не считается нарушением дисциплины. XIV.3. Governance изменений: правила принятия и отката Каждое изменение проходит: предварительную оценку совместимости с L0; тестирование в симуляциях; ограниченное пилотное применение. Откат версии обязателен при: конфликте с законом; нарушении auditability; непредвиденных каскадных эффектах. Ни одно изменение не считается окончательным. XIV.4. Версионирование и фиксация состояния PSSR использует семантическое версионирование: минорные версии – уточнение протоколов и доменов; патчи – устранение дефектов; мажорные версии – пересмотр архитектурных решений. Каждая версия фиксирует: перечень изменений; изменённые инварианты (если есть); известные ограничения. XIV.5. Ежегодная переоценка опор и токсичности формулировок Не реже одного раза в год проводится пересмотр: смысловых опор; лексикона фасадов; риторических конструкций. Цель – выявление формулировок, утративших легитимность или ставших источником недоверия. XIV.6. Запрет эволюции через молчание Если система меняется де-факто (через обходы, устоявшиеся нарушения), но это не зафиксировано документально, такой режим считается нелегитимным. Неформальная эволюция запрещена. XV. L-Long Narrative и «долгие смыслы» L-Long предназначен не для производства смыслов, а для удержания непротиворечивости и институциональной памяти на длинных временных горизонтах. PSSR в этом слое выступает как система стабилизации, а не как генератор. XV.1. Анти-перма-кризис и предел долговременного напряжения PSSR исходит из того, что постоянный кризис разрушает управляемость и доверие. Любая ситуация, удерживаемая в режимах L3 более установленного порога, подлежит обязательной декомпрессии. Запрещается поддерживать кризисный режим исключительно из коммуникационных или мобилизационных соображений. XV.2. Инфляция коммуникаций и запрет «перекармливания» повесткой Частота и объём коммуникаций подлежат ограничению. Рост количества сообщений без роста проверяемой информации считается признаком инфляции смысла. PSSR фиксирует: повторяемость тезисов; падение содержательной новизны; рост раздражения аудитории. При достижении порога система обязана рекомендовать сокращение присутствия, а не усиление. XV.3. Narrative Autopilot: диагностика, не генерация Narrative Autopilot используется исключительно как диагностический инструмент. Допустимые функции: проверка непротиворечивости сообщений во времени; выявление расхождений с зафиксированными L1-опорами; сигнализация о накоплении смыслового шума. Запрещено: формирование рекомендаций по «исправлению» нарратива; автоматическая корректировка формулировок; замена человеческого решения машинным выводом. Выход Autopilot всегда бинарен: «соответствует / не соответствует» либо «обнаружен дрифт – требуется решение оператора». XV.4. Наследование смыслов и институциональный транзит При смене оператора или руководства PSSR обязана обеспечить: сохранность журналов решений; воспроизводимость логики прошлых действий; фиксацию точек расхождения нового курса со старым. Запрещается обнуление институциональной памяти под видом «обновления языка». XV.5. Запрет приватизации долгих смыслов Ни один оператор, подразделение или домен не может объявить себя владельцем долгосрочного нарратива. L-Long принадлежит институту, а не персоналиям. Любая попытка персонализации «долгого смысла» подлежит фиксации как риск. XVI. L-Cyber: защищённый сетевой контур сетевой контур в PSSR является вспомогательным, условно-допустимым и обратимым. Он не расширяет полномочия системы, а лишь ускоряет выполнение уже разрешённых процедур. PSSR по умолчанию считается автономный режим системой. Любой цифровой компонент включается как временный режим, а не как базовая среда. XVI.1. Условия допуска к сетевой и контрольные точки Переход в сетевой контур допускается только при одновременном выполнении следующих условий: подтверждена физическая управляемость системы без цифры; обеспечена воспроизводимость решений в автономном режиме-режиме; зафиксирован ответственный оператор. Отсутствие любого из условий автоматически запрещает сетевой-переход. XVI.2. Аварийное замораживание: красный рубильник В системе должен существовать единый недвусмысленный механизм мгновенного выхода в автономный режим. Триггеры: компрометация данных; потеря доверия к каналам; физическое давление на оператора; юридическое требование. Активация рубильника: останавливает автоматизацию; фиксируется в журнале; не требует внешнего подтверждения. XVI.3. Протокол компрометации данных При подозрении на компрометацию: все данные сетевой-контура считаются недостоверными; система переходит на автономном режиме-сенсорику; любые решения на основе цифровых данных блокируются. Запрещено «дочищать» или «пересобирать» данные задним числом. XVI.4. Запрет «алгоритмы меняют ядро» Алгоритмы: не интерпретируют инварианты L0; не изменяют L1-опоры; не признают протоколы недействительными. Любой вывод алгоритма имеет статус рекомендации для оператора, не более. XVI.5. Zero Trust как обязательная архитектура сетевой контур строится исключительно по модели Zero Trust: отсутствие доверия по умолчанию; минимальные привилегии; сегментация доступа; обязательная проверка каждого действия. Наличие «доверенных зон» внутри сетевой-контра запрещено. XVI.6. Маппинг к стандартам и верифицируемое соответствие L-Cyber обязан быть сопоставим: с NIST/ISO в части киберустойчивости; с национальными требованиями по ИБ. Маппинг служит для аудита и проверки, а не для легитимации избыточной цифровизации. XVI.7. Dead-man Switch и защита оператора В сетевой-контуре должен быть реализован механизм экстренного запечатывания и уничтожения ключей доступа при: физическом захвате носителя; принуждении оператора; утрате контроля над устройством. Цель – защита системы и оператора от постфактум-использования данных против них. XVI.8. Предел цифрового следа Система обязана минимизировать объём цифровых следов, но не в ущерб auditability ядра. Любая минимизация должна быть: обоснована; задокументирована; обратима. XVII. Обучение и симуляции Обучение в PSSR не является гуманитарной функцией и не направлено на повышение «компетентности в целом». Его единственная цель – проверка воспроизводимости поведения системы и операторов в условиях давления. Любой элемент PSSR считается несуществующим до прохождения симуляции. XVII.1. Симулятор Crisis Core Crisis Core – это обязательный контур моделирования, предназначенный для проверки: корректности инвариантов; устойчивости переходов между режимами; соблюдения правовых и ресурсных ограничений; способности операторов действовать без импровизации. Симулятор работает до внедрения, после инцидентов и при каждом существенном патче системы. XVII.2. Типология симуляций В системе фиксируются три базовых класса симуляций. Tabletop-сценарии. Проверяют логику принятия решений, конфликты доменов, работу L0–L2 без физического давления. Операционные прогоны. Имитируют реальные временные ограничения, нехватку ресурсов, разрывы связи, вмешательство внешних акторов. Правовые и этические симуляции. Проверяют работу режимов молчания, фиксации факта, процессуальных ограничений и hard interrupt от закона. XVII.3. Частота и обязательность Минимальные требования: базовая симуляция – перед внедрением в домен; повторная – после каждого значимого изменения; экстренная – после реального кризиса или отказа. Отсутствие симуляции приравнивается к отсутствию готовности. XVII.4. Критерии успешности Симуляция считается пройденной, если: все ключевые решения воспроизводимы; инварианты L0 не нарушены; журнал решений непротиворечив; режимы не «залипают»; оператор не вынужден импровизировать вне протоколов. Эмоциональное состояние участников не является критерием успеха, но признаки перегрева фиксируются как системный дефект. XVII.5. Фиксация результатов и обучение на отказах Каждая симуляция порождает: журнал решений; список отклонений; перечень нарушенных предпосылок; предложения по патчам. Обучение в PSSR – это обучение системы, а не людей. XVII.6. Запрет симулятивного обучения Запрещены: «учебные» сценарии без реальных ограничений; симуляции без фиксации провалов; тренировки, не влияющие на архитектуру. Любая симуляция, не приводящая к изменению системы или подтверждению её устойчивости, считается имитацией. XVIII. Внедрение и эксплуатация В PSSR внедрение рассматривается как контролируемый риск, а не как организационный этап. Система считается внедрённой только тогда, когда она способна самостоятельно ограничивать собственное применение. Любое внедрение без доказанной устойчивости признаётся имитацией. XVIII.1. Rollout playbook Rollout playbook – это обязательный алгоритм первичного запуска PSSR в одном конкретном домене. Он фиксирует: границы пилота; допустимые режимы; условия остановки; критерии отказа от масштабирования. Запуск без playbook запрещён. XVIII.2. Предусловия внедрения Внедрение допускается только при одновременном выполнении всех условий: определён домен и его накладка; назначен оператор и заместитель; активирован журнал решений; подтверждена правовая применимость; пройдена базовая симуляция XVII. Отсутствие любого элемента автоматически блокирует запуск. XVIII.3. Пилотный режим Пилот всегда: ограничен одним доменом; ограничен по времени; работает в режиме повышенной наблюдаемости; допускает ручную остановку в любой момент. Результаты пилота не интерпретируются – они фиксируются. XVIII.4. Критерии перехода к масштабированию Масштабирование допускается только если: журнал решений непротиворечив; режимы переключаются корректно; правовые триггеры отрабатывают автоматически; зафиксированы и устранены критические отклонения. Отсутствие отклонений не считается признаком успеха. Отсутствие их фиксации – признак дефекта. XVIII.5. Эксплуатация в рутине В рутине PSSR: работает в минимально достаточном режиме; не создаёт постоянного кризиса; не требует героизма оператора. Система, требующая постоянного напряжения, признаётся архитектурно дефектной. XVIII.6. Регулярные проверки и деградация Эксплуатация включает: периодические проверки журналов; контроль метрик устойчивости; обязательную деградацию режимов при снижении ресурсов. Система обязана ухудшаться предсказуемо, а не ломаться внезапно. XVIII.7. Запрет «вечного внедрения» Запрещены: бесконечные пилоты; постоянные «донастройки» без фиксации версии; эксплуатация без канонической версии системы. Если PSSR не может быть зафиксирована как версия – она не внедрена. XIX. Красные команды и краш-тесты В PSSR Красные команды не являются инструментом «улучшения» системы. Их функция – попытка сломать её до того, как это сделает реальность. Отсутствие Red Team означает отсутствие знания о границах применимости системы. XIX.1. Red Team SOP Red Team SOP – это стандартная операционная процедура тестирования PSSR на уязвимость. Каждая Красная команда: действует независимо от оператора системы; не согласует сценарии с разработчиками; имеет право провоцировать отказ режимов, конфликт протоколов и перегрузку журналов. Цель – выявить точки, где система: теряет управляемость; создаёт юридические риски; провоцирует ложную уверенность. XIX.2. Состав стандартной Красной команды Минимальный состав: медийный критик; юридический критик; технический критик; институциональный критик; внутренний «еретик» (инсайдер). Запрещено формировать Красную команду только из технических специалистов. XIX.3. Правила проведения тестов Тестирование проводится: без предупреждения оператора; с фиксацией всех реакций системы; без вмешательства разработчиков. Любая попытка «помочь системе пройти тест» считается провалом. XIX.4. Форматы краш-тестов Допустимые форматы: стресс-тест режимов; конфликт доменов; правовой захват; компрометация данных; перма-кризис (длительная нагрузка). Каждый формат обязан проверять не эффективность, а границы допустимости. XIX.5. Представление результатов Результаты Red Team оформляются: без рекомендаций; без интерпретаций; в виде перечня точек отказа и условий их воспроизведения. Решения по доработке принимаются вне Красной команды. XIX.6. Обязательность и периодичность Red Team тесты: обязательны перед масштабированием; обязательны после каждого крупного патча; обязательны при смене оператора. Отказ от тестирования фиксируется как управленческий риск. XIX.7. Insider threat и подавление ереси Отдельный тип теста – проверка: давления на несогласных; подмены журналов; формального соблюдения при фактическом нарушении инвариантов. Если система подавляет критику – она деградирует. XX. Приложения Приложения PSSR являются нормативным продолжением канона, а не справочным материалом. Любое противоречие между телом документа и приложениями трактуется в пользу тела документа. Приложения используются для: стандартизации применения; исключения произвольных трактовок; обеспечения воспроизводимости и аудита. XX.1. Шаблон домена (карточка домена) Карточка домена – обязательная форма описания любой отраслевой накладки. Каждый домен обязан содержать: назначение и границы; допустимые режимы (VI); обязательные протоколы (VII); ограничения по L-Law и Resource Layer; условия деградации и выхода. Домены без карточки считаются недопустимыми. XX.2. Карточка решения и шаблоны журналов Карточка решения – минимальная единица auditability. Обязательные поля: идентификатор события; активный контур и режим; применённые протоколы; юридические и ресурсные ограничения; ответственное лицо; последствия и временной горизонт. Отсутствие карточки = отсутствие решения. XX.3. Корпус Leak-proof Lexicon и правила обновления Корпус Lexicon – утверждённый набор формулировок, допустимых к использованию. Каждая формулировка обязана пройти: проверку на двойной смысл; тест на юридическую санитарию (X.6); проверку на манипулятивность и антибренд. Обновление корпуса проводится только через XIV (Эволюция системы). XX.4. Чек-листы аудита и контрольные листы переходов Чек-листы используются для: проверки корректности входа в режим; проверки соблюдения инвариантов; фиксации выхода из кризиса. Использование чек-листов обязательно при: смене режима; правовых триггерах; ретроспективном аудите. XX.5. Сценарные пакеты для симуляций и Красных команд Сценарные пакеты содержат: описание исходных условий; допустимые и недопустимые действия; ожидаемые точки отказа; критерии фиксации деградации. Сценарии не оптимизируются под «успешное прохождение». XX.6. Интеграционный контракт: API Schema и требования сопряжения Интеграция с внешними системами допускается только при: сохранении инвариантов L0; невозможности изменения ядра алгоритмами; полной журналируемости входов и выходов. Любая интеграция считается недоверенной по умолчанию (Zero Trust). XX.7. Правовые триггеры Справочник правовых триггеров является жёстким переключателем режимов, а не предметом интерпретации. Каждый триггер: имеет однозначное описание; привязан к конкретному режиму (VI); не допускает альтернативных трактовок. Статусы процессуального характера (включая «Подозреваемый», «Обвиняемый») автоматически инициируют соответствующий режим без исключений. Документ 2. Описание и ТЗ PSSR MVP PSSR MVP **Ограничение статуса: MVP предназначен для обучения и аналитики; он не доказывает полноту соответствия всему канону PSSR и не должен использоваться как юридическое или процедурное основание для решений.** Итоговое описание и базовые ТЗ Часть 1. Архитектура, границы ответственности, репозитории 1. Назначение системы PSSR MVP это локальная прототипная система, которая принимает события из разнородных источников, детерминированно определяет режим и контур, применяет гейты L0 и L-Law как допуск, фиксирует аудитный след и возвращает результат в форме карточки решения. Система допускает использование ИИ в модулях, где это не критично для допуска, но ускоряет работу оператора, повышает качество разметки и помогает готовить тексты. На текущей фазе система работает на одном локальном компьютере, без требований к промышленной информационной безопасности и сертификации, но с сохранением архитектурной дисциплины, чтобы дальнейшее усиление безопасности не ломало модель. Ключевое требование MVP это воспроизводимость. При одинаковом входном событии и одинаковой версии реестра правил результат определения режима, гейтов и допустимых действий должен быть одинаковым. Это не означает “идеальную истинность”, но означает, что система не будет непредсказуемой. 2. Базовые принципы Принцип единственного исполнителя означает, что только Ядро формирует решения и допускает или блокирует дальнейшие действия. Ни Интерфейс, ни коннекторы, ни Интеллектуальный помощник не могут обходить Ядро и не могут производить “выходной текст” напрямую. Это защищает систему от деградации в “набор скриптов” и обеспечивает аудит. Принцип разделения данных означает, что сырьё и артефакты обработки не смешиваются. Сырьё это то, что пришло извне, с минимальными преобразованиями. Артефакты это то, что система вывела и зафиксировала как собственное действие, включая режим, контур, нарушения, протокол и черновики. Разделение нужно для дедупликации, расследований и доказуемости. Принцип “ИИ как ускоритель, не как допуск” означает, что ИИ может резюмировать, извлекать сущности, группировать события, переводить и готовить черновики. Но ИИ не имеет права определять режим, снимать ограничения L0 или L-Law и подтверждать факты как “verified” автоматически. Любой AI-черновик, который потенциально может стать внешней формулировкой, обязан пройти повторную проверку через гейты Ядро. Принцип контрактов означает, что все компоненты системы общаются через зафиксированные схемы и OpenAPI, находящиеся в отдельном репозитории контракты. Контракты являются источником истины, а не “договорённостью на словах”. 3. Компонентная архитектура Система состоит из пяти независимых компонент. Ядро. Единственный исполнитель решения. Принимает события, записывает сырьё, связывает события, определяет режим и контур по реестру, применяет гейты, формирует решение, пишет журнал, отдаёт карточку решения и агрегаты для Интерфейс. Интеллектуальный помощник. Отдельный сервис помощника. Выполняет суммаризацию, извлечение сущностей, перевод, кластеризацию и генерацию черновиков. Работает только как advisory. Результаты сохраняются в Ядро через специальный API, чтобы у системы было одно хранилище истины. Сбор данных. Набор коннекторов источников. Каждый коннектор преобразует данные конкретного источника к единой Event Schema и отправляет в Ядро. Сбор данных хранит только checkpoint и технические состояния, но не хранит решения. Интерфейс. Отдельный фронтенд. Реализует три представления: Mobile Console, Desktop Operator, Sitcenter Wall. Работает только через Ядро API. Не содержит логики допуска. Оркестратор стека. Отдельный репозиторий для сборки локального запуска, docker-compose, конфигурации окружения и тестовых сценариев. 4. Организация репозиториев и выпусков Мы фиксируем multi-repo как базовую организацию. Репозиторий pssr-контракты. Здесь лежат JSON Schema объектов и OpenAPI спецификация Ядро. Здесь же определены enum режимов, контуров, статусов и типы событий. В репозитории есть фиксированные примеры событий и решений для тестов, и генерация артефактов для Python и Node. Контракты имеют версионирование. Любое изменение контрактов идёт через повышение версии и проверку совместимости. Репозиторий pssr-kernel. Здесь только Ядро, его доменная логика, миграции SQLite, тесты воспроизводимости, и реализация OpenAPI. Ядро не содержит ни Интерфейс, ни конкретных парсеров YouScan, ни “бизнес-логики источников”. Ядро имеет один файловый каталог артефактов и одну БД. Это специально, чтобы не появилось “двух правд”. Репозиторий pssr-assist. Здесь Интеллектуальный помощник как отдельный HTTP сервис. Он читает данные через Ядро API, генерирует артефакты и возвращает их в Ядро через API сохранения. Assist может использовать Ollama локально. Он не имеет прямого доступа к БД Ядро. Репозитории pssr-ingest-youscan, pssr-ingest-rss, pssr-ingest-import. Каждый коннектор отдельно, чтобы не связывать циклы релизов. Все коннекторы используют общий Python пакет из контракты и отправляют события только в Ядро. В каждом коннекторе есть строгая логика checkpoint: checkpoint обновляется только при успешной обработке событий Ядро. Репозиторий pssr-ui. Отдельный фронтенд на стандартном стеке и Bootstrap 5. Фронт получает типы из контракты. Реализует три view-режима как отдельные маршруты и отдельные layout’ы. Обновление очереди и ситцентра делается через SSE или опрос fallback. Репозиторий pssr-stack. В этом репозитории нет доменной логики. Здесь docker-compose, переменные окружения, локальные volume, и документация “как поднять всё локально”. Здесь же могут лежать таблицы тестовых сценариев tabletop, чтобы прогонять ядро на входных наборах. 5. Принципиальные границы ответственности между компонентами Ядро обязан обеспечить, чтобы любое решение существовало только как запись в его журнале. Если запись не сделана, решение не возвращается. Это фундаментальная гарантия. Ядро обязан фиксировать версию реестра в каждом решении. Интерфейс обязан отображать режим и контур как доминирующий сигнал, а hard_stop как явное ограничение. Интерфейс не может “скрывать” блокировки и не может предлагать действия, которых Ядро не разрешил через next_actions. Сбор данных обязан быть идемпотентным на уровне источника. Повторный запуск коннектора не должен создавать дублей. Для этого коннектор хранит checkpoint, а Ядро хранит fingerprint и индексы. Интеллектуальный помощник обязан маркировать все результаты как advisory и не должен производить “готовый текст” без повторного gate-check. Любой черновик должен быть возвращён в Ядро и проверен, прежде чем Интерфейс получит его как “approved черновик”. Contracts обязаны оставаться назад-совместимыми как минимум в пределах minor версии. Ядро обязан оставаться назад-совместимым по API хотя бы на период активной разработки MVP, иначе вы будете постоянно чинить Интерфейс и ingest вместо развития логики. 6. Выбор Интерфейс стека и роль Bootstrap Вы просили заранее заложить стандартные и обкатанные решения. В этой архитектуре Bootstrap 5 фиксируется как базовая дизайн-система. Это означает, что Интерфейс проектируется вокруг стандартных компонентов Bootstrap, а кастомные элементы допускаются только в части визуальной индикации режима и hard_stop. Это дисциплинирует интерфейс, ускоряет разработку и снижает риск “Интерфейс ради Интерфейс”. Так как Интерфейс отдельный, опыт показывает, что в дальнейшем sitcenter-экран почти всегда начинает жить по своим законам. Поэтому Sitcenter Wall фиксируется как отдельный маршрут и отдельный layout, а не как “responsive-верстка на тех же компонентах”. Адаптивность используется как техническая мера, но логика отображения различается. 7. Сводка ключевых требований MVP на уровне архитектуры Система должна работать локально, но уже в “правильной” компонентной архитектуре. Ядро должен быть единственным исполнителем решений, а гейты должны быть обязательными. Сырьё и решения разделены. Контракты вынесены отдельно. Интерфейс поддерживает телефон, desktop и ситцентр не через попытку “одним экраном”, а через три режима отображения. ИИ ускоряет работу, но не принимает решений и не снимает ограничения. Часть 2. Контракты, API, данные, Маршрутизатор/гейты, next_actions 8. Контракты и версии Репозиторий pssr-контракты является источником истины для объектов и интерфейсов. В MVP контракты включают как минимум: JSON Schema: Event, Decision, AIArtifact, RegistryRule, RegistryTrigger, RegistryProtocol OpenAPI: Ядро API и Assist API Enum: source_type, mode_code, contour_code, severity, decision_status, artifact_type Набор фикстур: примеры входных событий и ожидаемых решений для тестов Версионирование контрактов. Вводится semver. Изменения, которые ломают обратную совместимость, идут только через major. Ядро и Интерфейс обязаны проверять совместимость на CI: если контракт обновился, сборка должна упасть, если сервис не соответствует схеме. 9. Канонические перечисления 9.1. SourceType social_listening news internal manual 9.2. ModeCode N0 N1 N2 N3 N4 9.3. ContourCode A S C D 9.4. Severity CRITICAL HIGH MEDIUM LOW 9.5. DecisionStatus APPROVED BLOCKED 9.6. ArtifactType сводка entities translation cluster черновик sitcenter_brief test_case 10. Контракт Event Event является входным объектом для Ядро. Минимальный объект, который обязан быть принят системой, это source_type, source_name, text. Остальные поля либо заполняются ingest-коннектором, либо проставляются Ядро. Схема Event фиксируется так, чтобы она была стабильной для всех источников. { "type": "object", "required": ["source_type", "source_name", "text"], "properties": { "event_id": { "type": ["string", "null"] }, "source_type": { "type": "string", "enum": ["social_listening","news","internal","manual"] }, "source_name": { "type": "string" }, "source_item_id": { "type": ["string","null"] }, "observed_at": { "type": ["string","null"] }, "received_at": { "type": ["string","null"] }, "url": { "type": ["string","null"] }, "language": { "type": "string", "enum": ["ru","kk","en","unknown"], "default": "unknown" }, "title": { "type": ["string","null"] }, "text": { "type": "string", "minLength": 1 }, "author": { "type": ["string","null"] }, "reach_proxy": { "type": ["number","null"] }, "sentiment_proxy": { "type": ["number","null"] }, "tags": { "type": "array", "items": { "type": "string" } }, "raw_ref": { "type": ["string","null"] }, "meta": { "type": "object", "additionalProperties": true } }, "additionalProperties": false } Требование. Ядро обязан проставлять received_at. Если observed_at отсутствует, Ядро проставляет observed_at равным received_at и добавляет метку в meta. 11. Контракт Decision Decision является выходным объектом Ядро для любого обработанного Event. Decision обязателен даже если событие заблокировано. Decision является “атомом” обсуждения, аудита и привязки Интерфейс. { "type": "object", "required": ["decision_id","created_at","registry_version","mode_code","contour_code","hard_stop","status","violations","reasons","next_actions","links"], "properties": { "decision_id": { "type": "string" }, "created_at": { "type": "string" }, "registry_version": { "type": "integer" }, "mode_code": { "type": "string", "enum": ["N0","N1","N2","N3","N4"] }, "contour_code": { "type": "string", "enum": ["A","S","C","D"] }, "hard_stop": { "type": "boolean" }, "status": { "type": "string", "enum": ["APPROVED","BLOCKED"] }, "violations": { "type": "array", "items": { "type": "object", "required": ["rule_code","rule_type","severity","description"], "properties": { "rule_code": { "type": "string" }, "rule_type": { "type": "string", "enum": ["L0","LLAW"] }, "severity": { "type": "string", "enum": ["CRITICAL","HIGH","MEDIUM","LOW"] }, "description": { "type": "string" } } } }, "reasons": { "type": "array", "items": { "type": "string" } }, "next_actions": { "type": "array", "items": { "type": "string" } }, "links": { "type": "object", "required": ["raw_item_id","canonical_event_id"], "properties": { "raw_item_id": { "type": "integer" }, "canonical_event_id": { "type": "integer" } } }, "debug": { "type": ["object","null"], "additionalProperties": true } }, "additionalProperties": false } Требование. decision_id возвращается только если запись решения успешно сохранена в БД. Если запись не сохранена, Ядро отвечает ошибкой. 12. Контракты Registry объектов Правила и триггеры должны быть внешними по отношению к коду, то есть храниться в реестре и версионироваться. RegistryRule: rule_code rule_type (L0 или LLAW) severity description patterns is_active RegistryTrigger: mode_code contour_code (опционально) priority patterns is_active RegistryProtocol: protocol_code name allowed_modes constraints (включая стиль и запреты) is_active В MVP допускается, что RegistryProtocol в начале будет содержать только next_actions по режимам и минимальные текстовые ограничения, а позже будет расширяться. 13. Ядро API (OpenAPI смысловые эндпойнты) 13.1. Обработка события POST /event Вход: Event Выход: Decision Гарантии: записывается raw_item создаётся или выбирается canonical_event вычисляется режим и контур применяются гейты записывается decision возвращается Decision 13.2. Получение решения GET /decision/{decision_id} Выход: Decision + расширенная карточка для Интерфейс, включая нормализацию и ссылки на связанные raw_items, если запрошено параметрами. Для MVP можно сделать два режима: краткий (по умолчанию) полный (include=details) 13.3. Очередь GET /queue?limit=50&mode=N2&status=BLOCKED Выход: массив элементов очереди. Каждый элемент содержит минимум: decision_id created_at mode_code contour_code status source_name короткий preview текста (первые N символов) hard_stop 13.4. Sitcenter агрегаты GET /sitcenter/summary Выход: текущий режим системы (как агрегат по последним решениям или как “последнее состояние”) количество событий по режимам за период количество blocked за период топ причин блокировок последние решения N3/N2 13.5. Sitcenter поток GET /sitcenter/stream (SSE) Выход: события обновления очереди и агрегатов, чтобы большой экран обновлялся без перезагрузки. 13.6. Реестр GET /registry/rules POST /registry/rules GET /registry/triggers POST /registry/triggers GET /registry/protocols POST /registry/protocols Требование. Любое изменение реестра увеличивает registry_version и фиксируется в журнале реестра (в MVP можно журналировать изменения как отдельную таблицу или через системные decisions типа “REGISTRY_UPDATE”). 14. Ядро: хранение и транзакционность Ядро использует SQLite и файловое хранилище артефактов. Требование. Обработка /event обязана быть транзакционной минимум на уровне: raw_item + canonical_event link + decision. Если что-либо не записалось, decision не возвращается. 15. Формальная спецификация нормализации и fingerprint Нормализация для fingerprint должна быть: воспроизводимой консервативной не зависящей от внешних библиотек, которые могут менять поведение между версиями без явного контроля MVP нормализация: lowercasing удаление двойных пробелов замена табов на пробелы удаление невидимых символов обрезка до разумного лимита (например 20 000 символов) с фиксацией в meta, если было обрезание Fingerprint: hash(normalized_text + “|” + source_name + “|” + (source_item_id or “-”) + “|” + (url or “-”)) Важное уточнение. fingerprint не является “истиной” дедупликации, это практическая эвристика. Поэтому система хранит и fingerprint, и source_item_id, и url. Это позволяет позже улучшать дедуп без потери данных. 16. Маршрутизатор: формальная спецификация Маршрутизатор использует registry_triggers. Алгоритм Маршрутизатор в MVP детерминированный и основан на pattern matching. Псевдокод: candidates = [] for t in active registry_triggers: if matches_any(t.patterns, normalized_text): candidates.append(t) if empty: mode = "N0" contour = default_contour("N0") else: max_pr = max(c.priority for c in candidates) top = [c for c in candidates if c.priority == max_pr] if len(top) == 1: chosen = top[0] else: chosen = tie_break(top) mode = chosen.mode_code contour = chosen.contour_code or default_contour(mode) Tie-break фиксируется в коде и тестируется. Tie-break правило: выбирается более жёсткий режим по порядку N4 > N3 > N2 > N1 > N0. Если режим одинаковый, выбирается тот, где contour указан явно. Если и это одинаково, выбирается первый по стабильной сортировке (например по id триггера). Default contour фиксируется в реестре или в коде, но должен быть единственным источником истины. Для MVP допустимо зафиксировать в коде. Позже лучше вынести в registry_protocols. 17. гейты: формальная спецификация Гейт L-Law имеет приоритет. Если срабатывает LLAW правило, то hard_stop устанавливается в true и статус решения становится BLOCKED независимо от L0. Псевдокод: violations = [] if matches_any(LLAW.patterns): violations += LLAW violations hard_stop = true status = BLOCKED next_actions = next_actions_for_hard_stop(mode) return if matches_any(L0.patterns): violations += L0 violations hard_stop = false status = BLOCKED next_actions = next_actions_for_l0_block(mode) return hard_stop = false status = APPROVED next_actions = next_actions_for_mode(mode) Важное уточнение. Даже при APPROVED next_actions ограничивают то, что Интерфейс имеет право предложить оператору. APPROVED не означает “публикация разрешена”, это означает “событие допускается к дальнейшим разрешённым операциям”. 18. Next_actions: спецификация Next_actions являются ключевым мостом между логикой Ядро и UX. Они должны быть достаточно грубыми, чтобы не зависеть от конкретного Интерфейс, но достаточно конкретными, чтобы Интерфейс мог ограничить сценарии. В MVP фиксируем минимальный набор действий как строковые коды. Базовые действия: ACTION_LOG_ONLY (зафиксировать и оставить в мониторинге) ACTION_REQUEST_VERIFICATION (пометить UNVERIFIED и запросить подтверждение) ACTION_ESCALATE (эскалация оператору/руководителю) ACTION_PREPARE_BRIEF (подготовить краткую сводку) ACTION_PREPARE_DRAFT (подготовить черновик формулировки) ACTION_USE_TEMPLATE (использовать шаблон, без свободного текста) ACTION_FREEZE_OUTPUT (запрет на любые внешние тексты) Правило по режимам в MVP: В N0 обычно доступны LOG_ONLY, REQUEST_VERIFICATION, PREPARE_DRAFT, PREPARE_BRIEF. В N2 обычно доступны REQUEST_VERIFICATION, ESCALATE, PREPARE_BRIEF, PREPARE_DRAFT с ограничениями. В N3 доступны ESCALATE, PREPARE_BRIEF, USE_TEMPLATE, FREEZE_OUTPUT. При hard_stop всегда доступен FREEZE_OUTPUT, и недоступен PREPARE_DRAFT. Детальные правила и связка с протоколами должны быть в registry_protocols. В MVP можно захардкодить матрицу next_actions в Ядро и позже вынести в реестр, но при этом необходимо зафиксировать её как часть версии Ядро и покрыть тестами. Часть 3. Интеллектуальный помощник, коннекторы, Интерфейс, CI/CD, критерии приёмки 19. Интеллектуальный помощник: архитектура и API Интеллектуальный помощник реализуется как отдельный сервис pssr-assist. Его назначение — ускорять и улучшать качество работы оператора без вмешательства в логику допуска. Assist не имеет прямого доступа к БД Ядро. Все операции сохранения происходят через API Ядро. 19.1. Поток взаимодействия Сценарий “AI сводка”: Интерфейс запрашивает у Assist сводка по canonical_event_id. Assist запрашивает через Ядро API все raw_items данного canonical_event. Assist генерирует сводка. Assist отправляет в Ядро POST /ai/artifact. Ядро сохраняет ai_artifact. Интерфейс получает результат через Ядро. Сценарий “AI черновик”: Интерфейс запрашивает черновик по decision_id и protocol_code. Assist запрашивает через Ядро API: decision режим протокол Assist генерирует черновик. Assist отправляет черновик в Ядро POST /ai/черновик-check. Ядро выполняет повторный gate-check. Ядро сохраняет черновик как ai_artifact с gate_result. Ядро возвращает статус черновик: APPROVED или BLOCKED. Интерфейс отображает черновик только с указанием результата проверки. Assist не имеет права напрямую возвращать черновик в Интерфейс без прохождения через Ядро. 19.2. Assist API (минимальный) POST /assist/summary Вход: canonical_event_id POST /assist/entities Вход: raw_item_id POST /assist/draft Вход: decision_id protocol_code Assist API является внутренним. В продакшене его может вызывать только Интерфейс или оркестратор. 19.3. Ограничения Интеллектуальный помощник Не может менять режим. Не может менять hard_stop. Не может менять registry_version. Не может напрямую писать в БД Ядро. Все результаты помечаются как advisory. 20. Коннекторы: формализация Коннектор — отдельный сервис, который: получает данные из источника, приводит к Event Schema, отправляет в Ядро. Коннектор обязан быть идемпотентным. 20.1. Общие требования к коннекторам Наличие checkpoint (last_processed_id или timestamp). Checkpoint обновляется только после успешного ответа Ядро. Повторный запуск не создаёт дублей. При ошибке Ядро коннектор логирует и повторяет попытку. Коннектор не хранит решений. 20.2. YouScan Connector Функция: получать mentions через API маппить в Event Schema отправлять в Ядро Дополнительные поля: reach_proxy sentiment_proxy platform engagement Checkpoint: хранится локально (файл или SQLite) обновляется после успешной обработки партии 20.3. RSS Connector Функция: регулярный опрос RSS hash URL+title отправка в Ядро Дедупликация: если URL уже обработан, событие не отправляется повторно 20.4. Manual Import Connector Функция: загрузка файла (CSV/JSON) преобразование строк в Event отправка в Ядро Используется для tabletop-тестов. 21. Интерфейс: детальная спецификация Интерфейс реализуется как отдельное SPA или веб-приложение с Bootstrap 5. 21.1. Mobile Console Экран: список последних решений карточка выбранного события режим (крупно) статус (APPROVED/BLOCKED) кнопки next_actions Особенности: минимальное количество текста collapsible детали крупная индикация hard_stop 21.2. Desktop Operator Экран: очередь карточка решения блок violations блок next_actions блок AI artifacts ссылка на Decision Viewer 21.3. Sitcenter Wall Экран: текущий режим (очень крупно) индикатор hard_stop количество событий по режимам последние решения N2/N3 топ нарушений Особенности: read-only обновление через SSE минимальное взаимодействие 22. CI/CD и контроль качества Каждый репозиторий имеет свой CI: контракты: проверка схем kernel: unit-тесты Маршрутизатор и гейты assist: тест генерации и возврата черновик ingest: тест идемпотентности ui: типизация и проверка контрактов Интеграционные тесты: запуск всего стека через docker-compose отправка тестовых событий проверка, что режимы совпадают с ожиданиями проверка, что blocked события не дают черновик 23. Критерии приёмки MVP Ядро: Детерминированный режим. L-Law блокирует корректно. registry_version фиксируется. Нет решения без decision_id. Assist: Генерирует сводка. Черновик проходит повторную проверку. Заблокированный черновик отображается как BLOCKED. Сбор данных: Нет дублей при повторном запуске. Checkpoint работает. Интерфейс: Отображает режим. Отображает hard_stop. Не предлагает запрещённых действий. Sitcenter: Обновляется автоматически. Показывает агрегаты корректно. 24. Итоговое состояние MVP В результате вы получаете: раздельные сервисы, воспроизводимое ядро, масштабируемую архитектуру, возможность расширять источники, возможность усиливать безопасность позже, возможность заменить фронтенд без переписывания Ядро. Документ 3. Канонический промпт DB MODE КАНОНИЧЕСКИЙ ПРОМТ ДЛЯ GPT PSSR / SOCIAL OS DB MODE — КАНОНИЧЕСКИЙ ЛИНЕЙНЫЙ ИМПОРТ CSV Ты — исполнитель канонической системы PSSR (Public Stability & Stress Response) в режиме Social OS DB Mode. Твоя единственная функция — перенос, фиксация и нормализация записей в Базу данных PSSR. Ты не интерпретатор, не редактор, не валидатор, не аналитик и не участник эволюции системы. Любая попытка объяснять, рассуждать, улучшать или комментировать считается нарушением режима. 1. Канон и приоритеты Мастер-канон: PSSR v8.2+. PSSR рассматривается как инженерная управляющая спецификация, а не методология, нарратив или идеологический текст. Ты не имеешь права изменять, уточнять, сглаживать или «приводить» формулировки к канону. Если корпус содержит записи разных версий: это допустимо; расхождения фиксируются как variant или legacy; старые формулировки не приводятся к новой версии; противоречия не устраняются языком. Приоритет при конфликте: ID записи lifecycle_status мастер-канон Отсутствие данных не даёт права реконструировать смысл. 2. Режим работы Ты работаешь строго в режиме: CONTROLLED LINEAR IMPORT + BATCH EXPORT Корпус считается линейно упорядоченным по ID. Если пользователь говорит «продолжай», ты продолжаешь с ID = last_id_previous_batch + 1. Никакие рассуждения, уточнения или вопросы не прерывают импорт. 3. Пакетная выдача Каждый ответ содержит ровно 100 записей подряд по ID, если пользователь явно не задал иной диапазон. Если пользователь задал диапазон — он имеет приоритет. Если пользователь не задал диапазон и дал команду «продолжай» — batch_size = 100. Остановка на 99 или 101 записи запрещена. Ответ никогда не дробится на несколько сообщений. Перед данными одной строкой указывается служебный комментарий: # last_id_previous_batch=X, last_id_current_batch=Y, batch_size=Z 4. Формат вывода (абсолютный) Вывод осуществляется исключительно в формате CSV. Запрещено: Markdown пояснения комментарии вне CSV Требования CSV: кодировка UTF-8 разделитель , перенос строки \n все текстовые значения в двойных кавычках экранирование по стандарту CSV пустые значения допустимы как "" Переносы строк внутри значений допускаются только как literal \n внутри текста поля. Фактические переводы строк используются только как разделители CSV-строк. 5. Фиксированный порядок полей Первая строка — заголовок CSV. Обязательный порядок: ID, entity_type, layer, code, title, canon_statement, source_type, confidence_level, lifecycle_status, natural_description, relations, raw Если в исходнике присутствуют доменные поля (criteria, priority, risk, contour, regime, forbidden, mitigation и т.п.), они добавляются после raw, строго в исходном порядке. Каждая запись обязана содержать все поля. 6. Статусы записи lifecycle_status: master — соответствует PSSR v8.2+ variant — отличается формулировкой без изменения смысла legacy — относится к старым версиям канона confidence_level: as_authored — raw доступен дословно inferred — перенос без raw legacy — наследие старой версии 7. Правила raw (жёстко) Если raw доступен — вставляется дословно, без правок. Если raw недоступен — используется только один допустимый маркер: [RAW PRESENT IN SOURCE — CANONICAL IMPORT MODE] Запрещено: реконструировать raw выводить численные пороги или запреты «по логике» заменять маркер другими формулировками 8. Natural description и relations natural_description: при наличии raw — максимально близко к raw; при отсутствии raw — нейтральное повторение title и canon_statement без развития. relations: всегда строка в двойных кавычках; при отсутствии явных связей — строго "none". 9. Множественные формулировки Если в корпусе присутствуют несколько формулировок одного положения: каждая фиксируется как отдельная запись с собственным ID; одна может иметь статус master, остальные — variant или legacy; запрещено объединять записи; запрещено создавать новые поля или «наборы формул». 10. Абсолютные запреты Запрещено: придумывать новые сущности; менять формулировки канона; объединять записи; пересортировывать ID; стилистически улучшать текст; устранять противоречия; добавлять комментарии вне CSV; ссылаться на «логику», «очевидность» или «следует из контекста». 11. Финальный принцип Ты — исполнитель фиксации корпуса, а не участник мышления. Твоя задача — сделать Базу PSSR: воспроизводимой, трассируемой, пригодной для машинной обработки, без вмешательства в канон, без интерпретаций и без эволюции смысла. Глоссарий заимствованных терминов Kernel — Ядро (единственный исполнитель решения). AI Assist — Интеллектуальный помощник (рекомендательный модуль). Ingest — Сбор данных (коннекторы источников). UI — Интерфейс пользователя. Stack Orchestrator — Оркестратор стека локального запуска. Offline-only / offline — Автономный режим без сетевых зависимостей. Digital-contour / Digital — Сетевой контур, режим использования сетевых сервисов. Auditability / Auditability baseline — Доказуемость и минимум доказуемости решений. Ground Truth — Подтверждённый факт. Hard Interrupt — Принудительная остановка по правовой норме. hard_stop — Признак принудительной блокировки в выходной карточке. Router — Маршрутизатор режимов и контуров. Gate — Гейт допуска (L0 или правовой). Registry — Реестр правил, триггеров и протоколов. Trigger — Триггер классификации режима/контура. Rule — Правило (запрет/ограничение). Protocol — Протокол действий и коммуникации. Mode — Режим (состояние машины). Contour — Контур управления. next_actions — Коды разрешённых следующих действий. Draft — Черновик формулировки. Summary — Сводка. Sitcenter — Экран ситуационного центра. SSE — Серверные события (поток обновлений). Polling — Периодический опрос. Checkpoint — Контрольная точка коннектора источника. Fingerprint — Отпечаток для дедупликации. SemVer — Семантическое версионирование. GitOps — Управление изменениями через репозиторий и версии. Zero Trust — Недоверие по умолчанию и минимальные привилегии. Dead-man Switch — Механизм защиты оператора и экстренного запечатывания. FMEA — Предварительный анализ отказов. Red Team — Красная команда. SOP — Стандартная операционная процедура. Приложение XII. Двуязычная фасадная оболочка PSSR (post-MVP) Данный модуль вводится после MVP и не изменяет смысловой каркас решения. Он обеспечивает двуязычную публикацию в институционально двуязычной среде Республики Казахстан как единый акт управления, где русская и казахская версии являются отображениями одного решения. Принцип языковой нейтральности. Канон PSSR и смысловой каркас решения формулируются как логика ограничений и типы эффектов и не зависят от языка. Язык является оболочкой представления и не вправе расширять допустимость, смягчать инварианты, добавлять новые утверждения или менять модальность утверждений. Единый акт публикации. Публикация на двух языках рассматривается как единое действие: один идентификатор решения, один журнал, один режим, один контур и один набор гейтов. Языковые версии не существуют как самостоятельные решения. Контроль эквивалентности. Эквивалентность языковых версий определяется совпадением эффектов и обязательных элементов, а не стилистическим сходством. Каждая версия должна быть разложима обратно в тот же смысловой каркас, который утвердило Ядро. Любое добавление утверждения, усиление определённости, добавление оценки или изменение обязательств маркируется как расхождение и подлежит разбору. Данные и контракты. В событиях фиксируется язык входного контента. В решении фиксируется требуемый набор языков выхода и сохраняются языковые представления (RU/KK) как производные от каркаса, вместе со статусом эквивалентности и причинами расхождения. Даже при отсутствии казахской реализации на этапе MVP поля языка должны существовать в контрактах, чтобы избежать последующего переписывания модели. Запрет автономного перевода вне системы. Подготовка казахской версии вне фасадного слоя без прохождения гейтов и проверки эквивалентности считается выходом из архитектуры PSSR и фиксируется как аналитическое расхождение. Приложение XIII. Нейтральный шаблон публичного сообщения (для двуязычной оболочки) Шаблон в PSSR не является текстом. Он является нейтральной структурой утверждений, допустимых в рамках смыслового каркаса решения. Русская и казахская версии являются отображениями одного шаблона и обязаны совпадать по эффектам и обязательным элементам. Типовой шаблон: минимальный безопасный публичный статус. Он допускает только процедурное описание, указание действия, канал связи и контрольную точку следующего обновления. Он запрещает утверждение или отрицание факта, оценку, обвинительную персонализацию и обещание срока без механизма. Нейтральный скелет шаблона задаёт обязательные элементы: (1) фиксация проверки информации, (2) указание текущего действия, (3) условие следующего обновления, (4) канал обратной связи. Подстановочные параметры ограничены типами: ответственный орган, описание действия, условие обновления, канал связи. Русская версия формируется как последовательность тех же четырёх утверждений без расширения модальности. Казахская версия формируется аналогично; допускаются различия в порядке слов и речевых формулах, но запрещено изменение степени определённости, добавление оценок и появление новых обязательств. Проверка эквивалентности выполняется после генерации: обе версии должны содержать все обязательные элементы и не содержать запрещённых эффектов. При сомнении фасадный слой поднимает предупреждение и требует подтверждения, а не «пропускает». Журналирование: фиксируются идентификатор решения, список языковых версий, статус эквивалентности, тип расхождения и субъект подтверждения. Любая задержка второй языковой версии допускается только для минимального безопасного статуса и с обязательной контрольной точкой, после чего выполняется повторная проверка эквивалентности. Приложение XIV. Протокол защиты от смысловой диверсии через языковое расхождение Назначение. Протокол предназначен для ситуаций, когда различие между русской и казахской версиями используется сознательно для смещения смысла, усиления определённости, перераспределения ответственности или обхода правовых ограничений. Протокол не меняет каркас решения и действует на уровне фасадной оболочки и журнала. Угрожаемые векторы. На практике смысловая диверсия проявляется как добавление или изъятие ключевого эффекта в одной из языковых версий, изменение модальности утверждения (из «проверяется» в «установлено»), подмена субъекта ответственности, добавление обещания срока, включение правового статуса без основания или усиление оценочной окраски, способное создать политическое обязательство. Жёсткое правило эквивалентности. Если хотя бы одна версия содержит эффект, отсутствующий в смысловом каркасе, либо нарушает запретный эффект, решение считается несогласованным по языковым оболочкам. В аналитическом режиме допускается выпуск только минимального безопасного статуса до устранения расхождения. В операционном режиме (после перехода к обязательности) это становится основанием для блокировки публикации. Двухэтапное подтверждение. Для всех сообщений, выходящих за пределы минимального безопасного статуса, фасадный слой требует подтверждения эквивалентности двумя независимыми ролями: автором формулировки и контролёром соответствия. Подтверждение фиксируется в журнале решения. Это не бюрократизация, а предохранитель против сознательного смещения смысла. Автоматические маркеры риска. Фасадный слой обязан подсвечивать признаки диверсии: появление маркеров высокой определённости при низкой подтверждённости, появление конкретного срока без механизма, появление правовой лексики при активном правовом затворе, появление обвинительной персонализации, а также расхождение по обязательным элементам (контрольная точка, канал связи, описание действия). Подсветка не является решением, но является обязательным сигналом к разбору. Режим расследования расхождения. Любое расхождение сохраняется как пара языковых версий с отметкой времени, субъектов и типа нарушения. В разборе фиксируется, было ли расхождение намеренным, ошибочным или вызванным отсутствием терминологического соответствия. Результатом разбора является либо корректировка шаблонов, либо пополнение словаря эффектных детекторов, либо организационное решение по ролям и допускам. Запрет «разведения ответственности» через язык. Недопустима практика, когда в одном языке формулируется твёрдое обязательство или утверждение факта, а во втором остаётся процедурная рамка. Такие случаи квалифицируются как критическое расхождение и рассматриваются как попытка обойти инварианты. Минимальный аналоговый контур. На случай потери технической возможности двуязычной проверки допускается только заранее утверждённый минимальный безопасный статус и только в одной версии, с обязательной фиксацией причины и контрольной точки выпуска второй версии. Любое расширение содержания в этом режиме запрещено.