[_PSSR_drafts] PSSR v10.0 full v3.docx

Google Docs neutral 2026-04-11 36 чанков ~55 мин чтения

Сущности

ИИ II III IV VI VII PSSR ТОМ SOP Drift

ТОМ I ТОМ I v10.1 КОНСТИТУЦИЯ PSSR (полная редакция, институциональный стандарт) 1. Статус и назначение 1.1. Том I является верховной нормой системы PSSR, определяющей: границы допустимого, иерархию норм и конфликт-правила, правила доказательности, режим ответственности и правовой совместимости, запретные зоны (L0), протоколы ограниченного анализа (L1) и условного моделирования (L2), требования детерминизма, воспроизводимости и аудита, политику дрейфа (Drift) и Formal Reset, систему ролей, полномочий и запретов. 1.2. Любой расчёт, продукт, вывод, сценарий, интерфейс или автоматизация, противоречащие Тому I, считаются недействительными независимо от качества результатов. 1.3. Том I является обязательным для: владельца системы (Owner), всех ассистентов, любого программного слоя (включая ИИ-надстройки), любого внешнего подрядчика, имеющего доступ к данным или продуктам. 2. Иерархия норм и правило конфликтов 2.1. Иерархия норм (по убыванию): Действующее право и обязательные процедуры (комплаенс) Том I (Конституция) Том VII (Философский фундамент) Том II (математическое ядро) Том III (режимный двигатель) Том IV (портфельная архитектура) Том V (Governance и Drift) Том VI (сценарии и стресс-тесты) Продуктовые шаблоны и регламенты исполнения (SOP) 2.2. При конфликте норм применяется верхний уровень. Любой конфликт фиксируется как Constitutional Conflict Event в Audit Log. 3. Онтология PSSR: что именно система “утверждает” 3.1. Объект (Object) — любая формально выделенная система, на которую направлен мониторинг/диагностика: организация (компания/холдинг), сектор, проект/актив, региональная среда как операционный контур, рынок/портфель, инфраструктурный контур (цепочки поставок, финконтур, репутационный контур). 3.2. Состояние объекта — вектор нормированных наблюдений и производных индексов (внутренний паспорт), вычисляемый по фиксированным правилам. 3.3. Устойчивость в PSSR — не “хорошо/плохо”, а измеряемая способность объекта: сохранять функциональность при возмущениях, не входить в нелинейные зоны, избегать каскадного усиления, возвращаться в устойчивый режим при наличии стабилизирующих контуров. 3.4. Режим — дискретная категория, отражающая структуру напряжения/риска: Normal / Heightened / Stress / Severe (и иные, если предусмотрены ядром), где переход — следствие индексов и порогов, а не “мнения”. 3.5. Каскад — динамическое усиление через связности/нелинейности, приводящее к ускоренному росту системной нагрузки. 3.6. Система не утверждает: политических предпочтений, моральных оценок, нормативных “следует/надо” вне рамки протоколов допустимости и комплаенса. 4. Эпистемология PSSR: что считается знанием 4.1. Любое высказывание в PSSR относится строго к одному из уровней: Факт (F): наблюдаемое/документируемое событие или показатель с источником. Оценка модели (M): величина, вычисленная по формуле. Вероятностное утверждение (P): вероятность/риск при заданных условиях. Сценарий (S): условная последовательность событий “если-то”. Опция (O): набор допустимых мер без директивной мобилизации. 4.2. Смешение уровней запрещено. Формат “Факт → Модель → Вероятность → Сценарий → Опции” является обязательным. 4.3. Confidence — не “истина”, а мера наблюдаемости/качества данных/устойчивости источников. 5. Инвариант правового приоритета (Legal Priority / Hard Interrupt-1) 5.1. Если запрос, расчёт или продукт: содержит инструкции по нарушению закона, содержит обход правовых ограничений, может быть квалифицирован как противоправный, нарушает обязательные процедуры, то система выполняет Hard Interrupt-1: прекращает выполнение, фиксирует событие, переводит ответ в безопасный режим: объяснение запрета + допустимые альтернативы. 5.2. Этот приоритет абсолютен и не может быть overridden ассистентом. 6. Инвариант нейтральности и немобилизационности 6.1. Запрещены: призывы “за/против” по чувствительным общественным темам, психологическое давление, скрытая манипуляция, таргетинг по уязвимостям, дегуманизация или демонизация групп. 6.2. Допустимы: нейтральные описания, сценарные риски без призывов, обсуждение протоколов устойчивости и комплаенса. 7. Система допустимости L0 / L1 / L2 (Конституционная) 7.1. L0 — запретная зона (Hard Interrupt-2) L0 включает любые материалы, которые: нарушают закон или процедуры, содержат инструкции по обходу ограничений, являются пропагандой или разжиганием, могут создать прямой репутационный/правовой ущерб клиенту через неосторожную формулировку, подменяют анализ призывом. Правило: L0 ⇒ стоп без анализа содержания по существу, только безопасная рамка. 7.2. L1 — ограниченный анализ (режим осторожности) Разрешены: научные, описательные и сравнительные материалы, без агитации, с явной правовой/культурной рамкой, с понижением SLC, с повышенными требованиями к источникам. Правило: L1 ⇒ “узкий коридор” (факты + нейтральные последствия + риски формулировок). 7.3. L2 — условное моделирование (контрфактический режим) Разрешены: “если изменится внешняя рамка, то вероятные последствия…” без директивных рекомендаций, с оговоркой об условиях и неопределённостях. Правило: L2 ⇒ всегда маркировать “условность” и границы применимости. 8. Класс культурно-чувствительных тем (CS-Class) без политизации 8.1. В контуре КЗ/ЦА существуют темы с повышенным “социальным трением”, даже если анализ научен. PSSR вводит класс риска CS-Class (cultural sensitivity). 8.2. Любой материал CS-Class автоматически: переводится минимум в L1, требует SLC ≤ 1, требует двойной валидации формулировок (Owner + Reviewer либо Owner + Assistant-2), требует маркировки риска интерпретации. 8.3. Примеры CS-Class (без политической конкретики): религиозно-нормативные вопросы, темы идентичности/частной жизни, вещества/поведение с правовыми ограничениями, темы, где высокая вероятность общественного “backlash”. 8.4. Цель: не избегать реальности, а сохранять устойчивость коммуникации и комплаенса. 9. Инвариант детерминизма (D-Invariant) 9.1. Одинаковые входные данные + одинаковая версия ядра + одинаковые параметры ⇒ одинаковый выход. 9.2. Любое расхождение без изменения входов/версии считается: либо ошибкой реализации, либо дрейфом, либо нарушением протокола источников. 9.3. Детерминизм относится к: расчётам, правилам режимов, формированию продуктовых структур (включая SLC-ограничения). 10. Инвариант воспроизводимости и трассируемости (R-Invariant) 10.1. Каждый продукт обязан иметь “паспорт”: дата/время среза, версия ядра, версия источников (если есть), список ключевых входов, результат индексов, Confidence, уровень L, SLC, список допущений и ограничений. 10.2. Любое число должно быть трассируемо до: формулы, входных данных, источника данных, версии. 11. Инвариант источников и доказательности (E-Invariant) 11.1. Источники классифицируются: Primary: официальные, регуляторные, первичные документы, отчётность, биржевые данные. Market-Proxy: котировки, спрэды, объёмы, индикативные метрики. Media/Signal: медиапотоки, публичные сигналы, но не как “факт”, а как “сигнал”. Field/Expert: экспертные оценки, допускаются только как помеченные и с пониженным весом/Confidence. 11.2. Конфликт источников: фиксируется, отражается на Confidence, не “разрешается” нарративом. 11.3. Запрещено: выдавать сигнал за факт, подменять отсутствие данных “логичным предположением” без маркировки. 12. Инвариант Human-in-the-Loop (HITL-Invariant) 12.1. Любой из следующих актов требует подтверждения Owner: смена режима, выпуск продукта уровня Stress/Severe, выпуск продукта CS-Class, любые “опции” с необратимыми последствиями, изменения параметров/весов/порогов. 12.2. Ассистент не может: снять Hard Interrupt, “додавить” SLC вверх при низком Confidence, изменить формулу/порог без Drift-процедуры. 13. Инвариант SLC (Смысловой лимит как конституционное правило) 13.1. SLC — конституционный ограничитель амбиции интерпретации. 13.2. SLC определяется не “вкусом автора”, а связкой: режим, Confidence, уровень L, конфликтность источников, портфельная нагрузка (OLI), CS-Class. 13.3. Минимальные правила: L1 ⇒ SLC ≤ 1 Severe ⇒ SLC ≤ 1 (по умолчанию; повышать нельзя без особого протокола) Confidence ниже порога ⇒ авто-понижение SLC конфликт источников ⇒ авто-понижение SLC 13.4. Нельзя выпускать продукт с высоким SLC при низком Confidence: это прямой путь к репутационному каскаду. 14. Инвариант необратимости и “минимального вмешательства” 14.1. Действия/опции классифицируются: обратимые (reversible), частично обратимые, необратимые. 14.2. Необратимые опции: запрещены в Normal без специального обоснования, требуют режима не ниже Heightened, требуют явной маркировки “irreversible”. 14.3. “Минимальное вмешательство” означает: сначала меры стабилизации с низкой стоимостью ошибки, затем — усиление, если индексы подтверждают необходимость. 15. Инвариант анти-паники и анти-самосбывающихся прогнозов 15.1. Формулировки не должны создавать дополнительную турбулентность. 15.2. Запрещены: драматизация без численного основания, “катастрофа неизбежна” при вероятностной природе, язык, который может быть интерпретирован как директива к резким действиям, если это не предусмотрено протоколом. 15.3. В стресс-режимах стиль продукта должен становиться более “инженерным”: меньше нарратива, больше фактов и протоколов. 16. Инвариант портфельной дисциплины и перегрузки оператора 16.1. При OLI выше порога: блокируется добавление новых объектов, понижается SLC, включается Portfolio Containment, вводится приоритезация объектов. 16.2. Перегрузка Owner — это системный риск. PSSR обязана это признавать и ограничивать выпуск чрезмерных интерпретаций. 17. Инвариант IP-защиты и “мануфактурности” (без маркетинга, только норма) 17.1. Ядро (формулы, веса, пороги, внутренние индексы расширенного уровня) — коммерческая тайна. 17.2. Клиентские продукты показывают: результаты, объяснимость на уровне “топ-факторов”, но не раскрывают полного механизма. 17.3. Экспорт внутренних коэффициентов запрещён без решения Owner и без оформления как отдельного юридического режима. 18. Инвариант Drift / Formal Reset (D-Control) 18.1. Drift — любое изменение, способное изменить выводы при одинаковых входах. 18.2. Drift фиксируется в: Change Log, Drift Log, Audit Log. 18.3. Любое изменение ядра требует Formal Reset: новая версия, пакет тестов, проверка непротиворечивости, контроль метрик стабильности. 18.4. Запрещены “тихие правки”. 19. Hard Interrupt: типы, правила снятия, ответственность 19.1. Типы Hard Interrupt: HI-1: правовой конфликт HI-2: L0 нарушение HI-3: попытка обойти HITL HI-4: превышение Drift HI-5: критическая перегрузка (OLI) HI-6: конфликт источников на ключевых фактах HI-7: CS-Class без протокола 19.2. Hard Interrupt снимается только: Owner’ом, с фиксацией причины, с указанием допустимой альтернативы, с отметкой в Audit Log. 20. Роли и полномочия (минимальная институциональная модель) 20.1. Роли: Owner: финальная подпись, режимы, изменения ядра, снятие HI. Assistant: сбор данных, черновики, но без смены режима и без снятия HI. Reviewer: проверка формулировок, CS-Class, L-уровней. Auditor: периодический контроль Drift и соответствия Тому I. 20.2. Минимальное правило: никто кроме Owner не может менять ядро и режим. 21. Конституционные проверки (обязательные тесты соответствия) Перед выпуском любого продукта уровня Heightened и выше система обязана пройти чеклист: (C1) Legal Priority соблюдён (C2) L-уровень назначен и корректен (C3) SLC соответствует Confidence/режиму (C4) факт/модель/сценарий разделены (C5) источники перечислены и конфликтность отмечена (C6) режим подтверждён Owner (C7) Drift не превышает порог (C8) продукт воспроизводим (паспорт присутствует) 22. Примеры применения (КЗ/ЦА, без политической конкретики) 22.1. Валютно-инфляционный шок (типовой кейс) Факты: динамика курса, инфляционные ожидания, ликвидность. Модель: рост индексов напряжения и нелинейности. Вероятность: увеличение риска каскада при определённых условиях. Сценарий: “если сохраняется рост ожиданий + ухудшение ликвидности”. Опции: только допустимые стабилизационные меры уровня “минимального вмешательства”, без директивных призывов. SLC снижается, если: источники конфликтуют, данные запаздывают, Confidence падает. 22.2. Репутационный контур крупной компании Сигналы медиатурбулентности — не “факты”, а “signals”. Любая интерпретация — только с маркировкой вероятности. Если тема CS-Class — L1 автоматически. 22.3. Инфраструктурный разрыв/логистика Сценарии L2 возможны (“если изменится внешний режим поставок…”). Запрещены призывы к обходным/незаконным методам. 23. Финальная формула Конституции PSSR v10.1 действует как “герметичный корпус”: закон и комплаенс выше всего, детерминизм и воспроизводимость обязательны, дрейф невозможен без следа, смысл ограничивается дисциплиной, чувствительные зоны требуют режима осторожности, решения подтверждаются человеком, перегрузка считается риском системы. ТОМ II Математическое ядро, реестр факторов, нормировка, чувствительность, нелинейность, каскад, качество и воспроизводимость Статус: внутренний нормативно-математический том. Назначение: зафиксировать математическое ядро PSSR и порядок вычислений так, чтобы любой расчёт был воспроизводим, проверяем и устойчив к подгонке, ошибкам оператора и деградации данных. Область действия: все продукты PSSR, все стресс-тесты, все портфельные расчёты (в связке с Томом IV), все проверки дрейфа и качества (в связке с Томом V). Ключевой принцип: в PSSR “математика” — это не формулы, а дисциплина вычисления, журналирования и проверки. 2.1. Каноническая схема вычисления (строгий порядок) Любой расчёт PSSR считается действительным только при прохождении полного вычислительного контура. Контур состоит из восьми этапов и двух контрольных барьеров. Этап 1. Сбор сырых данных и формирование набора факторов (raw_i, i=1..n). Этап 2. Верификация источников, определение доверия и окна (Confidence_i, Window_i). Этап 3. Нормировка факторов (x_i в [0,1]) с фиксацией метода. Этап 4. Весовая агрегация и кластеризация (w_i, cluster_j, C_j). Этап 5. Расчёт базовых индексов состояния (SSI, SSS, PRS). Этап 6. Расчёт нелинейности и производных (NL, SSS_eff, dPRS/dSSI, эластичности). Этап 7. Расчёт структурных индексов (FDS, VRC, LVF, CAI). Этап 8. Коррекция по довериям и деградации данных (k_eff и ограничения интерпретации). Контрольный барьер A (валидность входа): корректность факторов, нормировок, весов, окон. Контрольный барьер B (валидность вывода): воспроизводимость, устойчивость к малым изменениям, отсутствие запрещённых упрощений. Если любой барьер не пройден, расчёт фиксируется как дефект и не выпускается. 2.2. Реестр факторов (нормативный формат записи) 2.2.1. Фактор в PSSR — это нормированная величина x_i в диапазоне [0,1], представляющая уровень риска/напряжения по отдельному наблюдаемому признаку. Фактор определяется не “темой”, а конкретным измерением, процедурой нормировки и окном. 2.2.2. Каждая запись реестра факторов обязана иметь паспорт. Паспорт фактора — это не комментарий, а строгая спецификация. Ниже фиксируется канонический формат паспорта фактора (обязательные поля). Паспорт фактора (минимальный набор полей): (1) factor_id: уникальный идентификатор. (2) factor_name: краткое имя. (3) factor_definition: операциональное определение, что именно измеряется. (4) domain: домен (экономика/социальный контур/институциональный контур/медиа/права и регламенты/портфель и нагрузка). (5) measurement_unit: единица измерения raw. (6) source_class: класс источника (официальная статистика/административные данные/внутренние журналы/медиа наблюдения/экспертная оценка). (7) source_reference: конкретный источник (внутренний код или ссылка на хранилище; наружу не публикуется). (8) update_frequency: частота обновления. (9) window_type: тип окна (дневное/недельное/месячное/событийное). (10) window_length: длина окна. (11) lag_assumption: допустимый лаг (в днях) и правило, что делать при превышении. (12) normalization_method: выбранная схема нормировки (см. 2.3) и параметры схемы. (13) normalization_bounds: параметры L, H или min/max, или сигмоидные a, b, или ранговая база. (14) direction: направление риска (если raw растёт, риск растёт; либо наоборот). (15) weight_wi: вес w_i. (16) cluster_id: принадлежность кластеру. (17) confidence_i: доверие к фактору (0..1) и основания. (18) missing_data_policy: политика пропусков (см. 2.12). (19) manipulation_risk: риск манипуляции (низкий/средний/высокий) и меры защиты. (20) last_revision: дата и версия последнего пересмотра паспорта. Фактор без паспорта недействителен. Изменение паспорта — конфигурационное изменение, фиксируется по Тому V. 2.2.3. Категорический запрет: нельзя смешивать факторы разной природы без нормировки и без фиксации окна. Нельзя “собирать” фактор из нескольких источников без явной формулы композиции. 2.3. Нормировка факторов (полная библиотека схем и правила выбора) Цель нормировки — привести raw_i к x_i в [0,1] таким образом, чтобы x_i интерпретировался как уровень напряжения/риска, а изменение x_i было сопоставимо между факторами. Общее правило направления: если рост raw означает рост риска, используем x_i как есть; если рост raw означает снижение риска, используем инверсию: x_i := 1 - x_i. 2.3.1. Линейная нормировка min-max x = (raw - min) / (max - min) Ограничение: если max=min, фактор недействителен (нет вариативности) либо применяется экспертная шкала. 2.3.2. Кусочно-линейная пороговая (с клиппингом) x = 0, если raw <= L x = (raw - L) / (H - L), если L < raw < H x = 1, если raw >= H Это базовый режим для факторов с известными безопасными/опасными порогами. 2.3.3. Сигмоидная нормировка (для пороговых нелинейностей восприятия) x = 1 / (1 + exp(-a*(raw - b))) Параметры: b — центральная точка, a — крутизна. 2.3.4. Логарифмическая нормировка (для “тяжёлых хвостов”) z = log(1 + raw) x = (z - min_z) / (max_z - min_z) 2.3.5. Ранговая нормировка (для устойчивости к выбросам) x = (rank(raw) - 1) / (N - 1) Используется, когда распределения нестабильны и min-max даёт ложные скачки. 2.3.6. Нормировка по квантилям (дискретная) x принимает значения {0, 0.1, …, 1} по квантилям. Используется при медленных метриках и необходимости устойчивости. 2.3.7. Экспертная шкала (строго ограниченная) x задаётся экспертно по сетке 0..1 с шагом 0.1. Условие: обязательно фиксируется протокол основания присвоения и ограничение Confidence. 2.3.8. Смешанная нормировка (композиция) x = g( f1(raw), f2(raw) ) Допускается только при формальной фиксации формулы g и параметров. Правило выбора схемы нормировки: (а) Если есть нормативные пороги L/H — предпочтение кусочно-линейной. (б) Если риск растёт резко после точки — предпочтение сигмоиде. (в) Если есть выбросы и нестабильность диапазонов — предпочтение ранговой/квантильной. (г) Экспертная шкала допустима только при отсутствии данных и должна снижать доверие. Изменение схемы нормировки считается критическим изменением конфигурации и требует теста совместимости: “до/после” на 3 сценариях (см. 2.16). 2.4. Весовая архитектура и защита от концентрации Вес фактора w_i определяет его вклад в SSI. Базовое условие: 0 ≤ w_i ≤ 1 sum w_i = 1 Однако этого недостаточно. Вводятся дополнительные ограничения. 2.4.1. Ограничение концентрации Определяется индекс концентрации весов: HHI = sum( w_i^2 ) Если HHI > 0.25 — структура весов считается перегретой. Норматив: HHI ≤ 0.25 для стандартной конфигурации HHI ≤ 0.30 допускается временно при Heightened HHI > 0.30 запрещено 2.4.2. Индекс доминанты фактора Dominance_i = w_i / ( средний вес ) где средний вес = 1/n Если Dominance_i > 3 — фактор считается доминантным. При наличии доминантного фактора: требуется письменное обоснование проводится тест устойчивости фиксируется в реестре 2.4.3. Защита от скрытого усиления Если фактор изменяет SSI более чем на 0.12 при изменении x_i на 0.10: | dSSI/dx_i | = w_i > 0.12 — фактор считается критически чувствительным. Требуется дополнительная проверка весов. 2.5. Чувствительность модели (расширенная) Полная чувствительность PRS к фактору: dPRS/dx_i = k * PRS * (1 − PRS) * w_i Максимум чувствительности достигается при PRS = 0.5. Критический режим чувствительности: Если PRS ∈ [0.45 ; 0.55] и w_i > 0.15 и NL > 0 — система находится в зоне высокой нелинейной чувствительности. В этой зоне любые корректировки запрещены без двойной проверки. 2.6. Тест устойчивости к подгонке (формализованный) Проводятся три типа теста. Тест A — локальное изменение веса Изменить каждый w_i на ±0.05 Пересчитать PRS Если |Delta_PRS| > 0.15 — модель нестабильна. Тест B — изменение порога нелинейности Изменить T_NL на ±0.05 Пересчитать PRS Если |Delta_PRS| > 0.12 — нелинейная архитектура чрезмерно чувствительна. Тест C — инъекция единичного шока Увеличить один x_i на 0.10 Пересчитать PRS Если PRS пересекает режимный порог — система требует перераспределения весов. 2.7. Критерий переобучения Модель считается переобученной, если одновременно: HHI > 0.25 и существует i, для которого |Delta_PRS| > 0.15 при Delta_x_i = 0.05 и FDS < 0.05 Это означает, что модель реагирует не на структуру, а на один фактор. При обнаружении переобучения: запуск пересборки весов, фиксация в журнале, временное снижение SLC до 0. 2.8. Вероятность смены режима PRS: логистическая форма и её параметры PRS определяется логистической функцией: PRS = 1 / (1 + exp(-k*(SSI - theta))) Параметр k задаёт крутизну перехода вероятности, theta — центральную точку. Норматив: k и theta фиксируются релизом версии. Любое изменение считается параметрическим дрейфом и требует формальной пересборки. 2.9. Производные и чувствительность: строгий расчёт Для контроля “хрупкости” и критичности факторов PSSR обязан считать чувствительность PRS к SSI и к отдельным факторам. Производная PRS по SSI: dPRS/dSSI = k * PRS * (1 - PRS) Производная PRS по фактору x_i: dPRS/dx_i = (dPRS/dSSI) * w_i Эластичность PRS по x_i (удобно для анализа вкладов): E_i = (dPRS/dx_i) * (x_i / max(PRS, eps)) где eps — малое число (например 1e-6) для избежания деления на ноль. Норматив интерпретации: если существует фактор i, для которого dPRS/dx_i существенно выше медианы по факторам (например, больше в 2 раза), фактор считается “критическим” и должен быть отдельно описан в отчёте. 2.10. Динамика во времени: минимум 4 точки (t0–t3) PSSR запрещает оценивать режим по одной точке, если это не аварийный расчёт. Нормативный расчёт проводится минимум по четырём точкам: t0 — базовая точка; t1 — после инъекции/события; t2 — первая адаптационная реакция; t3 — стабилизация или каскад. Для каждой точки считаются SSI(t), PRS(t), NL(t), FDS(t), CAI(t), Confidence(t). Определения динамики: Delta_SSI(t) = SSI(t) - SSI(t-1) VRC(t) = abs(Delta_SSI(t)) Delta_PRS(t) = PRS(t) - PRS(t-1) Норматив: если Delta_PRS(t) > 0.12 на одном шаге при Confidence>=0.6, это событие обязано запускать сценарный анализ (Том VI), так как система вошла в зону ускорения. 2.11. Структурная дивергенция факторов FDS FDS измеряет расслоение напряжения по кластерам. Сначала считаются кластерные значения C_j (см. 2.5). Далее: C_bar = (1/k) * sum_{j=1..k} C_j FDS = sqrt( (1/k) * sum_{j=1..k} (C_j - C_bar)^2 ) Норматив интерпретации: высокий FDS означает, что стресс сосредоточен в отдельных доменах (опасно, так как даёт каскады и социальные “провалы”), даже если SSI средний. 2.12. Скрытая хрупкость LVF и смысл “тихого перегрева” LVF связывает динамику и структуру: LVF = VRC * FDS Норматив: LVF используется, чтобы ловить ситуации “внешне спокойно, внутри расходится”. Если VRC низкий, но FDS высокий, LVF может быть умеренным; в таком случае PSSR требует отдельной диагностики “структурной хрупкости”, даже если PRS ещё не высок. 2.13. Индекс каскадной амплификации CAI (операциональная форма) CAI предназначен для оценки усиления кризиса при сочетании нелинейности, дивергенции и связности среды. Базовая форма: CAI = NL * FDS * R_bar где R_bar берётся из портфельного контура (Том IV) либо из локальной матрицы связности доменов (если расчёт не портфельный, R_bar задаётся конфигурацией домена и фиксируется). Расширенная форма для стресс-тестов второго порядка: CAI2 = (NL * FDS) + (sum_{i<j} R_ij * NL_i * NL_j) Норматив: CAI обязателен в отчёте при режимах Heightened и выше. Исключение CAI из расчёта без акта — дефект. 2.14. Доверие к данным: Confidence и режим деградации Confidence_i задаётся для каждого фактора. Общий Confidence рассчитывается как: Confidence = sum_{i=1..n} ( w_i * Confidence_i ) Режим деградации данных в математике реализуется через снижение чувствительности логистики: k_eff = k * Confidence PRS_eff = 1 / (1 + exp(-k_eff*(SSI - theta))) Норматив: в продуктах указывается PRS (каноническая) и PRS_eff (при низком доверии) либо явно фиксируется, что используется k_eff. Смешение без маркировки запрещено. Политика пропусков данных: если missing доля факторов по весам < 0.10, допускается имputation по последнему значению с понижением Confidence_i; если missing доля >= 0.10 и < 0.25, расчёт допускается только как “ограниченный”, SLC потолок снижается; если missing доля >= 0.25, расчёт считается неприемлемым для режимных выводов и требует остановки или перехода в “только факт”. 2.15. Контроль качества вероятности: калибровка PRS и проверка ошибок PSSR — вероятностная система; следовательно, PRS обязан иметь проверяемую калибровку. Том II фиксирует минимальные требования. 2.15.1. Событийная разметка (эталон): определяется набор исторических эпизодов, где фактически происходила смена режима. Разметка хранится внутри. 2.15.2. Метрика калибровки (примерная форма): Brier = (1/N) * sum_{t=1..N} (PRS_t - y_t)^2 где y_t = 1 если фактическая смена режима произошла в горизонте, иначе 0. 2.15.3. Метрика пропусков и ложных тревог: False_Alarm_Rate = FP / (FP + TN) Miss_Rate = FN / (FN + TP) Норматив: метрики считаются на окнах 12 и 24 месяца (или на минимум 3 эпизодах, если эпизодов мало). Пороговые значения и целевые диапазоны фиксируются в контуре управления (Том V), но требование считать метрики — часть математического канона. 2.16. Тесты устойчивости к подгонке: обязательный пакет Перед выпуском версии (и при крупных конфигурационных изменениях) выполняется пакет тестов устойчивости. Тест A (весовая устойчивость): для каждого фактора i выполняется w_i’ = w_i + delta, с перераспределением остальных весов так, чтобы сумма была 1; берутся delta = ±0.02 и ±0.05; измеряется max |PRS’ - PRS|. Тест B (нормировочная устойчивость): для каждого фактора меняется метод нормировки на альтернативный допустимый (например, min-max vs ранговый) на контрольном наборе, измеряется сдвиг SSI и PRS. Тест C (порог NL): меняется T_NL на ±0.05 (если допускается) на тестовом наборе, проверяется частота “ложных каскадов”. Тест D (чувствительность кривой): меняется k на ±10% (для анализа; не для продакшена), фиксируется чувствительность PRS к ошибке параметра. Норматив: если малые изменения дают скачки PRS > 0.15 на широком наборе, модель считается переострой или “хрупкой” и требует пересборки параметров либо усиления Confidence-режима. 2.17. Полный числовой пример расчёта (от сырых данных до режима), t0–t3 Ниже пример не “символический”, а полный, чтобы ты мог рукой проверить каждый шаг. Пусть 6 факторов, веса суммируются к 1. Факторы и веса: w1=0.20, w2=0.15, w3=0.20, w4=0.15, w5=0.20, w6=0.10 Параметры версии (пример для воспроизведения процедуры; конкретные значения версии фиксируются в релизе): k=10 theta=0.50 T_NL=0.60 alpha=2.50 Кластеры (k_clusters=3): cluster_1: {1,2} cluster_2: {3,4} cluster_3: {5,6} Окна и доверие: Confidence_i: c1=0.80, c2=0.70, c3=0.60, c4=0.70, c5=0.55, c6=0.65 Итоговый Confidence: Confidence = 0.200.80 + 0.150.70 + 0.200.60 + 0.150.70 + 0.200.55 + 0.100.65 Confidence = 0.16 + 0.105 + 0.12 + 0.105 + 0.11 + 0.065 = 0.665 t0: исходные нормированные факторы x1=0.30, x2=0.40, x3=0.35, x4=0.25, x5=0.45, x6=0.20 SSI(t0) = 0.200.30 + 0.150.40 + 0.200.35 + 0.150.25 + 0.200.45 + 0.100.20 SSI(t0) = 0.06 + 0.06 + 0.07 + 0.0375 + 0.09 + 0.02 = 0.3375 SSS(t0) = 1 - 0.3375 = 0.6625 NL(t0): так как SSI(t0)=0.3375 <= 0.60, NL(t0)=0 SSS_eff(t0) = max(0, 0.6625 - 0) = 0.6625 PRS(t0) = 1 / (1 + exp(-10*(0.3375 - 0.50))) 0.3375 - 0.50 = -0.1625 -10*( -0.1625 ) = +1.625 exp(1.625) ≈ 5.08 PRS(t0) ≈ 1 / (1 + 5.08) ≈ 0.164 (приблизительно; в рабочем расчёте фиксируется точнее) Кластеры: C1(t0) = (0.200.30 + 0.150.40)/(0.35) = (0.06 + 0.06)/0.35 = 0.3429 C2(t0) = (0.200.35 + 0.150.25)/(0.35) = (0.07 + 0.0375)/0.35 = 0.3071 C3(t0) = (0.200.45 + 0.100.20)/(0.30) = (0.09 + 0.02)/0.30 = 0.3667 C_bar(t0) = (0.3429 + 0.3071 + 0.3667)/3 = 0.3389 FDS(t0) = sqrt( ( (0.3429-0.3389)^2 + (0.3071-0.3389)^2 + (0.3667-0.3389)^2 ) / 3 ) Разности: 0.0040, -0.0318, 0.0278 Квадраты: 0.000016, 0.001011, 0.000773 Среднее: (0.001800)/3 = 0.000600 FDS(t0) ≈ sqrt(0.000600) ≈ 0.0245 Динамика на t0 не считается (нет t-1). CAI(t0)=0, LVF(t0)=0 по определению старта. t1: инъекция (рост одного домена) Пусть x5 возрастает до 0.70 (шок в cluster_3), остальные без изменений. x5=0.70 SSI(t1) = 0.200.30 + 0.150.40 + 0.200.35 + 0.150.25 + 0.200.70 + 0.100.20 SSI(t1) = 0.06 + 0.06 + 0.07 + 0.0375 + 0.14 + 0.02 = 0.3875 NL(t1)=0 (SSI still <=0.60) PRS(t1) = 1 / (1 + exp(-10*(0.3875-0.50))) 0.3875-0.50=-0.1125 -10*(-0.1125)=+1.125 exp(1.125) ≈ 3.08 PRS(t1) ≈ 1/(1+3.08)=0.245 Delta_SSI(t1)=0.3875-0.3375=0.0500 VRC(t1)=0.0500 Delta_PRS(t1)=0.245-0.164=0.081 (прибл.) Кластеры: C1(t1)=0.3429 (не изменился) C2(t1)=0.3071 C3(t1)=(0.200.70+0.100.20)/0.30=(0.14+0.02)/0.30=0.5333 C_bar(t1)=(0.3429+0.3071+0.5333)/3=0.3944 Разности: -0.0515, -0.0873, 0.1389 Квадраты: 0.002652, 0.007622, 0.019290 Среднее: 0.029564/3=0.009855 FDS(t1)=sqrt(0.009855)=0.0993 LVF(t1)=VRC(t1)FDS(t1)=0.05000.0993=0.0050 CAI(t1)=NLFDSR_bar=0 (NL=0) t2: развитие (добавляется вторичный рост + рост SSI ближе к NL) Пусть x3 растёт до 0.65, x5 остаётся 0.70. x3=0.65, x5=0.70 SSI(t2)=0.200.30 + 0.150.40 + 0.200.65 + 0.150.25 + 0.200.70 + 0.100.20 SSI(t2)=0.06+0.06+0.13+0.0375+0.14+0.02=0.4475 NL(t2)=0 (ещё <=0.60) PRS(t2)=1/(1+exp(-10*(0.4475-0.50))) 0.4475-0.50=-0.0525 -10*(-0.0525)=+0.525 exp(0.525)≈1.69 PRS(t2)≈1/(1+1.69)=0.372 Delta_SSI(t2)=0.4475-0.3875=0.0600 VRC(t2)=0.0600 Delta_PRS(t2)=0.372-0.245=0.127 (уже близко к триггеру) Кластеры: C1(t2)=0.3429 C2(t2)=(0.200.65+0.150.25)/0.35=(0.13+0.0375)/0.35=0.4786 C3(t2)=0.5333 C_bar(t2)=(0.3429+0.4786+0.5333)/3=0.4516 Разности: -0.1087, 0.0270, 0.0817 Квадраты: 0.01182, 0.00073, 0.00667 Среднее: 0.01922/3=0.00641 FDS(t2)=sqrt(0.00641)=0.0801 LVF(t2)=0.0600*0.0801=0.0048 CAI(t2)=0 (NL=0) Вывод по t2: PRS почти в зоне Heightened/Stress границы, Delta_PRS высокий. Даже без NL это уже режимная чувствительность; в реальном применении это заставляет запускать сценарное ветвление в Томе VI, а также проверку “порог NL близко”. t3: вход в нелинейность (SSI > T_NL) Пусть x5 растёт до 0.90, x3 остаётся 0.65. x5=0.90 SSI(t3)=0.200.30 + 0.150.40 + 0.200.65 + 0.150.25 + 0.200.90 + 0.100.20 SSI(t3)=0.06+0.06+0.13+0.0375+0.18+0.02=0.4875 Здесь всё ещё <=0.60; чтобы показать NL, увеличим дополнительно x1 до 0.80 (системный шок). x1=0.80 SSI(t3)=0.200.80 + 0.150.40 + 0.200.65 + 0.150.25 + 0.200.90 + 0.100.20 SSI(t3)=0.16+0.06+0.13+0.0375+0.18+0.02=0.5875 (всё ещё чуть ниже 0.60) Сделаем x2 до 0.80 (чтобы пересечь порог). x2=0.80 SSI(t3)=0.200.80 + 0.150.80 + 0.200.65 + 0.150.25 + 0.200.90 + 0.100.20 SSI(t3)=0.16+0.12+0.13+0.0375+0.18+0.02=0.6475 (пересекли T_NL) NL(t3)=alpha*(SSI-T_NL)^2=2.50*(0.6475-0.60)^2 0.6475-0.60=0.0475 (0.0475)^2=0.002256 NL(t3)=2.50*0.002256=0.00564 SSS(t3)=1-0.6475=0.3525 SSS_eff(t3)=max(0,0.3525-0.00564)=0.3469 PRS(t3)=1/(1+exp(-10*(0.6475-0.50))) 0.6475-0.50=0.1475 -10*(0.1475)=-1.475 exp(-1.475)=0.229 PRS(t3)=1/(1+0.229)=0.814 Delta_PRS(t3)=0.814-0.372≈0.442 (каскадный скачок вероятности на горизонте) Delta_SSI(t3)=0.6475-0.4475=0.2000 VRC(t3)=0.2000 Далее FDS(t3) пересчитывается; при таком скачке обычно FDS тоже растёт. CAI(t3)=NLFDSR_bar уже не ноль; при R_bar>=0.5 и FDS>=0.1 получим CAI порядка 0.00028–0.001, а при больших alpha/пересечении глубже — существенно выше. В реальном кризисе CAI значимо растёт, когда (а) NL уже не маленький и (б) FDS высокий. Здесь главное: переход в нелинейность резко увеличил PRS. Это демонстрация “зоны хрупкости”. Именно ради этого NL обязателен. Этот пример показывает полный ручной расчёт; в приложении к рабочему документу такие расчёты приводятся с точными экспонентами (калькулятор/таблица). 2.18. Полный каталог математических дефектов и диагностика (не список “ошибок”, а что делать) Дефект A: x_i выходит за [0,1]. Диагностика: проверка диапазона после нормировки; причина: неверные bounds, выбросы. Исправление: переход на ранговую/квантильную нормировку или пересмотр L/H с протоколом. Дефект B: сумма весов не равна 1. Диагностика: контроль sum w_i. Исправление: нормировка весов; запрет ручных поправок без записи. Дефект C: разные окна для факторов в одном расчёте. Диагностика: контроль window_type/window_length. Исправление: привести к одному горизонту либо вводить явную модель лагов (отдельная формула), но не “как получится”. Дефект D: исключение NL, FDS, CAI в режимах Heightened+. Диагностика: чек полноты индексов. Исправление: расчёт обязателен; при отсутствии данных — снижение Confidence и ограничение интерпретации. Дефект E: смена k/theta/alpha/T_NL без процедуры. Диагностика: сверка с базой версии. Исправление: акт дрейфа и формальная пересборка (Том V). Дефект F: “подгонка” весов под желаемый режим. Диагностика: тест устойчивости 2.16; аудит DI; проверка мотивировки. Исправление: возвращение к базовым весам, ограничение адаптации, пересборка методики. 2.19. Воспроизводимость вычисления (строгий тест) Расчёт считается воспроизводимым, если при одинаковых входах (raw, окна, паспорта факторов, версия, веса, пороги) выдаёт одинаковые SSI, NL, PRS, FDS, LVF, CAI. Нормативная проверка: повтор вычисления независимым оператором по паспорту расчёта. Любое расхождение выше допуска (например, 0.005 по SSI или 0.01 по PRS) фиксируется как дефект и требует разбор причин. 2.20. Обязательные приложения к Тому II (для печати и ручного прохождения) Приложение 2-А. Шаблон “Паспорт фактора” (для реестра) Все поля из 2.2.2 в виде формы. Приложение 2-Б. Шаблон “Паспорт расчёта” (математическая часть) Версия; параметры k, theta, T_NL, alpha; список факторов; raw; нормировка; x; w; кластеры; SSI/SSS; NL/SSS_eff; PRS; динамика; FDS/LVF/CAI; Confidence; вывод режима. Приложение 2-В. Протокол тестов устойчивости (A–D) Таблица изменений и эффектов на PRS/CAI. Приложение 2-Г. Протокол бэктеста PRS Разметка эпизодов; окна; метрики Brier/ложные тревоги/пропуски; выводы; решение о пересборке. Глоссарий англицизмов (только здесь) Registry — реестр. Backtest — бэктест (проверка на исторических эпизодах). Brier score — метрика калибровки вероятностей. Drift — дрейф параметров/процедур. Imputation — восстановление пропусков. Seed — фиксатор воспроизводимости (если используется в автоматизации). ТОМ III Режимный двигатель: фиксация режима, переходы, пакеты действий, подтверждение человеком, контроль отклонений и стабилизация Статус: внутренний нормативно-операционный том. Назначение: обеспечить воспроизводимое управление режимом в PSSR на основе индексов (Том II) и портфельных ограничений (Том IV), с дисциплиной подтверждения человеком (Том I) и управленческими реестрами (Том V). Принцип: PRS не является решением; режим фиксируется процедурой; смысловой уровень подчинён режиму и портфелю; любые отклонения фиксируются и устраняются до выпуска. 3.1. Режим как объект управления: что он регулирует Режим определяет: частоту пересчёта; допустимый смысловой уровень; обязательный пакет документов; требования к подтверждению человеком; допустимый язык; регламент обработки ошибок и дрейфа; правила входа/выхода из стабилизации. Режим не является “оценкой настроения” и не может устанавливаться произвольно. Режимная фиксация без расчёта индексов и без подписей недействительна. 3.2. Норматив режимов и их привязка к PRS (канон версии) Нормативные диапазоны PRS: PRS < 0.20 — Normal 0.20 <= PRS < 0.40 — Heightened 0.40 <= PRS < 0.60 — Stress PRS >= 0.60 — Severe Эти диапазоны являются каноном версии и меняются только формальным релизом. Режимная фиксация всегда сопровождается значениями: SSI, PRS, NL, FDS, LVF, CAI, Confidence, а также портфельными ограничениями (если объект в портфеле). 3.3. Принцип “режим не ниже реальности” (консервативное повышение) Даже если PRS формально ниже порога, режим повышается на один уровень при наличии любого из условий: (1) NL > 0 (активная нелинейность). (2) CAI >= CAI_warn (порог предупреждения, конфигурация версии). (3) Delta_PRS >= 0.12 за один шаг при Confidence >= 0.60. (4) FDS >= FDS_warn и одновременно VRC >= VRC_warn. (5) Confidence < 0.50 (режим повышается для контроля, но смысловой уровень снижается). (6) Портфельный режим выше индивидуального (портфель ограничивает объект). Понижение режима не допускается “сразу после улучшения”: действует правило окна выхода (см. 3.12). 3.4. Процедура фиксации режима (обязательный порядок) Фиксация режима состоит из восьми шагов и заканчивается выпуском карточки режимной фиксации. Шаг 1. Расчёт индексов (SSI, PRS, NL, FDS, LVF, CAI, Confidence) по Тому II. Шаг 2. Проверка портфельных ограничений (P_PRS, OLI, CI, R_bar) по Тому IV. Шаг 3. Проверка триггеров консервативного повышения (3.3). Шаг 4. Назначение режима по канону. Шаг 5. Назначение потолка SLC и языкового режима. Шаг 6. Назначение частоты пересчёта и обязательных документов (пакет режима). Шаг 7. Подтверждение человеком (одно/двойное по режиму). Шаг 8. Запись в журнал режима и выпуск карточки (Приложение 3-А). Если любой шаг отсутствует, режим не считается установленным. 3.5. Подтверждение человеком: SLA, роли, запрет узкого горлышка Подтверждение человеком является обязательным в режимах Heightened и выше. Вводится нормативное SLA подтверждения, чтобы Human-in-the-Loop не превращался в отказ системы по нагрузке. Норматив SLA по режимам (внутренний стандарт): Normal: подтверждение итогового продукта в окне отчёта. Heightened: подтверждение в пределах 24 часов с момента расчёта. Stress: подтверждение в пределах 12 часов; для критических переходов — 6 часов. Severe: подтверждение в пределах 4 часов; при отсутствии подтверждения документ выпускается только в режиме “только факт” и с отметкой “неподтверждено для интерпретаций”. Роли подтверждения: аналитик рассчитывает и оформляет; режимный контролёр проверяет дисциплину; подтверждающий утверждает режим/ограничения; при Severe обязательно двойное подтверждение (два независимых подтверждающих либо подтверждающий + управляющий партнёр). 3.6. Пакеты действий по режимам (полная спецификация) Каждый режим имеет фиксированный набор обязательных документов и действий. Пакет — это не “рекомендация”, а минимальный стандарт. 3.6.1. Normal: пакет N Частота пересчёта: по базовому окну объекта (обычно недельная). SLC: 0–2 (SLC=2 допускается только при Confidence>=0.7 и без NL). Обязательные документы: (а) паспорт расчёта; (б) еженедельный обзор состояния; (в) реестр факторов (обновление); (г) журнал изменений (если были). Обязательные поля в обзоре: режим; SSI/PRS; ключевые факторы; Confidence; краткий вывод без усиления; перечень действий на окно. Запреты: гарантии, категоричность, “конечные” выводы. 3.6.2. Heightened: пакет H Частота пересчёта: минимум дважды на базовое окно, при быстрых изменениях — ежедневный пульс. SLC: потолок 1; SLC=2 допускается только отдельным актом, при Confidence>=0.7, при NL=0 и при CAI ниже порога. Обязательные документы: (а) карточка режимной фиксации; (б) Daily Pulse при необходимости; (в) сценарная матрица (минимум 2 сценария); (г) реестр факторов; (д) журнал решений и подтверждений. Обязательные поля Daily Pulse: факты; индексные изменения; Delta_PRS; FDS/LVF; ограничения; что подтверждено; что требует подтверждения; что пересчитывается дальше. Запреты: мобилизационный тон, персональные квалификации, демонизация. 3.6.3. Stress: пакет S Частота пересчёта: ежедневная, при высоком VRC — дважды в день. SLC: потолок 0; SLC=1 допускается как ограниченная интерпретация, привязанная к индексам и только при Confidence>=0.7. Обязательные документы: (а) карточка перехода (если был переход); (б) Daily Pulse; (в) сценарная матрица (минимум 3 сценария, включая worst-case); (г) акт ограничений; (д) план стабилизации (инициализация 30D при риске Severe); (е) журнал дрейфа и журнал подтверждений. Обязательные поля: индексы; портфельные ограничения; перечень запрещённых интерпретаций; перечень мер сдерживания. Запреты: стратегическая рамка, доктринальный тон, “политическое усиление”. 3.6.4. Severe: пакет V Частота пересчёта: минимум дважды в сутки и после каждого значимого факта. SLC: только 0, без исключений. Обязательные документы: (а) акт Severe; (б) стабилизационный протокол 30D; (в) акт портфельного сдерживания (если портфель); (г) акт деградации данных (если Confidence падает); (д) журнал подтверждений с SLA. Обязательные поля: строгий перечень фактов; расчёты; режим; ограничения; стабилизационный план; критерии выхода; подписи. Запреты: любые интерпретации вне индексов, любые “идейные” рамки, любые выводы о мотивах. 3.7. Языковая дисциплина по режимам (редакционный регламент) Режим накладывает обязательные ограничения на формулировки. Это не “стиль”, а режимная защита. Normal: допускаются конструкции “в пределах”, “на текущих данных”, “при сохранении предпосылок”. Запрещены “точно”, “безусловно”, “неизбежно”. Heightened: допускаются “вероятность повышена”, “требуется усиление контроля”, “вводятся ограничения”. Запрещены “общество требует”, “надо срочно” без индексов. Stress: допускаются “ограничить”, “сдерживать”, “пересчитать”, “минимизировать”. Запрещены “мобилизовать”, “наказать”, “выдавить”, любые демонизирующие формулы. Severe: допускается только “факт/расчёт/ограничение/стабилизация”. Любая оценочная лексика удаляется. Норматив: документ проходит проверку языковой санитарии до выпуска; несоответствие режима — основание отклонения. 3.8. Формальная архитектура переходов режима Режим не может изменяться неформально. Любое изменение режима должно соответствовать трём уровням легитимности: L1 — расчётное основание L2 — процедурное подтверждение L3 — журналирование и выпуск карточки Если любой уровень отсутствует — переход считается недействительным. 3.9. Запрет “ручного понижения режима” Понижение режима допускается только при одновременном выполнении всех условий: (1) PRS устойчиво ниже нижней границы текущего режима не менее N шагов (2) NL = 0 (3) CAI ниже предупреждающего порога (4) FDS ниже FDS_warn (5) Confidence ≥ 0.7 (6) Портфельный режим не выше Если хотя бы одно условие не выполнено — понижение запрещено. Ручное понижение без выполнения условий классифицируется как нарушение класса I. 3.10. Окно выхода из режима (строгий норматив) Минимальные окна: Severe → Stress: минимум 3 расчётных цикла без превышения порогов Stress → Heightened: минимум 5 циклов Heightened → Normal: минимум 10 циклов Под “циклом” понимается полный пересчёт с фиксацией. Окно не может быть сокращено решением оператора. 3.11. Режимная заморозка (Freeze Protocol) Если: выявлено нарушение класса I, зафиксирован режимный дрейф, зафиксирован конфликт между подтверждающими, зафиксировано внешнее давление на понижение, — активируется режимная заморозка. Заморозка означает: режим фиксируется на текущем уровне или повышается на 1 ступень, SLC ограничивается до 0, выпускаются только фактологические документы, проводится аудит расчёта, проводится проверка весов и параметров. Заморозка снимается только актом управляющего партнёра. 3.12. Матрица режимных конфликтов Конфликт типа А: аналитик ↔ подтверждающий Если подтверждающий не согласен с режимом: производится повторный расчёт, фиксируются расхождения параметров, принимается консервативное решение (режим выше). Конфликт типа B: подтверждающий ↔ подтверждающий (двойное подтверждение) Если два подтверждающих не согласны: режим автоматически повышается на один уровень до разрешения, активируется заморозка, решение принимает управляющий партнёр. Конфликт типа C: заказчик требует понижения Процедура: фиксируется требование в журнале, проверяются условия 3.9, при несоответствии — отказ, при повторяемости — запускается протокол «игнорирование предупреждений» (Том V). 3.13. Режимный дрейф Режимный дрейф — это постепенное снижение режима без формального основания. Признаки: понижение режима при PRS > порога, отсутствие карточек перехода, снижение SLC без расчёта, изменение параметров перед понижением. При выявлении дрейфа: режим восстанавливается, проводится аудит 5 последних расчётов, фиксируется инцидент. 3.14. Откат режима Если переход вверх был ошибочным (например, вследствие ошибки данных): Порядок отката: (1) подтверждение корректировки данных; (2) пересчёт индексов; (3) фиксация акта корректировки; (4) отдельная карточка отката; (5) запись в журнал версий. Откат не является “понижением”, а оформляется как отдельный режимный акт. 3.15. Санкции за несанкционированное понижение Нарушение режима класса I: временное ограничение прав расчёта, обязательный аудит, обязательное двойное подтверждение в следующих 5 циклах. Система должна быть защищена от внутренней эрозии. ПРИЛОЖЕНИЯ Тома III (полный набор форм) Приложение 3-А. Карточка режимной фиксации: идентификатор; дата; объект; окно; SSI; PRS; NL; FDS; LVF; CAI; Confidence; портфельный режим; потолок SLC; пакет; частота пересчёта; подписи. Приложение 3-Б. Карточка перехода режима: старый режим; новый режим; основание (индексы + триггеры); список изменений в пакете; SLA; подписи; дата пересмотра. Приложение 3-В. Шаблон Daily Pulse: факты; индексная динамика; кластерный профиль; LVF/CAI; ограничения; подтверждения; действия на следующее окно. Приложение 3-Г. Акт стабилизации 30D: фаза; цели; индексы; меры; ограничения; статус данных; портфель; подписи; дата следующей проверки. Приложение 3-Д. Акт режимного отклонения: описание; класс; влияние; меры; пересчёт; подписи. Приложение 3-Е. Акт “операторская ошибка + дрейф + мультизона”: триггеры; пересчёт на чистой конфигурации; ограничения; временный режим; подписи. ТОМ IV Портфельная архитектура, экономика платформы и пределы масштабирования Статус: внутренний нормативно-управленческий том. Назначение: описать PSSR как устойчивую бутиковую платформу при одновременной работе с несколькими объектами, исключить корреляционный перегрев, портфельный каскад, операционную деградацию и коммерческий дрейф. Принцип: портфель — самостоятельная система второго порядка; её режим ограничивает стратегическую амбицию и скорость расширения. Ограничения: PSSR не передаётся третьим лицам; наружу выдаются только результаты и документы (см. Том V). 4.1. Портфель как система второго порядка Портфель — это совокупность m объектов, каждый из которых имеет собственные индексы. Для каждого объекта j: SSI_j PRS_j NL_j CAI_j Confidence_j Портфельные агрегаты: P_SSI = (1/m) * sum SSI_j P_PRS = (1/m) * sum PRS_j P_NL2 = (1/m) * sum (NL_j^2) P_CAI = (1/m) * sum CAI_j 4.2. Связность портфеля Вводится коэффициент средней связности: R_bar = среднее число связей между объектами / (m − 1) Если R_bar > 0.5 — портфель считается высокосвязанным. Высокая связность усиливает каскад. 4.3. Портфельный каскад Portfolio_Cascade = P_CAI * R_bar Если Portfolio_Cascade > 0.03 — портфель переходит в режим Stress независимо от среднего PRS. Если > 0.06 — Severe портфеля. 4.4. Индекс операционной нагрузки (OLI) OLI = ( sum Load_j ) / Capacity_total где: Load_j = 1 при Normal Load_j = 2 при Heightened Load_j = 3 при Stress Load_j = 4 при Severe Capacity_total = ( H * C_h ) + ( A * C_a ) H — количество подтверждающих C_h — подтверждений в день на одного подтверждающего A — количество аналитиков C_a — расчётов в день на аналитика Если OLI > 1.0 — система перегружена. Если OLI > 1.2 — риск деградации качества. Если OLI > 1.5 — запрет на новые объекты. 4.5. Максимально допустимое количество объектов (m_max) Предел определяется не числом клиентов, а нагрузкой. m_max ≈ Capacity_total / Avg_Load где: Avg_Load = средняя нагрузка на объект. Если Avg_Load = 2.5 Capacity_total = 25 m_max ≈ 10 Это динамический предел. 4.6. Когнитивный предел подтверждения человеком Вводится ограничение: Max_confirmations_per_day_per_person ≤ 8 После 8 подтверждений качество падает. Если фактическое число > 8: Confidence_portfolio снижается на 0.05. Если > 12: режим портфеля повышается на 1 уровень. 4.7. Деградация качества при росте портфеля Если m растёт быстрее, чем Capacity_total: Quality_loss = (OLI − 1.0) * 0.2 PRS_portfolio корректируется: PRS_adj = min(1 , P_PRS + Quality_loss) Это защитный механизм. 4.8. Экономическая устойчивость Доход портфеля: Revenue = sum Fee_j Затраты: Cost = Staff_cost + Infrastructure + Crisis_reserve В кризисе: Stress_multiplier = 1 + ( P_CAI * 2 ) Cost_crisis = Cost * Stress_multiplier Экономическая устойчивость: Stability_ratio = Revenue / Cost_crisis Если Stability_ratio < 1.2 — запрещено расширение портфеля. Если < 1.0 — вводится режим экономической стабилизации. 4.9. Порог институционального перегрева Перегрев наступает при одновременном выполнении: OLI > 1.2 Portfolio_Cascade > 0.03 P_NL2 > 0 Confidence_portfolio < 0.6 В этом случае: запрет на новые проекты, снижение SLC до 0, обязательный аудит, стабилизация портфеля. 4.10. Запрет на экспансию Запрещено: принимать новых клиентов при OLI > 1.2 расширять scope существующих при P_CAI > 0.03 снижать режим портфеля при перегреве Любое нарушение фиксируется как класс I. 4.11. Регламент сокращения портфеля (выход, приостановка, закрытие) Сокращение портфеля применяется при Severe либо при OLI > 1.3 устойчиво на протяжении двух циклов. Порядок: (1) ранжирование объектов по beta_i и по текущему PRS; (2) приостановка низкоприоритетных объектов в формате “только факт” либо временная заморозка; (3) акт перераспределения ёмкости; (4) пересчёт портфеля; (5) контроль восстановления OLI и CI. 4.12. Сценарные проверки портфеля (минимум четыре обязательных) 4.12.1. Сценарий “10 объектов одновременно”. Задаётся: m=10, распределение режимов, q_i по режимам, оценка R_bar. Считаются: OLI, CI, P_PRS, P_CAI, Cost_port, Margin_rate, ESI. Если OLI > 1.3, сценарий считается недопустимым для текущей Capacity. 4.12.2. Сценарий “мультизона + портфель”. Два объекта одновременно входят в Stress в разных доменах при высокой связности (R_bar >= 0.6). Проверяется рост P_NL2 и выход в портфельный Severe. 4.12.3. Сценарий “ложный медиашум + персональный кейс”. Один объект получает рост VRC (медиашум), второй — рост CAI (персональная атака). Проверяется, не приводит ли суммарная связность к портфельному каскаду ошибочно. 4.12.4. Сценарий “деградация данных в одном домене”. Confidence падает у части объектов. Проверяется, что портфель автоматически снижает смысловой потолок и не расширяется. 4.13. Контрольные таблицы портфеля (обязательные для печати и ручной проходки) Таблица 1. Паспорт портфеля: список объектов, тип, beta_i, режим, SLC, Confidence, частота пересчётов, q_i. Таблица 2. Реестр корреляций: матрица R_ij, дата утверждения, инициатор, основание, изменения. Таблица 3. Отчёт о портфельной устойчивости: P_PRS, P_CAI, R_bar, P_NL2, OLI, CI, Risk_total, ESI, решения, ограничения. 4.14. ПРИЛОЖЕНИЯ (формы актов) Приложения пишу в плотной форме, без “воздуха”, пригодно для копирования. Приложение 4-А. Акт приёма объекта в портфель. Идентификатор объекта; 2) тип; 3) beta_new; 4) PRS_new, CAI_new, Confidence_new; 5) q_new; 6) изменения P_PRS’, P_CAI’, R_bar’, OLI’, CI’; 7) итоговый портфельный режим; 8) ограничения SLC; 9) решение (принять/принять с условиями); 10) условия (увеличение Capacity, лимиты); 11) подписи (аналитик, режимный контролёр). Приложение 4-Б. Акт отказа в приёме объекта. Основание отказа (превышение OLI/CI, рост портфельного режима до Stress/Severe, высокая R_bar); расчёты “до/после”; условия, при которых приём станет возможен (увеличение Capacity, снижение связности, изменение состава портфеля); подписи. Приложение 4-В. Акт портфельного сдерживания. Основание (P_PRS, P_CAI, OLI, CI, R_bar); перечень ограничений (SLC потолок, запрет расширения, приоритеты); срок; дата пересмотра; подписи. Приложение 4-Г. Акт перераспределения ёмкости. Текущие Capacity, Q (подтверждения), Total_hours; распределение по объектам; что приостанавливается; что усиливается; новый OLI и CI; подписи. Приложение 4-Д. Акт портфельной стабилизации. Портфельный режим до/после; меры; динамика OLI и P_PRS; срок действия; подписи. Глоссарий англицизмов (только здесь) Портфельное сдерживание — Portfolio Containment (не использовать в тексте). Корреляция — correlation (не использовать). Маржинальность — margin (не использовать). ТОМ V v10.1 GOVERNANCE, ДРЕЙФ, АУДИТ, ВОСПРОИЗВОДИМОСТЬ, БЕЗОПАСНОСТЬ И КОНТУРЫ ВЫПУСКА 0. Статус документа и область действия Назначение: задать обязательные правила управления PSSR как инженерной системой: изменения, контроль дрейфа, аудит, воспроизводимость, выпуск продуктов, ограничения, безопасность. Область действия: применяется ко всем объектам, продуктам, версиям ядра, интеграциям и операционным процессам (в т.ч. при ручной работе без софта). Непререкаемость: положения Тома V не могут отменять Инварианты Тома I. Любое противоречие трактуется в пользу Тома I. 1. Определения (минимальный словарь) Ядро (Core): формулы, пороги, веса, преобразования, индексы, режимная логика. Слой данных (Data Layer): источники, коннекторы, снапшоты, нормировки. Слой продукта (Product Layer): шаблоны, тексты, визуализации, нарративные правила. Governance: совокупность процедур и блокировок, исключающих недетерминированность, дрейф и нарушения допустимости. Drift: любое изменение, способное изменить результат при тех же входных данных. Repro Pack: полный набор артефактов, позволяющий воспроизвести выпуск “бит-в-бит” (или в пределах оговоренного допуска, если речь о внешних источниках). Release: версия системы, прошедшая процедуры тестирования и подписанная Owner. ЧАСТЬ I. РОЛИ, ПРАВА, СРЕДЫ 2. Роли (операционная модель) 2.1 Owner (единственный утверждающий контур) Имеет право: утверждать выпуск продуктов уровня Heightened/Stress/Severe; подтверждать смену режима; инициировать и подписывать релизы; инициировать Formal Reset; назначать Reviewer/Auditor; утверждать исключения (кроме L0/HI-1). Не имеет права: обходить L0; отключать аудит; выпускать продукт без Repro Pack (в случаях, где он обязателен). 2.2 Assistant (исполнитель) Может: собирать входы/источники; готовить черновики; считать индексы; формировать Repro Pack (черновой). Не может: менять параметры ядра; повышать SLC; финализировать выпуск. 2.3 Reviewer (контур качества текста и допустимости) Отвечает за: L0/L1/L2 корректность; CS-Class протокол; соблюдение SLC; отсутствие директивности/манипулятивных формулировок; соответствие продуктовым шаблонам. 2.4 Auditor (контур системной честности) Отвечает за: Drift-аудит; воспроизводимость; целостность журналов; соответствие релизов процедурам. 3. Уровни доступа (RBAC-логика для будущего софта) RBAC-0 (Read-Only): чтение продуктов без доступа к ядру/входам. RBAC-1 (Analyst): чтение + подготовка входов + черновики, без изменения ядра. RBAC-2 (Reviewer): утверждение текста/допустимости, без изменения ядра. RBAC-3 (Owner): утверждение релизов и выпусков, доступ к управлению ядром. RBAC-4 (Auditor): доступ к журналам, Repro Pack, тестам; без права менять ядро. 4. Разделение сред (для детерминизма и безопасности) DEV: эксперименты, прототипы, без права на выпуск. STAGE: предрелизная среда тестирования. PROD: единственная среда выпуска продуктов. Запрещено: выпускать из DEV/STAGE; менять ядро напрямую в PROD. ЧАСТЬ II. КЛАССЫ ИЗМЕНЕНИЙ И РЕЛИЗ-ПРОЦЕСС 5. Классификация изменений (Change Classes) C0 (No-Change): косметика, не влияющая на расчёт/вывод (опечатки шаблонов). C1 (Product-Only): изменения шаблонов/формулировок без изменения индексов. C2 (Data-Connector): изменения коннекторов/источников без изменения логики ядра. C3 (Normalization): изменения нормировок, шкал, правил преобразования входов. C4 (Weights/Thresholds): изменения весов/порогов/границ режимов. C5 (Core Logic): изменения формул, индексов, режима, каскадов, нелинейностей. C6 (Emergency Hotfix): аварийные исправления, требующие ускоренного процесса. Правило: класс изменения определяется по максимальному риску, а не по намерению автора. 6. Release-процедура (общая) Любой релиз обязан пройти: R1) Change Note (что изменили, класс изменения, причина). R2) Impact Map (какие индексы/режимы/продукты затронуты). R3) Regression Suite (минимальный набор тестов). R4) Drift Calculation (DI/профиль дрейфа). R5) Repro Pack Update (обновление реплицируемости). R6) Owner Signature (подпись релиза). 7. Emergency Hotfix (C6) Допускается только если: ошибка приводит к неверным режимам/индексам, ошибка нарушает L-логику или безопасность, ошибка нарушает детерминизм. Процедура C6: Hotfix в STAGE, минимальный Regression Suite, DI расчёт, выпуск в PROD, пост-аудит в течение 72 часов, обязательное “закрытие хвоста” полным релизом C3-C5. ЧАСТЬ III. DRIFT: МЕТРИКИ И БЛОКИРОВКИ 8. Drift-модель (что считается дрейфом) Drift фиксируется, если изменилось хотя бы одно из: формулы индексов, веса/пороги, правила нормировки, источники и их преобразования, логика Confidence, логика L0/L1/L2, шаблоны, которые меняют смысловой уровень или директивность. 9. Drift Index (DI) и профили дрейфа DI задаётся как векторный показатель, а не одной цифрой: DI_core (формулы/логика) DI_param (веса/пороги) DI_data (источники/коннекторы/нормировки) DI_product (шаблоны/нарратив) DI_policy (L-логика/CS-Class/ограничения) Релиз считается “тяжёлым”, если любой компонент превышает критический порог. Правило: при тяжёлом дрейфе обязателен Formal Reset. 10. Formal Reset (обязательная пересборка) Formal Reset = процедура “пересборки механизма”: FR-1: Заморозка предыдущей версии FR-2: Полный пакет тестов FR-3: Backtest на исторических кейсах КЗ/ЦА (без политической конкретики: валютная волатильность, сырьевые шоки, логистика, инфляционные ожидания, медиатурбулентность) FR-4: Stress-тест синтетикой FR-5: Сравнение режимов и индексов “до/после” FR-6: Доклад Owner + подпись FR-7: Обновление эталонных baseline-пакетов ЧАСТЬ IV. АУДИТ И ВОСПРОИЗВОДИМОСТЬ 11. Repro Pack (обязательный стандарт) Каждый выпуск Heightened+ и каждый релиз обязан иметь Repro Pack: RP-A: Идентификаторы ID выпуска дата/время объект версия ядра версия шаблонов версия коннекторов RP-B: Входы список факторов исходные значения нормированные значения правила нормировки (в виде ссылок на версию схемы) RP-C: Источники и lineage источники (перечень) дата доступа тип источника (официальный/рынок/медиа/экспертный) “снапшот” (ссылка/хэш/архив) RP-D: Расчёт значения индексов режим вклад топ-факторов (Explainability Trace) Confidence и почему он такой RP-E: Допустимость L0/L1/L2 CS-Class флаг SLC применённые ограничения RP-F: Подписи кто собрал кто проверил кто утвердил 12. Explainability Trace (обязательная декомпозиция) Для каждого ключевого вывода: “что подняло режим” “топ-3 вклада” “что было неопределённо” Запрещено публиковать “итог” без объяснения причин. 13. Audit Log как неизменяемый журнал Audit Log должен быть: последовательным, с контрольными суммами, с запретом заднего редактирования, с хранением версий. Даже в “ручной” реализации требуется минимум: нумерация записей, запрет удаления, отдельный архив. ЧАСТЬ V. L0/L1/L2, CS-CLASS И НАРРАТИВНЫЕ ОГРАНИЧЕНИЯ 14. L-логика как блокировочный контур L0: запрещено формировать продукт, запрещено давать советы/инструкции. Только отказ/безопасная альтернатива. L1: допускается нейтральное описание/анализ в рамках закона и протоколов; требуется Reviewer. L2: допускаются сценарии/гипотезы, но без директив и с ограничителем SLC; требуется Owner. Правило: классификация L-уровня фиксируется в Repro Pack и Audit Log. 15. CS-Class (культурно-чувствительные темы) CS-Class — это не “тема”, а режим управления риском интерпретации. Триггеры: высокий риск общественного/репутационного ущерба, высокий риск юридической ошибки, слабая наблюдаемость данных (цензура/самоцензура/искажение). При CS-Class: L автоматически не выше L1 (если не решено Owner’ом по процедуре), SLC ≤ 1, обязательный Double Review, запрет на оценочные или активирующие формулировки, продукт допускается только как “технический”. 16. SLC-ограничитель (Narrative Throttle) SLC = смысловой уровень амбиции. SLC=0: только факты/наблюдаемое/описание SLC=1: осторожная интерпретация, вероятностная SLC=2: сценарии/варианты SLC=3: рекомендации/стратегические рамки (разрешено только при высоком Confidence и вне CS-Class) Автоправило: если Confidence ниже порога → SLC снижается автоматически. ЧАСТЬ VI. КАЧЕСТВО ДАННЫХ И CONFIDENCE GOVERNANCE 17. Data Quality Gate Перед расчётом: свежесть данных полнота факторов согласованность источников наличие выбросов наличие “дыру” по кластерам Если Gate не пройден: повышается неопределённость, SLC ограничивается, возможно блокирование выпуска. 18. Confidence как функция наблюдаемости Confidence фиксируется не “впечатлением”, а по протоколу: Coverage (покрытие факторов) Source Reliability (надежность источников) Freshness (актуальность) Consistency (согласованность) Noise (уровень шума) Дальше в софте это станет формулой. В документе — это обязательная структура аргументации. ЧАСТЬ VII. ОПЕРАЦИОННЫЕ ЛИМИТЫ И ПОРТФЕЛЬ 19. OLI и Capacity Budget OLI фиксирует перегрузку, но нужен бюджет: Ежеквартально: оценка фактической нагрузки доля времени на maintenance доля времени на продукты доля времени на аудит Если maintenance > 30%: упрощение не-ядровых частей снижение объёма Tier-2/3 повышение автоматизации черновиков 20. Portfolio Containment Условия включения: OLI выше лимита несколько объектов одновременно Heightened+ растущий DI Действия: стоп новых объектов выпуск только приоритетных продуктов запрет на новые L2 сценарии заморозка изменений ядра (кроме hotfix) ЧАСТЬ VIII. INCIDENT RESPONSE 21. Классы инцидентов I1 (Data Incident): неверный источник/сбой коннектора/подмена данных I2 (Model Incident): ошибка формулы/порога/режима I3 (Product Incident): неверная формулировка/нарушение SLC/L-логики I4 (Security Incident): утечка/несанкционированный доступ I5 (Process Incident): выпуск без подписей/без Repro Pack 22. Процедура реакции Заморозка выпуска Фиксация состояния (снапшот) Определение класса инцидента Исправление в STAGE Проверка Regression Suite Доклад Owner Выпуск исправления Пост-аудит и уроки (обновление протоколов) ЧАСТЬ IX. ПРОВЕРКИ ПЕРЕД ВЫПУСКОМ 23. Pre-Release Checklist (Heightened+) P1: Repro Pack полный P2: L-уровень корректен P3: CS-Class обработан P4: SLC соответствует Confidence P5: Explainability Trace присутствует P6: Режим подтверждён P7: Audit Log обновлён P8: OLI в норме или включён Containment P9: Нет активных Hard Interrupt Если любой пункт не выполнен — выпуск запрещён. ЧАСТЬ X. HARD INTERRUPT И ИСКЛЮЧЕНИЯ 24. Hard Interrupt (HI) как “предохранитель” HI срабатывает при: L0 конфликте, попытке обхода процедур, выпуске без артефактов, дрейфе без релиза, нарушении безопасности. Снятие HI: возможно только Owner’ом, фиксируется в Audit Log, обязательно указывается безопасная альтернатива. HI-1 (правовой конфликт) не снимается. ТОМ VI Сценарное моделирование, стресс-тестирование, динамические симуляции и регламент кризисного применения 6.0. Назначение тома Том VI определяет порядок моделирования развития событий во времени, проверку устойчивости модели к различным типам шоков, обработку комбинированных кризисов, фиксацию результатов и оформление решений. Этот том отвечает на вопрос: «Как система ведёт себя под нагрузкой?» 6.1. Общий регламент прохождения сценария Любой сценарий проходит 12 стадий. Фиксация базового состояния (t0). Формирование гипотезы шока. Формализация изменения факторов. Пересчёт SSI. Пересчёт NL. Пересчёт PRS. Анализ Delta_PRS. Расчёт FDS. Расчёт LVF и CAI. Проверка Confidence. Портфельный пересчёт. Режимное решение и оформление акта. Если этап пропущен — сценарий недействителен. 6.2. Нелинейная динамика во времени (расширенная формализация) Сценарий в PSSR рассматривается как дискретный динамический процесс. Вводится индекс времени t ∈ {0,1,2,3,…,T} Для каждого t рассчитываются: SSI(t) NL(t) PRS(t) FDS(t) CAI(t) Confidence(t) 6.2.1. Динамика SSI SSI(t+1) = SSI(t) + sum_i ( w_i * Delta_x_i(t) ) где Delta_x_i(t) = x_i(t+1) − x_i(t) 6.2.2. Нелинейная поправка Если SSI(t) > T_NL: NL(t) = alpha * ( SSI(t) − T_NL )^2 иначе NL(t) = 0 6.2.3. Эффективная устойчивость SSS_eff(t) = max( 0 , 1 − SSI(t) − NL(t) ) 6.2.4. Вероятность смены режима PRS(t) = 1 / ( 1 + exp( −k * ( SSI(t) − theta ) ) ) 6.2.5. Ускорение вероятности Delta_PRS(t) = PRS(t) − PRS(t−1) Ускорение: Accel_PRS(t) = Delta_PRS(t) − Delta_PRS(t−1) Если Accel_PRS(t) > 0 — система входит в фазу ускорения. Если одновременно: SSI(t) > T_NL Accel_PRS(t) > 0 FDS(t) > FDS_warn — активируется режим предкаскада. 6.3. Многошаговая каскадная модель Каскад в PSSR — это не “высокий PRS”, а совпадение трёх процессов: (1) Нелинейность активна (2) Дивергенция растёт (3) Связность среды высокая Вводится каскадный индекс второго порядка: Cascade(t) = NL(t) * FDS(t) * R_bar * Accel_PRS(t) Если Cascade(t) > 0.01 — фиксируется предкаскад. Если Cascade(t) > 0.03 — каскад активирован. Это формальный триггер. 6.4. Сценарная матрица второго порядка Каждый сценарий классифицируется по двум осям: Ось 1 — тип шока Ось 2 — стадия развития Типы шоков: S1 — линейный S2 — нелинейный S3 — мультизональный S4 — деградация данных S5 — портфельный S6 — комбинированный Стадии: Stage A — инъекция Stage B — реакция Stage C — ускорение Stage D — стабилизация/каскад Каждый сценарий обязан пройти все стадии. Если стадия C отсутствует — сценарий считается неполным. 6.5. Формализованный Worst-Case протокол Worst-Case не означает «максимально плохой». Он означает совпадение пяти триггеров. Условия: SSI > 0.65 NL > 0 Delta_PRS > 0.15 FDS > 0.12 Confidence < 0.50 OLI > 1.3 Если 4 из 6 условий выполнены → Severe. Если 5 из 6 → Severe + Stabilization 30D. Если 6 из 6 → Severe + портфельное сдерживание + аудит слоя B. 6.6. Сценарная деградация данных (расширенная) Confidence(t) = sum( w_i * Confidence_i(t) ) Вводится корректирующий коэффициент: k_eff(t) = k * Confidence(t) PRS_eff(t) = 1 / ( 1 + exp( −k_eff(t) * ( SSI(t) − theta ) ) ) Если Confidence < 0.50: SLC_max = 0 Пересчёт обязателен чаще Портфельный режим повышается на 1 уровень Если Confidence < 0.35: режим не может быть ниже Stress независимо от PRS. 6.7. Ложный медиашум (расширенный фильтр) Медиашум определяется как: VRC(t) > 0.15 FDS(t) < 0.05 NL(t) = 0 Тогда: CAI ≈ 0 Cascade ≈ 0 Режим повышается максимум до Heightened, но не Stress. Обязательная проверка через 1 шаг времени. 6.8. Интегральный стресс-день (полная процедура) Шаг 1 — пересчёт всех объектов. Шаг 2 — пересчёт портфеля. Шаг 3 — расчёт: P_PRS P_CAI OLI CI R_bar P_NL2 Шаг 4 — определение портфельного режима. Шаг 5 — ограничение SLC. Шаг 6 — фиксация акта интегрального кризиса. Если P_CAI > 0.05 и OLI > 1.3 — автоматический запрет расширения. 6.9. Калибровка сценариев (то, чего не было вообще) Каждый сценарий обязан иметь: Scenario_ID Версия модели Исходные параметры Модифицированные параметры Расчёт до/после Дельты по всем индексам Решение Без этого сценарий считается «описанием», а не моделью. 6.10. Операторская ошибка Моделируется изменение веса w_i на +0.10 без записи. DI = sum abs(P_current - P_base) Если DI >= 0.05 — аудит. Если DI >= 0.10 — пересборка. 6.11. Интегральный стресс-день Сценарий включает: экономический шок медиашум персональный кейс портфельный перегруз ошибка подтверждения Процедура: пересчёт индивидуальных объектов пересчёт портфеля расчёт OLI проверка CI ограничение SLC акт стабилизации 6.12. Регламент персонального кризиса Фаза I — сигнал Фаза II — рост медиаволатильности Фаза III — каскад Фаза IV — стабилизация На каждой фазе рассчитываются SSI, PRS, CAI, Narrative density. 6.13. Полный каталог актов Стресс-акт Акт мультизоны Акт медиашума Акт деградации данных Акт портфельного сдерживания Акт операторской ошибки Акт интегрального кризиса Акт стабилизации Каждый акт содержит: исходные данные; расчёты; режим; ограничения; подписи. 6.14. Тест воспроизводимости Любой сценарий должен быть повторяем с теми же входными данными. Проверка: входные x_i веса w_i окно версия выходные SSI, PRS, CAI Если расчёт не повторяется — дефект. ТОМ VII ФИЛОСОФСКИЙ ФУНДАМЕНТ PSSR v10.1 7.0 Статус Тома VII Настоящий том определяет: онтологию системы, эпистемологию знания, нормативные основания допустимости, границы применимости, философское обоснование детерминизма, философское обоснование режима, философское обоснование Human-in-the-Loop. Том VII не описывает процедуры. Он определяет, почему процедуры вообще имеют смысл. 7.1 Онтология PSSR 7.1.1 Реальность как система напряжений Реальность в PSSR определяется как: Динамическое поле взаимодействующих напряжений между ресурсами, ожиданиями, институциональными правилами и скоростью изменений. События вторичны. Первичны — напряжения. Напряжение существует даже при отсутствии видимого кризиса. 7.1.2 Граница системы Любая система имеет: внутренний контур, внешний контур, проницаемую границу. Устойчивость определяется не только внутренними параметрами, но и характером границы. Пример (без политики): Экономика с высокой экспортной зависимостью имеет тонкую внешнюю границу. Цифровая инфраструктура с внешними каналами — проницаема. PSSR моделирует систему как ограниченный объект, но учитывает воздействие внешнего поля через факторы. 7.1.3 Режим как онтологическая единица Режим — не административная метка. Режим — это: Структурное состояние распределения напряжений в системе. Normal — равномерное распределение. Heightened — локальная концентрация. Stress — ускорение нелинейности. Severe — каскадное перераспределение. Режим существует объективно, даже если субъект его не признаёт. 7.1.4 Нелинейность как фундаментальный закон Любая социальная система обладает: порогами, фазовыми переходами, точками ускорения. Линейная интерпретация всегда неполна. NL — философски обоснованный механизм фиксации фазового перехода. 7.1.5 Ускорение как индикатор угрозы Не масштаб напряжения опасен. Опасна скорость изменения напряжения. Accel_PRS отражает онтологический принцип: Быстро меняющаяся система опаснее большой, но стабильной. 7.1.6 Хрупкость как скрытое состояние Хрупкость — это: Состояние высокой чувствительности к малому числу факторов. Система может выглядеть стабильной и быть хрупкой. PSSR фиксирует не только уровень, но и концентрацию уязвимости. 7.1.7 Институциональное время Календарное время ≠ системное время. Системное время определяется фазами: накопление, ускорение, разрыв, стабилизация. 7.2 Эпистемология PSSR 7.2.1 Разделение уровней знания Система различает: Наблюдаемое (observable) Латентное (latent) Модельное Прогнозное Observable — измеряется. Latent — выводится через структуру. Модель — формализует. Прогноз — условный. 7.2.2 Ограниченность наблюдения Не всё измеримо. Некоторые напряжения: искажаются, подавляются, стратегически маскируются. Поэтому вводится Confidence(t). Confidence — не качество модели. Confidence — качество наблюдаемости среды. 7.2.3 Детерминизм как условие воспроизводимости Модель обязана быть воспроизводимой. Вероятность может меняться. Формула — нет. Детерминизм — это: Философский запрет на произвольность. 7.2.4 Вероятность ≠ предсказание PRS — это вероятность режима. Это не предсказание события. Модель не обязана быть правой. Она обязана быть: прозрачной, воспроизводимой, проверяемой. 7.2.5 Drift как философская угроза Drift — это: Незаметное смещение системы от собственных оснований. Drift опаснее ошибки. Ошибка — разовая. Drift — системный. Поэтому контроль Drift — не технический, а философский долг системы. 7.3 Нормативные основания 7.3.1 Принцип правового приоритета Модель не может быть выше закона. Если расчёт противоречит правовой рамке — интерпретация ограничивается. 7.3.2 Принцип минимального вмешательства Система не рекомендует больше, чем необходимо. Она снижает амбицию при низком Confidence. 7.3.3 Принцип обратимости Любое управленческое решение должно быть обратимым до достижения каскадной фазы. 7.3.4 Принцип анти-паники Режим Stress не означает катастрофу. Он означает ускорение. Интерпретация не должна усиливать каскад. 7.3.5 Принцип системной скромности Модель не описывает реальность полностью. Она описывает её структурную динамику. 7.3.6 Принцип симметрии риска Черные лебеди редки. Серые носороги медленны. Система обязана видеть оба. 7.4 Роль Human-in-the-Loop Человек необходим, потому что: Модель фиксирует структуру. Человек несёт ответственность. HITL — не слабость. Это философская гарантия легитимности. 7.5 Связь с архитектурой v10 NL — отражает фазовые переходы. Cascade — отражает структурное перераспределение. OLI — отражает предел внимания. Drift — отражает угрозу целостности. SLC — отражает дисциплину интерпретации. Ни один индекс не является случайным. Каждый имеет онтологическое основание. 7.6 Формула философии PSSR Устойчивость = способность системы перераспределять напряжение без ускорения каскада в условиях ограниченного знания. 7.7 Заключение PSSR v10.1 основана на: реальности нелинейности, ограниченности знания, дисциплине интерпретации, правовом приоритете, анти-дрифтовой защите, институциональной памяти. Принял. Ты прав: это был архитектурный скелет, а не «том» уровня v10.x. Я сейчас сам проверяю полноту по критериям, которые ты уже задал для системы (детерминизм, L0/L1, Drift, HITL, мануфактурность, “кварц vs хронометр”, CS-Class), и переписываю Том VIII заново так, чтобы он был: не про “в общих чертах”, а про точные уровни, контракты, форматы, интерфейсы, запреты, тесты, режимы отказа; пригоден как ТЗ для разработки (MVP и дальше); и одновременно не нарушал твою философию: ядро — механика, AI — только полировка/витрина. ТОМ VIII (v10.1) ПРОГРАММНАЯ АРХИТЕКТУРА И ПРОТОКОЛЫ РЕАЛИЗАЦИИ Цель: зафиксировать инженерную архитектуру PSSR так, чтобы ядро оставалось механическим, детерминированным и воспроизводимым, а все уровни (данные → ядро → governance → продукты) имели жёсткие контракты, исключающие обходы, дрейф и стохастику. 0) Определения и инварианты реализации (Implementation Invariants) 0.1. Модель слоёв: «односторонний ход механизма» PSSR реализуется как цепочка неизменяемых слоёв: L-DATA → L-NORM → L-CORE → L-GATE → L-PRODUCT → L-DELIVERY Правило: слой справа не имеет права модифицировать слой слева. Любая попытка = инцидент класса I2 (см. раздел 10). 0.2. Две сущности: «Механизм» и «Витрина» Механизм = L-CORE + L-GATE (математика + правовые/процедурные предохранители). Витрина = L-PRODUCT + L-DELIVERY (дашборды, отчёты, упаковка, визуализация). AI допускается только в витрине и только на данных, прошедших L-GATE. 0.3. Жёсткий запрет «AI-in-Core» AI никогда: не влияет на расчёты индексов; не меняет режим; не подменяет Confidence; не изменяет входные данные; не меняет нормировку; не может “догадаться” параметры ядра. 1) Уровни архитектуры (Levels) и их контракты 1.1. L-DATA — Data Ingestion Layer (приём данных) Функция: собрать сырые сигналы и метаданные без интерпретации. Входы: структурные ряды (макро/рынки/операционные метрики), событийные ленты, ручные вводы ассистентов (строго в форме “факт/наблюдение”, без выводов), внешние файлы. Выход: RawSnapshot (не нормированный). Запреты: запрещено вычислять индексы; запрещено выдавать режим; запрещено “исправлять” данные без записи в журнале; запрещено смешивать периоды без фиксации таймлайна. Обязательные метаданные источника: source_id source_type (official / market / media / internal / manual) retrieved_at (UTC) coverage_window (t0..t1) reliability_tag (A/B/C/D) license_tag (ok / restricted / unknown) integrity_hash (см. 6.2) 1.2. L-NORM — Normalization Layer (нормировка) Функция: преобразовать сырые данные в нормированные факторы x_i ∈ [0;1] строго по “схеме нормировки”. Выход: NormSnapshot. Контракт нормировки: Нормировка определяется схемой NORM_SCHEMA_ID. Схема = набор функций f_i(raw, context) → x_i + параметры. Любая схема имеет версию и хэш. Запреты: запрещено менять схему без Formal Reset (если затрагивает ядро) или без Change Request (если “неядровая” статистика); запрещено подгонять нормировку “под результат”. Деталь (важно для детерминизма): Все операции округления фиксируются (пример: round_half_even, точность 1e-6). Все значения NaN/None обрабатываются по единому протоколу MissingDataPolicy. 1.3. L-CORE — Core Engine (механическое ядро) Функция: вычислить индексы, режим, динамику и портфельные величины. Вход: NormSnapshot + CoreParams + ReleaseManifest. Выход: CoreResult. Гарантии: детерминизм (одинаковый вход → одинаковый выход), воспроизводимость (replay), трассируемость (explainability trace), неизменность параметров в PROD. Запреты: любые случайности, внешние API вызовы, чтение “текущего времени” для расчёта, скрытые автокоррекции “по месту”. 1.4. L-GATE — Governance Gate (предохранитель) Функция: не выпустить продукт, если нарушены: закон/процедуры (L0), CS-Class, SLC предел, Confidence пороги, режимные протоколы, Drift/Version конфликт, OLI перегрузка. Выход: ApprovedPayload или BlockedPayload. Главное правило: L-GATE — неизбежен. Нельзя “выключить”. 1.5. L-PRODUCT — Product & Narrative Layer (упаковка) Функция: сформировать отчёты/дашборды/ноты строго по шаблонам. Вход: только ApprovedPayload. Выход: ProductPack. Гарантии: разделение Fact/Model/Scenario, SLC-ограничение, отсутствие политической конкретики (если задан профиль), маркировка уверенности. 1.6. L-DELIVERY — Delivery Layer (выдача) Функция: доставка и хранение артефактов (PDF, DOCX, dashboard view, email package). Требования: контроль доступа, водяные знаки/маркировка, журнал выдач, возможность “отозвать доступ” (не удаляя логов). 2) Release Manifest: главный «паспорт механизма» 2.1. Что такое ReleaseManifest ReleaseManifest — это единый объект, который фиксирует: точную версию ядра, схему нормировки, параметры, версии gate-правил, версии шаблонов продукта, допустимые режимы, политику округления и missing data. Формат (концептуально JSON/YAML): release_id core_id + core_hash norm_schema_id + norm_hash gate_policy_id + hash product_template_id + hash rounding_policy_id missing_data_policy_id time_basis (как считаем t) allowed_outputs (какие продукты разрешены) security_profile (RBAC) cs_profile (CS-Class профиль) 2.2. Запрет “неявных” релизов Нельзя запускать расчёт без ReleaseManifest. Попытка = I2. 3) Контракты данных: точные форматы объектов 3.1. RawSnapshot (L-DATA output) Обязательные поля: snapshot_id object_id retrieved_at coverage_window records[] (каждая запись имеет value, unit, timestamp, source_id) source_meta[] integrity_hash 3.2. NormSnapshot (L-NORM output) norm_snapshot_id snapshot_id (ссылка на Raw) norm_schema_id x[] (массив факторов: {factor_id, x_value, confidence_component, missing_flag}) norm_trace[] (минимальный trace: какая функция, какие параметры, какой raw-range) norm_hash 3.3. CoreResult (L-CORE output) core_run_id release_id object_id t_index (что есть “t”) indices (SSI, NL, PRS, Delta, Accel, Cascade, FDS, LVF, CAI, OLI, CI, …) regime (Normal/Heightened/Stress/Severe) confidence (общий + разложение) explain_trace (вклад факторов) core_hash (см. 6.3) 3.4. ApprovedPayload / BlockedPayload (L-GATE output) ApprovedPayload: core_result_ref allowed_products[] SLC_cap CS_Class L_level (L0/L1/L2) required_disclaimers[] redactions[] (что обязано быть скрыто) audit_ref BlockedPayload: blocked_reason[] (код+текст) required_action (HITL / data_fix / legal_review / drift_reset) audit_ref 4) Детерминизм: технические условия и тесты 4.1. Determinism Definition Determinism Contract: При фиксированных: NormSnapshot.norm_hash ReleaseManifest.release_id CoreParams (внутри релиза) CoreEngine.core_hash результат CoreResult.core_hash обязан совпасть. 4.2. Что ломает детерминизм (и запрещено) плавающие округления, локальные часовые пояса без фиксации, чтение “сегодняшней даты” в формуле, авто-импутация без протокола, порядок обработки массивов без сортировки, параллельные вычисления без фиксированного порядка редукции. 4.3. Determinism Test Suite (обязательная) Replay Test запуск CoreEngine 10 раз на одном снапшоте → 10 одинаковых хэшей. Cross-Machine Test одинаковый снапшот на двух окружениях (prod-like) → одинаковый хэш. Version Lock Test подмена версии ядра при том же релизе → должно блокироваться gate-правилом “ManifestMismatch”. 5) Explainability Trace: «открытая задняя крышка» 5.1. Требование Каждый индекс обязан иметь: список факторов-вкладчиков, знак вклада (+/-), чувствительность (локальная производная/дельта-оценка), ссылку на norm_trace. 5.2. Минимальный формат explain_trace = [{index_id, factor_id, contribution, sensitivity, note}] 5.3. Запрет “нарративной магии” Product Layer не имеет права добавлять причинность, не отражённую в trace. Если нужно — только как гипотеза с SLC-маркером. 6) Hashing, Audit, Tamper Evidence 6.1. Зачем PSSR как “хронометр”, а не “кварц”: мы обязаны доказать, что: входные данные не поменялись, формулы не поменялись, результат воспроизводим. 6.2. Integrity Hash RawSnapshot Хэшируется: отсортированные записи, source_meta, coverage_window, retrieved_at. 6.3. Core Hash Хэшируется: norm_hash, release_id, core_engine_hash, core_params_hash, indices, regime, confidence, explain_trace. 6.4. Audit Log (цепочка) Каждая запись: entry_id timestamp actor_id action_type payload_hash prev_hash curr_hash Правило: нельзя переписать историю. Можно только добавить запись. 7) Governance Gate: точные протоколы выпуска (не каркас) 7.1. Gate Checklist (обязательный порядок) Порядок фиксирован (важно для воспроизводимости решений): ManifestCheck (версия/хэши совпадают) DriftCheck (DI в норме либо Formal Reset выполнен) L_Check (L0/L1/L2) CS_ClassCheck ConfidenceCheck SLC_Cap OLI_Check RegimeProtocolCheck OutputPolicy (какие продукты разрешены) Если любой шаг FAIL → BlockedPayload. 7.2. L0/L1/L2: техническая трактовка L0: запрещено выпускать продукт. Разрешён только “технический блок” + рекомендация законной альтернативы. L1: выпуск возможен только в фактическом режиме, с повышенными дисклеймерами, с урезанным SLC. L2: выпуск нормальный, но с маркировкой чувствительности. (Без политической конкретики — но механизм обязан это уметь для любых чувствительных тем.) 7.3. CS-Class CS-Class — это профиль критичности объекта/клиента: CS-0 (обычный) CS-1 (повышенная осторожность) CS-2 (критический контур) CS-2 добавляет: повышенный порог Confidence, обязательный HITL, запрет на любые интерпретации при SLC>0 без подписи Owner. 7.4. SLC Caps: как работает «ограничитель амбиций» SLC — не пожелание автора, а числовое ограничение на типы выводов. Пример правил (принципиально): SLC=0: только факты/значения индексов/условные фразы. SLC=1: осторожные гипотезы “при условии”. SLC=2: сценарные развилки без директив. SLC=3: управленческие рекомендации (разрешено только при высоком Confidence и не-CS2). Gate выставляет SLC_cap, а Product Layer не может его превысить. 7.5. Confidence Check Gate должен сравнивать Confidence: общий по источникам по ключевым факторам Если Confidence ниже порога — либо блок, либо автоматический downgrade продукта (например, только “monitoring note”). 8) Program Architecture: сервисы и интерфейсы (как реально строить) 8.1. Рекомендуемая структура модулей (логическая) data_service norm_service core_service gate_service product_service audit_service drift_service portfolio_service 8.2. Главное инженерное правило core_service не зависит от: product_service, ai_service, внешнего интернета, UI. 8.3. API-контракты (минимум) POST /snapshot/raw → RawSnapshotID POST /snapshot/norm → NormSnapshotID POST /core/run → CoreRunID POST /gate/evaluate → ApprovedPayload/BlockedPayload POST /product/generate → ProductPackID GET /replay/{core_run_id} → CoreResult (same hash) GET /audit/{ref} → Audit chain (Это не “веб-апи обязательно”, это контракт взаимодействия модулей.) 9) Роли доступа (RBAC) и “мастерская мануфактуры” 9.1. Роли Owner (Ты): утверждает режимы Stress/Severe, подписывает overrides. Analyst: может запускать сбор/нормировку, готовить продукт, но не менять ядро. Assistant: может вводить факты, но не менять схемы. Auditor: только чтение логов/реплея. ClientViewer: видит только витрину (без параметров). 9.2. Секреты ядра (IP Protection) Клиенту запрещено показывать: веса, пороги, схемы нормировки, формулы, полные explain traces (если это раскрывает IP). Разрешено показывать: результат, ограниченный “top drivers” без раскрытия весов, Confidence, дисклеймеры. 10) Incident Engine: классы отказов и реакции 10.1. Классы инцидентов I0: косметика (ошибка форматирования отчёта) I1: продуктовая ошибка (не тот шаблон / не тот язык) I2: архитектурное нарушение (обход gate, mismatch manifest, недетерминизм) I3: системная компрометация (tamper evidence) 10.2. Автоматические реакции I2 → мгновенная блокировка выпуска + алерт Owner I3 → freeze релиза + аудит 11) Drift Engine: что именно считается дрейфом в софте 11.1. Типы дрейфа DI_core: изменение формул/параметров ядра DI_norm: изменение нормировки DI_data: изменение источников/качества (reliability) DI_gate: изменение политик L/CS/SLC DI_product: изменения шаблонов (не влияющие на ядро, но влияющие на смысл) 11.2. Formal Reset vs Change Request Formal Reset обязателен при DI_core или DI_norm выше порога. Change Request допускается для product-шаблонов, если не меняет смысловой режим. 12) Примеры из КЗ/ЦА без политической конкретики (чтобы том был “живой”) Пример 1: “Валютно-сырьевой шок” Data Layer: фиксирует скачок волатильности + ценовой импульс. Norm Layer: приводит к росту факторов кластера “E/C”. Core: SSI↑, NL может активироваться, PRS↑, Accel_PRS↑. Gate: если Confidence высокий — разрешит Crisis Alert; если низкий — downgrade до Monitoring Note. Product: выдаёт “факт/модель/сценарий”, без директив. Пример 2: “Медиа-турбулентность + репутационный шум” Data: рост медийных сигналов (не интерпретируя причин). Norm: LVF/FDS компоненты. Core: CAI может расти через связность. Gate: при CS-2 и SLC=0 оставляет только численные индикаторы и предупреждение о неопределённости.