[drive-download] 10.docx

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

10.1 ВЕРДИКТ VERDICT: FAIL Причины (привязка к ID уязвимостей): Ложная теорема о диапазоне S_raw∈ при F_syn>1 (Range Guarantee) — доказательство в разделе “Property 2: Range Guarantee” противоречит собственной SSOT-формуле и числам (S_raw>1 уже при T=0.85, C=V=1, ε=0.35). Это системный математический дефект [V02, V05].ppl-ai-file-upload.s3.amazonaws Ложная теорема “No plateau until maximum” — уже при T_comp≈0.85 индекс уходит в клип 150 и остаётся на плато до T=1, при этом в разделе “Property 3: No Plateau Until Maximum” утверждается обратное [V03]. Sanity checks не воспроизводимы SSOT-кодом — строка “Trust Threshold” заявляет 123.5, тогда как каноническая функция compute_index_v4 с F_syn=1+εCT даёт ~160→150 (клип). Внутренний текст сам признаёт расхождение, но таблица помечена как “Auto-Generated” и “✓” [V01]. Sanity check “High Volatility” (σ=20) также не совпадает с SSOT — таблица ожидает 50.0, а по коду получается 67.5 при C=V=T=Z=1, σ=20 [V04]. “Non-Compensatory” нарушено синергией — разделы 1–3 жёстко декларируют “low trust ≠ high capacity rescue”, но формула F_syn=1+εCT и min-агрегация дают численные сценарии, где рост C существенно поднимает KPI при низком T, т.е. частичная компенсация доверия мощностью присутствует [V06]. Gate-константы g0, g1 численно противоречат определению g(x)=1/(1+e^{−x}) — текст повторно использует приближения из v3 (0.1544/0.5744), которые не соответствуют g(kθ), g(−k(1−θ)) при k=2, θ=0.85; в Python-коде используются другие значения (0.8456/0.4256) [V07]. Доказательство монотонности игнорирует клиппинг и сжатие на плато 150, вследствие чего утверждение о строго возрастающем S_KPI по T нарушается на участке T∈[~0.85,1) (формально ∂S_KPI/∂T=0 там из‑за клипа) [V08]. Калибровка ε и μ описана как “grid search” и “Basel III prior”, но без датасета, MAE-таблиц, train/test split и допусков — это несоответствие заявленному “Complete Mathematical Design” и требованиям аудита [V13, V14]. В SSOT-коде есть backdoor для ручного override параметров через **params без аудиторского следа, что ломает идею единственного канонического конфига (SSOT) [V17]. Ключевые управленческие зоны 0–150 и кризисные пороги (Section 15) семантически конфликтуют с тем, что “All Optimal” и даже “Trust Threshold” уже насыщают шкалу 150, превращая верхний диапазон “overheat” в норму [V09, V10]. В совокупности это даёт математически несостоятельную и управленчески токсичную модель в текущем виде. Без жёсткого P0‑ремонта документ нельзя выносить на Steering Committee как “готов к реализации”. 10.2 ТОП-20 УБИЙСТВЕННЫХ УЯЗВИМОСТЕЙ Таблица (ID, Severity, Category, Цитата → Механизм → Атака → Патч → Тест) (Оставшиеся ≥25 уязвимостей будут перечислены в полном списке ниже.) 10.3 ПОЛНЫЙ СПИСОК УЯЗВИМОСТЕЙ (≥45) Ниже — компактный перечень с категоризацией (каждая строка: ID, категория, цитата → механизм → патч → тест). A. Math / SSOT / Proofs (≥14) V01–V05, V07–V08, V11–V12 — уже описаны в ТОП‑20. V21 (Math / Gate sign history) — цитата: g(x) = 1/(1+e^{-x}) + старые численные значения g_0≈0.1544, g_1≈0.5744 [Sec.4]. Механизм: смесь старой и новой сигнум-конвенции создаёт двусмысленность при реализации gate в других языках (R, SQL). Патч: отдельный бокс “Sign convention changed vs v3” с явной формулой. Тест: сравнить реализацию в Python/R/SQL на ключевых T (0, θ, 1). V22 (Math / Domain of C,V,T,Z) — допускаются точные нули без ε‑клиппинга [Sec.4], но в proof моновариантов используются производные C^{w_C−1}, T^{w_T−1}, которые при C=0 формально →∞. Механизм: proof некорректен на границе. Патч: ограничить proof внутренним интервалом (0,1] либо ввести техническую ε‑нижнюю границу для анализа. Тест: символьная проверка производных и численная проверка вблизи 0. V23 (Math / Fixed-points proof) — в разделе C: Convergence & Fixed Points говорится, что система “non-chaotic” и “asymptotically stable” потому что ∂S_KPI/∂σ_hist<1 [App.C]. Механизм: σ_hist сама функция прошлых S_t; proof односторонней производной недостаточен, фактически это feedback‑система. Патч: переписать как эвристическую оценку, не как theorem. Тест: симуляции с искусственно зашумлёнными S_t, проверка отсутствия дивергенции. V24 (Math / Alternative 2 rejected reasoning) — в обсуждении “Alternative 2: Multiplicative (All Factors, REJECTED)” утверждается, что “No synergy (already baked into multiplication)” [Sec.5]. Механизм: некорректное заявление — multiplicative формула тоже даёт синергию, просто другого вида; это подрывает доверие к аргументации выбора v4. Патч: заменить на корректный аргумент (“слишком агрессивное подавление”). Тест: показать пример, где чисто мультипликативная форма даёт чрезмерное падение. V25 (Math / Sensitivity table inconsistency) — в Sec.16 приводится “±10% change” по параметрам с итоговым “±MAE” (45pp,50pp,2.5pp и т.п.), но не указано, к чему это “pp”: к MAE или S_KPI. Механизм: неоднозначные единицы нарушают SsOT. Патч: уточнить столбец (например “ΔS_KPI at All Optimal”). Тест: пересчитать эти числа и зашить в unit‑tests. B. Data / Observability (≥9) V18 (Z models) — описано выше. V26 (Data / C measurement) — C берётся из “Ministry reports, audit against payroll” [Sec.13], но нет конкретной формулы (FTE? бюджет? доля обученных?). Механизм: два министерства могут считать C по-разному. Патч: добавить формальный индекс C=0.4·FTE_norm+0.3·budget_util+0.3·coverage. Тест: сверка C из двух независимых реализаций. V27 (Data / T_synthetic details) — Sec.14 задаёт 4-уровневый fallback, но без указания, как именно объединяется survey и synthetic (например, скользящая средняя vs Bayesian update). Механизм: два разных подрядчика дадут разные T_loyalty. Патч: формулы взвешивания T_synthetic с T_survey. Тест: прогнать pipeline на одной и той же истории с двумя реализациями и убедиться, что отличия < допустимого. V28 (Data / σ_hist uses S_KPI vs S_resilience) — в Sec.11 Step 4 volatility audit считает σ_hist по “S_KPI” [Sec.11], но F_vol в compute_index_v4 может использовать либо официальную, либо тех‑шкалу; это не явно закреплено. Механизм: смена выбора (S_resilience vs S_KPI) меняет σ_hist, но документ не фиксирует одну версию. Патч: указать однозначно, что σ_hist считается по официальному S_KPI до клипа или по resilience. Тест: проверить σ_hist по обоим вариантам и зашерстить расхождение. V29 (Data / Missing data for V) — “V from Mediascope/Similarweb, weekly” [Sec.13], но нет политики при отсутствии данных (например, для регионов без медиа‑панели). Механизм: V может быть искусственно завышен LOCF, без флага. Патч: добавить fallback (proxy по другим источникам) с обязательным флагом качества. Тест: симулировать отсутствие панельных данных и проверять, что это отражено в метаданных. V30 (Data / Extreme σ_hist case) — Sec.14 допускает σ>50 и предлагает F_vol(50)=0.17, но не описывает, какие наблюдаемые паттерны в данных будут считаться “ошибочными”, а какие “реальными” [Sec.14]. Механизм: любое extreme value можно объявить “ошибкой” и выкинуть. Патч: детальный критерий для data‑quality checks при σ>50. Тест: на тестовом датасете задать сценарий σ≈60 и прогнать quality‑rules. V31 (Data / Time alignment) — шаги pipeline (сбор в 09:00, валидация 10:00, вычисление 11:00) [Sec.13] не описывают, какие временные зоны используются и как агрегируются события, пришедшие “между отчётами”. Механизм: нет чёткого определения периода наблюдения. Патч: ввести “reference week window” (понедельник–воскресенье UTC+5). Тест: проверить корректность агрегации cross‑TZ данных. C. Validation / Calibration / Causal (≥8) V13, V14, V19 — уже описаны. V32 (Validation / Cross-validation protocol) — упоминается “Cross-validation (2020-2022 train, 2023-2024 test)” без деталей разбиения (rolling vs random) [Sec.7]. Механизм: можно выбрать удобный split (window shopping) и получить “лучший” ε. Патч: формально зафиксировать CV схему (например, time-series CV с k‑fold). Тест: автоматическое построение CV folds и проверка неизменности split между релизами. V33 (Validation / No benchmark vs naive) — v4 не сравнивается с simple baseline (S_t+1=S_t). Механизм: v4 может быть сложнее и хуже, чем baseline. Патч: обязательная таблица MAE для baseline. Тест: assert MAE_v4 < MAE_naive - δ. V34 (Validation / EWS integration) — хотя v4 — индекс, а EWS отдельно (в v3 docs), здесь нет описания, как EWS будет переобучаться на новом KPI (classes, labels). Механизм: витринные показатели могут стать несогласованными с ML‑моделью. Патч: добавить раздел “EWS retraining plan for v4”. Тест: unit‑тест на формирование labels y∈{0,0.5,1,2} из нового S_KPI. D. Ops / MLOps / Reproducibility (≥7) V15, V17 — уже описаны. V35 (Ops / CI scope) — в checklist перечислено “Unit tests 50+ (all pass)” [Sec.17], но не сказано, что среди них есть property‑tests (монотонность, диапазоны), только классические asserts. Механизм: можно покрыть код синтаксическими тестами, но не поймать логические нарушения свойств. Патч: добавить обязательный раздел “Property Tests” в CI. Тест: сам факт наличия и прохождения property‑suite. V36 (Ops / Library versioning) — код использует scipy.special.expit [Sec.8,12], но нет фиксации версий scipy/numpy. Механизм: при обновлении библиотеки поведение граничных значений может чуть измениться (float отличия), ломая воспроизводимость аудиторских проверок до 0.5pp. Патч: pin library versions в requirements.txt и включить их в audit. Тест: проверка того, что pip freeze совпадает с эталонным списком. V37 (Ops / Parallel metrics) — compute_parallel_metrics реализован в конце [Sec.12] отдельно от main SSOT, с дублированием формул для S_pot, F_gate, F_vol. Механизм: 2 реализации одной и той же логики легко разойдутся. Патч: вынести общие блоки в одну функцию. Тест: строго сравнивать S_resilience, вычисленный через shared‑блоки и через основную функцию. E. Adversarial / Gaming / Governance (≥7 + 12 атак) V15, V20 — уже описаны. V38 (Gaming / C via reclassification) — способность “уговорить” ведомства переклассифицировать административный персонал как “оперативный информационный ресурс” поднимает C без реального роста ответной способности. Патч: жёсткие правила классификации FTE. Тест: аудит случайной выборки персонала. V39 (Gaming / V via bots) — использование купленного трафика/ботов увеличит измеряемую видимость по Similarweb/Mediascope без реального охвата. Патч: фильтрация по качеству трафика, доля direct/organic. Тест: сравнение с независимыми источниками и флагование резких скачков без контента. V40 (Gaming / T via survey design) — документ не описывает контроль wording и выборку опросов для T_loyalty [Sec.13/14]. Лёгкая смена формулировки вопроса повышает T без реального изменения доверия. Патч: стандартизованный questionnaire и внешний аудит. Тест: split‑sample test разных формулировок. V41 (Gaming / Z via model choice) — смена одной из трёх моделей на “более оптимистичную” (меньше видит дезу) поднимает Z, увеличивая T_comp. Патч: зафиксированный ensemble с регулярным внешним аудитом. Тест: мониторинг дрейфа Z при смене моделей. V42 (Gaming / σ via smoothing) — кроме удаления экстремальных недель (V20), можно искусственно “декларировать” изменение окна σ с 24 до 52 недель, тем самым сгладив волатильность. Патч: жёстко закрепить окно в параметр-регистре и запретить его менять без SC‑решения. Тест: автоматический аудит того, что σ_window совпадает с registry. V43 (Goodhart / thresholds) — жёсткие пороги Level 0/1/2/3 мотивируют ведомства “держать” S_KPI ровно чуть выше 80, минимизируя реальное улучшение. Патч: использовать непрерывные KPI и rolling‑average оценки вместо жёстких порогов. Тест: анализ распределения S_KPI (скопление около порогов=признак goodhart). 6) АНТИ-ГЕЙМИНГ: 12 КОНКРЕТНЫХ АТАК Каждая в формате: уязвимость → как атакуют → сигнал → детекция → контрмера. C‑inflation через “бумажную ёмкость” (V15, V38) Атака: массовая переквалификация административных сотрудников в “инфо‑специалистов” на бумаге, рост C от 0.5 до 0.9 без реального прироста эффективных действий. Сигнал: скачок C без соответствующего роста фактических вмешательств/контента. Детекция: корреляция C vs фактическое число response‑events; если C↑, а events const — красный флаг. Контрмера: аудит FTE по должностным инструкциям + KPI на фактические действия, а не на голову. C‑inflation через “пустые структуры” Атака: создание новых отделов/центров, которые формально увеличивают C (структурная ёмкость), но не staffed/operational. Сигнал: рост числа подразделений при прежнем бюджете и FTE. Детекция: ratio “staffed/declared units” и “budget per unit” со временем. Контрмера: ввод “operational capacity” (реально функционирующие единицы) вместо голой структуры. V‑boost через закупку ботов/трафика (V39) Атака: закупка дешёвого бот‑трафика в соцсетях для искусственного роста метрик видимости. Сигнал: резкий рост трафика из стран/регионов вне целевой аудитории, рост direct/referral без контента. Детекция: аномальный паттерн geo/device, высокий bounce rate, низкое вовлечение. Контрмера: использовать качество‑взвешенный V (органический трафик, вовлечение) и blacklist источников бот‑трафика. T‑boost через манипуляцию выборкой опроса (V40) Атака: смещение выборки в сторону лояльных групп (например, госслужащие, пенсионеры), чтобы поднять T_loyalty. Сигнал: изменение демографического профиля выборки без внешних причин. Детекция: регулярный аудит выборки независимым исследовательским центром. Контрмера: обязательная стратифицированная выборка и публикация её параметров. T‑boost через seasonality (выбор даты опроса) Атака: проведение опросов в моменты “позитивных новостей” (перед увеличением цен/налогов), когда доверие выше. Сигнал: систематическое смещение дат опросов к “хорошим” событиям. Детекция: анализ календаря событий vs даты опросов. Контрмера: фиксированное расписание опросов (квартальные окна, не привязанные к инфоповодам). Z‑gaming через выбор NLP‑моделей (V41) Атака: смена модели sentiment / misinfo на менее чувствительную, чтобы занизить оценку дезы и завысить Z. Сигнал: резкое улучшение Z при неизменной реальной информационной обстановке. Детекция: параллельный расчёт Z старой и новой моделью в течение 3–6 месяцев и сравнение трендов. Контрмера: SC‑одобрение смены моделей + временная “двойная запись” обеих версий. σ‑gaming через удаление пиковой недели (V20) Атака: объявление одной плохой недели “ошибкой сбора” и её выключение из σ_hist, что сильно снижает волатильность. Сигнал: несостыковка между публичной историей S_KPI и тем, что пошло в σ_hist. Детекция: хранение raw S_KPI и отдельного sigma_hist_raw. Контрмера: любая ручная правка истории требует отдельного verdict‑файла SC. σ‑gaming через смену окна 24→52 недели (V42) Атака: растягивание окна волатильности, чтобы сгладить несколько плохих недель. Сигнал: оперативное изменение параметра σ_window без обсуждения. Детекция: аудит registry vs реального значения σ_window в коде. Контрмера: запрет менять σ_window без формального решения SC и логирования. S_KPI‑gaming через Index Shopping (S_KPI vs S_resilience) (Sec.10) Атака: для внешней коммуникации использовать S_KPI (с синергией), а для внутренних решений — то значение, которое “красивее”, фактически cherry-picking. Сигнал: несоответствие между значениями в отчётах и в технических логах. Детекция: обязательное параллельное логирование S_KPI и S_resilience и их соотношение. Контрмера: однозначно зафиксировать, какой индекс используется для чего (управление vs PR). Threshold‑gaming около Level1=80 Атака: удерживание S_KPI аккурат чуть выше 80 путём временных мер (кампании, одноразовые выплаты) без системных изменений, чтобы не перейти в Level2. Сигнал: скопление значений в диапазоне 80–82. Детекция: анализ распределения, всплески активности “точечно перед отчётами”. Контрмера: использовать сглаженные показатели (rolling medians) и усиливать вес долгосрочных трендов. “Devil’s Implementer”: скрытый override параметров в BI/SQL (V15) Атака: в BI‑слое реализовать собственный расчёт индекса с чуть изменённым ε или μ, при этом ссылка идти на “официальный” документ. Сигнал: отличие значений на dashboard vs эталонный Python‑скрипт. Детекция: регулярный cross‑tool сравнение (Python vs SQL/BI). Контрмера: централизованный microservice‐endpoint для расчёта индекса, запрет пересчёта “локально” в BI. “Zero‑gaming”: сознательное удержание C,V,T на низком уровне, чтобы не входить в зону high‑alert Атака: снижать интенсивность коммуникаций (V) и видимость C, чтобы индекс не фиксировал резких падений. Сигнал: падение V/C и σ_hist одновременно, при этом субъективно события происходят. Детекция: внешние независимые метрики (медиа‑упоминания, международные рейтинги). Контрмера: ввод внешних бенчмарков (международные индексы) как контрольных переменных. 10.4 “АТАКА НА СОВЕЩАНИИ” — 15 УДАРОВ Каждый удар ссылается на ID. “Ваш ‘Trust Threshold’ sanity обещает 123.5, но SSOT-функция даёт 150 — установка synergies ломает таблицу. Что считать истиной: документ или код?” (V01) “В теореме range вы утверждаете S_raw∈, хотя сами считаете S_raw>1 уже при T=0.85. Это ложное доказательство.” (V02)ppl-ai-file-upload.s3.amazonaws “Вы пишете ‘No plateau until maximum’, но при T=0.85 индекс уже 150 и дальше не растёт — явное плато задолго до идеала.” (V03) “Sanity ‘High Volatility’ ожидает 50, но SSOT с ε=0.35 даёт 67.5. Почему аудитор должен верить другим числам таблицы?” (V04) “Вы декларируете ‘non-compensatory’, но формула содержит множитель (1+εCT). Рост C при низком T всё равно поднимает индекс. Это и есть компенсация.” (V06) “Gate-константы g0, g1 в тексте (0.154,0.574) не совпадают с g(kθ), g(−k(1−θ)) для g(x)=1/(1+e^{−x}). Какой логит вы реально используете?” (V07) “Монотонность доказывается для S_raw, а не для S_KPI. В реальности из-за клиппа при 150 S_KPI перестаёт расти ещё до T=1 — вы это скрываете.” (V08) “Если 150 — это зона ‘excellent-overheat’, почему All Optimal и даже T=0.85 уже saturate на 150? Чем отличается норма от перегрева?” (V09) “Вы ссылаетесь на Basel III для μ, но не показываете ни одной формулы или оценки из данных. Это rhetorical prior, не калибровка.” (V14) “Ваш SSOT-код допускает override параметров через **params. Любой аналитик может незаметно поменять ε и получить ‘нужный’ индекс.” (V15) “Backfill‑политики нет: вы не говорите, когда разрешено пересчитывать историю. Как тогда в суде доказать, какой индекс был ‘официальным’ на дату решения?” (V17) “Z_skepticism рассчитывается ‘3 моделями’, но без конкретики. Значит, любой подрядчик может подставить свои модели и получить удобный Z.” (V18) “Где таблица ‘v3 vs v4’ по MAE? Возможно, старая и ‘простая’ модель банально лучше предсказывает реальность.” (V19) “Ваша проверка σ_hist аудирует только std по уже очищенной истории. Если экстремальную неделю объявить ‘ошибкой’ и выкинуть, аудит ничего не заметит.” (V20) “Вы называете этот документ ‘Complete Mathematical Design’, но ключевой параметр ε описан как ‘expected 0.35’ без единой реальной цифры или графика. Это не дизайн, а черновик.” (V13) 10.5 КАРТА ИСПРАВЛЕНИЙ P0 — ДО УТВЕРЖДЕНИЯ SC (BLOCKER, ИНАЧЕ STOP) Цель P0: устранить логические и арифметические противоречия SSOT (формулы ↔ код ↔ sanity ↔ доказательства). Обязательные задачи (2–3 недели): Пересчитать sanity‑таблицу и привести её в полное соответствие с compute_index_v4 (V01, V04, V12). Условие: любой sanity‑кейс должен совпадать с SSOT‑кодом с допуском <0.5pp. Если не выполнено → STOP, документ не выносить на SC. Переписать Range Guarantee и No Plateau теоремы под фактический диапазон S_raw и клиппинг (V02, V03, V05, V08). Условие: ни одна теорема не должна содержать шагов, логически противоречащих числам и SSOT‑коду. Устранить gate‑несогласованность (g0,g1, sign‑convention) и зафиксировать константы (V07, V21). Явно и честно описать non‑compensatory статус и роль синергии, добавить S_resilience как официальный bottleneck‑индекс (V06, Sec.10). Жёстко убрать **params override из production‑версии compute_index_v4 (V15, V37). Зафиксировать σ_window, domain σ_hist и обработку σ>50 с точки зрения теорем и кода (V16, V20). Добавить минимальную табличную калибровку ε (значения MAE по grid) (V13). Если любая из этих задач не выполнена → формальный вердикт: FAIL, v4 не может быть принята как стандарт. P1 — ДО ПИЛОТА (ALMATY PILOT), ПОСЛЕ УТВЕРЖДЕНИЯ ДИЗАЙНА Цель P1: сделать модель операционно пригодной и частично защищённой от гейминга. Критические задачи: Полный hindcast v3 vs v4 с train/test split и baseline (V19, V32, V33). Оформленный Anti-Gaming Protocol (12 атак из п.6) в виде отдельного раздела и регламента (V15, V38–V43). Формальный дизайн T_synthetic (взвешивание survey/proxy, CV‑проверка) (V27). Документированный data pipeline с чётким описанием C,V,Z источников и fallback’ов (V26–V31). Введение property‑tests в CI (монотонность, диапазоны, отсутствие NaN, плато‑поведение) (V35). Условие GO на пилот: v4 не хуже v3 по MAE на тестовом периоде (с запасом δ). Anti‑gaming протокол утверждён и задокументирован. P2 — ДО BETA / NATIONAL ROLLOUT Цель P2: усилить causal‑валидность, tail‑risk и внешнюю аудируемость. Ключевые задачи: Реализация t‑copula UQ в v4.1 (описано в App.D) с реальными параметрами, а не placeholder. DAG и causal‑анализ P,D,R→T (Phase 3), synthetic control для Jan 2022. Формализация Audit Board и внешнего аудита (описанного в FUTURE WORK). Стандартизация версий библиотек/моделей (numpy/scipy/NLP) с жёсткой фиксацией в audit‑артефактах (V36, V18). Условие перехода к национальному развёртыванию: Положительное заключение внешнего технического аудитора (академия/международная организация) по v4.1. Итог: В текущем виде SG INDEX v4.0 не выдерживает разрушительного аудита: имеются ложные доказательства, арифметические несостыковки sanity‑таблиц с SSOT‑кодом, семантические противоречия в верхней зоне 100–150, а также серьёзные дыры в калибровке и антиигровых механизмах. При выполнении предложенного P0‑ремонта и дальнейшей P1/P2‑доводке модель может стать управляемо‑надёжной, но только как v4.1+ с явной фиксацией исправлений. ID | Sev | Категория | Цитата / фрагмент | Механизм разрушения | Как атакуют | Минимальный patch | Обязательный тест V01 | Critical | SSOT / Sanity | Таблица “All 5 Sanity Checks (Auto-Generated)” даёт для “Trust Threshold”: Expected 123.5, Result ✓ 123.5 при C=V=T=Z=0.85, σ=0, тогда как код compute_index_v4 использует F_syn = 1.0 + εCT с ε=0.35 [Sec.8]. | По SSOT: T_comp=0.85, S_pot≈0.937, F_gate≈0.823, F_syn=1.2975, F_vol=1→ S_raw≈1.067 → 150·S_raw≈160→clip=150, а не 123.5. Таблица sanity прямо противоречит каноническому коду и формуле [Sec.4, Sec.8]. | “Вы называете таблицу sanity ‘Auto-Generated’, но при T=0.85 ваш SSOT-код даёт 150, а не 123.5. Что является истинной моделью — формула, код или таблица? На базе чего будет принят бюджет?” | Жёстко разделить две версии: (а) либо ε=0 в SSOT (без синергии в KPI) для sanity, (б) либо пересчитать sanity-таблицу по compute_index_v4 и честно указать, что при T=0.85 уже 150 (плато). В самой таблице оставить только значения, полученные автоматическим прогоном кода (и приложить скрипт). | Unit-test: assert abs(compute_index_v4(1,1,0.85,0.85,0) - expected_trust_threshold) < 0.5 где expected_trust_threshold берётся из sanity таблицы. Тест должен падать, если таблицу не пересчитали. V02 | Critical | Proof / Range | В “Property 2: Range Guarantee” сказано: F_syn ∈ [1, 1.35], F_vol ∈ [0,1] и затем: S_raw = min(...) × F_syn × F_vol ∈ [0,1] [Sec.6]. | Математически: min(...)∈ppl-ai-file-upload.s3.amazonaws, F_syn∈[1,1.35], F_vol∈ppl-ai-file-upload.s3.amazonaws ⇒ максимум S_raw=1·1.35·1=1.35>1. Сам документ в разделе sanity сам считает S_raw≈1.067 при T=0.85 и признаёт, что это >1. Доказательство теоремы ложно, а вывод “S_raw∈ppl-ai-file-upload.s3.amazonaws” неверен. | “Вы формально доказываете ‘S_raw∈ppl-ai-file-upload.s3.amazonaws’, но двумя строками ниже сами считаете S_raw>1 для T=0.85. Это textbook пример ложного proof и подрыва доверия к любым последующим теоремам.” | Исправить теорему: честно написать S_raw ∈ [0, 1.35] и формулу S_KPI = clip(150·S_raw, [0,150]). Явно добавить: “Без клиппинга S_KPI может превышать 150, поэтому клиппинг не только косметика, а часть SSOT”. | Property-test: сэмплировать 10⁴ случайных (C,V,T,Z,σ) и проверять 0 ≤ S_raw ≤ 1.35 + ε и 0 ≤ S_KPI ≤ 150. Отдельно убедиться, что количество случаев S_raw>1 не нулевое. V03 | Critical | Proof / Plateau | Раздел “Property 3: No Plateau Until Maximum”: dS_KPI/dT_comp > 0 for all T_comp ∈ [0,1) и “No plateau before 150, only at 150 (saturation)” [Sec.6]. | Численно: уже при T_comp=0.85, C=V=1, ε=0.35, σ=0 получаем S_raw≈1.067, S_KPI=150 (clip). Для любого T_comp∈[0.85,1) при тех же C,V,σ индекс остаётся 150 — явное плато до достижения T=1. Доказательство игнорирует клиппинг и тот факт, что F_syn>1 может вывести систему в плато до “идеала”. | “Вы формально доказываете, что индекс монотонен по T до самого T=1. Но при T=0.85 он уже saturate=150 и дальше не растёт. Значит, theorem неверна, а Steering Committee вводится в заблуждение по поводу чувствительности к доверию.” | Переформулировать теорему: “S_raw строго возрастает по T_comp на [0,1), но S_KPI может образовывать плато при 150 за счёт клиппинга при S_raw>1.0.” Добавить график S_KPI(T_comp) для C=V=1, σ=0, показывающий плато от ~0.85 до 1.0. | Property-test: сгенерировать сетку T_comp∈[0.8,1.0], при C=V=1, Z=T, σ=0 и убедиться, что S_raw растёт, а S_KPI имеет отрезок константы (различие менее 0.1) до T<1. Фиксировать это в тесте как ожидаемое поведение. V04 | Critical | SSOT / Sanity | В sanity-таблице указан тест “High Volatility” с C=V=T=Z=1, σ=20, Expected 50.0 [Sec.8]. SSOT: F_syn=1.35, F_vol=1/(1+0.1·20)=1/3, min=1 ⇒ S_raw=1.35·1/3=0.45, S_KPI=67.5. | Повторяется проблема v3: численный sanity не согласован с SSOT. Если убрать синергию (ε=0), получится S_KPI=150·(1·1/3)=50; но SSOT-код явно использует ε=0.35. Либо sanity писался под “старую” формулу, либо код несогласован с дизайном. | “Второй sanity-тест подряд, который не воспроизводится функцией compute_index_v4. Вы уверены, что код и документ вообще описывают одну и ту же модель?” | Либо явным образом указать, что sanity-таблица для “resilience score” (без F_syn), либо пересчитать значения с учётом F_syn и переписать Expected=67.5. Нельзя оставлять 50.0 при ε=0.35 как единственный SSOT. | Unit-test для каждого sanity-кейса: expected берётся напрямую из таблицы; тест должен прогонять compute_index_v4 и падать, если V05 | Critical | Proof / Range & Design | В proof Range Guarantee шаг 6: S_raw ∈ [0,1] используется далее как аргумент, что S_KPI ∈ [0,150] и что клип — “формальность” [Sec.6]. | На самом деле диапазон S_KPI= обеспечивается исключительно клиппингом, т.к. без него при All Optimal имеем 202.5, при Trust Threshold ≈160 и т.д. Формально неверное доказательство создаёт у аудитора ощущение “естественного” диапазона, скрывая роль клиппа. | “Ваше доказательство строится на ложном шаге и создает видимость естественного диапазона , тогда как на деле диапазон реализуется грубым усечением. Это textbook ‘false assurance’.” | Исправить proof: честно выделить два шага — (1) теоретический максимум S_raw_max=1.35, (2) диапазон S_KPI обеспечивается именно clip. Добавить фразу: “Без клиппинга индекс может выходить за 150, поэтому клиппинг — часть математического ядра, а не косметика.” | Property-test: поискать max(S_raw) по сетке входов; тест должен проверять, что max(S_raw)>1, и что при снятии клиппа S_KPI может выйти за 150. V06 | Critical | Min+Syn / Non‑Comp | В разделе 2 говорится: “Non-Compensatory: Low trust ≠ high capacity rescue. Trust is not tradeable.” [Sec.2]. Фактическая SSOT: S_raw = min(S_pot, F_gate) * (1+εCT_comp) * F_vol [Sec.4]. | Численно при T=Z=0.2, C растёт 0.2→1 (V=1, σ=0): gate фиксируется (низкое доверие), но F_syn=1+0.35C0.2 растёт 1.014→1.07, индекс растёт ~на 5–6%; при σ>0 эффект сильнее. То есть C частично компенсирует низкий trust, что прямо противоречит жёсткой формулировке “low trust ≠ high capacity rescue”. | “Вы декларируете ‘non-compensatory’ и ‘trust not tradeable’, но сама формула содержит множитель (1+εCT). При фиксированно низком доверии рост C увеличивает KPI. Это и есть компенсация.” | Ослабить формулировку: заменить на “частично non‑compensatory: bottleneck по min(S_pot,F_gate), но сверху допускается ограниченная синергия ~35%”. Для строгого non‑compensatory аудита ввести отдельный официальный индекс без F_syn (S_resilience) и указать, что именно он используется для критических решений. | Тест: для фиксированных T=Z=0.2, V=1, σ=0, посчитать S(C=0.2) и S(C=1.0); тест явно должен показывать рост. Этот же тест нужно использовать в документации как иллюстрацию ограниченной, но существующей компенсации. V07 | High | Gate / SSOT | В определении gate: g(x)=1/(1+e^{−x}), затем g_0 := g(kθ) ≈ 0.1544, g_1 := g(−k(1−θ)) ≈ 0.5744 [Sec.4]. | Для g(x)=1/(1+e^{−x}) при k=2, θ=0.85: kθ=1.7 → g(1.7)≈0.8456, а не 0.1544; −k(1−θ)=−0.3 → g(−0.3)≈0.4256, а не 0.5744. Очевидно, сюда попали числа из старой версии (где аргументы имели противоположный знак). Python-код (expit(k*theta) и expit(-k*(1-theta))) использует правильные значения, а текст — нет. | “В формальном определении g_0, g_1 у вас расхождение почти на 0.7 (0.845 vs 0.154). Это базовое численное несоответствие между текстом и реализацией. Какой gate считать легитимным при аудите?” | Выровнять определение: либо поменять сигнум в g(x) на прежний (как в v3), либо пересчитать численные приближения в тексте (0.8456 и 0.4256) и согласовать пример F_gate(T=0.85). Добавить мини-таблицу значений g_0,g_1, F_gate(0,0.85,1) как часть SSOT. | Unit-test: жёстко проверить, что вычисленные в коде g_0 и g_1 совпадают с зафиксированными в документации константами (до 1e−4). Любое расхождение — fail CI. V08 | High | Proof / Monotonicity | В “Property 1: Monotonicity” доказывается, что ∂S_raw/∂C>0 и аналогично для V,T,Z, при этом S_KPI упомянут как монотонный [Sec.6]. Клиппинг на 150 игнорируется. | Как только S_raw≥1 (T≈0.85, C=V=1), S_KPI=150 и дальнейшее увеличение C,V,T,Z не меняет S_KPI. То есть S_KPI не строго монотонен: есть плато. Подмена S_raw↔S_KPI в формулировке создаёт ложное ощущение “чем выше T, тем всегда выше KPI”. | “На словах вы доказываете монотонность индекса, но фактически работаете с неограниченным S_raw. Как только включается clip, S_KPI перестаёт расти. Это принципиально другой объект.” | Развести свойства: (а) строгая монотонность S_raw (без клиппа), (б) кусковая монотонность S_KPI (возрастающая до сатурации, затем плато). В теореме явно указать, что речь идёт о S_raw, а не о финальной шкале. | Property-test: проверить, что S_raw(C2)≥S_raw(C1) при C2>C1, но для S_KPI зафиксировать возможное равенство при C2>C1 (из-за клиппинга). Тест должен документировать это поведение, а не скрывать его. V09 | High | Gov / Semantics | “Why 150, not 100?” — предлагается семантика: [0–50] critical, [50–100] fair-good, [100–150] excellent-overheat [Sec.6]. При этом sanity “All Optimal” = 150 и “Trust Threshold” при включённой синергии тоже даёт 150 [Sec.8]. | Если 150 — это “overheat/alert”, то “All Optimal” и даже точка порога доверия (0.85) оказываются в зоне перегрева. Практически вся верхняя часть “excellent” превращается в плато 150, теряя различимость между “очень хорошо” и “перегрев/alert”. | “Вы декларируете, что 100–150 — зона ‘excellent–overheat’, но идеальный и даже пороговый случаи уже дают 150. Чем тогда отличается здоровая система от перегретой на графике? Управленчески это токсично.” | Развести шкалы: (а) техническая S_tech до 150, (б) официальная управленческая, скажем, до 120, с отдельным флагом ‘overheat’ при S_raw>1.0. Либо сменить зону: ‘overheat’ только >135, а All Optimal прописать как 135, а не 150. | Acceptance тест: набор кейсов (All Optimal, Threshold, Near Optimal, True Overheat) должен давать разные значения в верхней зоне, а не всегда 150. Тест должен падать, если ≥2 разных сценария из этого набора дают одинаковый KPI. V10 | High | Gov / Zones | Раздел 15 вводит уровни кризиса по S_KPI: Level0 >120, Level1 80–120, Level2 30–80, Level3<30 [Sec.15]. При этом sanity “High Volatility” на All Optimal с σ=20 даёт (по коду) 67.5 → Level2, тогда как таблица ожидает 50 [Sec.8]. | Нелинейный и несогласованный переход: при небольшом ухудшении по σ (0→20) All Optimal падает с Level0 (150) в середину Level2, причём разрыв в 80 пунктов (!) по одной метрике. А в документации ожидаемое значение 50 ещё сильнее усугубляет скачок. | “Ваши зоны кризиса настолько грубы, что одно изменение σ с 0 до 20 (при идеальном C,V,T,Z) кидает страну с ‘нормала’ на 'High Alert'. При этом в sanity вы ещё и ошибаетесь на 17.5 п.п. Это неприемлемо для KPI уровня Кабмина.” | Смягчить зонирование: ввести промежуточные подзоны для high vol при высоких C,V,T; отдельно маркировать волатильность (второй индикатор), не сваливая всё в один KPI. И обязательно пересчитать все зоны по фактическому распределению S_KPI (квантильный подход). | Property-тест: прогнать All Optimal при σ=0,10,20,50 и убедиться, что переходы между уровнями разумны (например, не более 1 уровня за одно “типичное” изменение σ). Тест должен сравнивать дискретную зону до и после изменения σ. V11 | High | Min+Syn / Monotone | В “Property 1: Monotonicity” для случая, когда gate — bottleneck: ∂S_raw/∂C = F_gate·ε·T_comp·F_vol > 0 [Sec.6]. | Формула игнорирует зависимость bottleneck от C: при росте C S_pot растёт и может стать <F_gate, переключив bottleneck с gate на S_pot. В точке переключения поведение ∂S_raw/∂C не непрерывно, и на практике возможно, что при небольшом увеличении C значение min(...) уменьшится (из-за численной ошибки / разных округлений), давая нелинейности. Доказательство не рассматривает точку S_pot=F_gate вообще. | “Ваш proof просто игнорирует границу S_pot=F_gate, где min() недифференцируема. В реальном коде это порождает ‘ломаную’ зависимость и может выдать неожиданные эффекты вокруг границы.” | Явно рассмотреть случай S_pot≈F_gate, добавить лему о непрерывности и провести численный тест вокруг границы (C±δ). В документации признать, что proof носит piecewise характер, а не гладкий. | Property-тест: выбрать набор точек, где S_pot≈F_gate, и проверить численно monotonicity S(C−δ)≤S(C)≤S(C+δ). Тест должен охватывать случай смены bottleneck. V12 | High | SSOT / Sanity Auto-Gen | Таблица sanity помечена как “Auto-Generated”, но ниже в документе следуют ручные рассуждения “Wait, this should be 123.5, not 150. Let me recalculate…” c явной путаницей между версиями формулы и включением/отключением F_syn [Sec.8]. | Структурно это значит, что sanity-таблица не является прямым выводом кода, а была сначала рассчитана без F_syn, затем “подправлена” вручную, затем поверх добавлена новая логика, но таблица не обновлена. Любой внешний аудит воспринимает пометку “Auto-Generated” как прямое утверждение воспроизводимости — что здесь не так. | “Под таблицей, которую вы называете ‘auto-generated’, вы дальше рассуждаете ‘let me try without synergy’. Это признание ручной калибровки и фактического отсутствия связи с SSOT-кодом.” | Убрать ручной текст ‘Wait…’ из основного тела (перенести в историю ревизий) и гарантировать, что sanity-таблица реально формируется скриптом, приложенным в annex (с фиксированным seed, версиями библиотек). В текст добавить явную ссылку на этот скрипт как единственный источник таблицы. | Acceptance-тест в CI: запуск скрипта автогенерации sanity-таблицы, сравнение результата с вшитой в репозиторий версией (byte‑for‑byte). Любое расхождение — блокирующий тест перед релизом. V13 | High | Validation / ε Calibration | “Calibration Method for ε (Synergy)” описывает grid search по ε с псевдокодом, но без таблицы результатов MAE, без указания используемого периода (кроме фразы “2020–2024”) и без фактического значения MAE=8.5 pp — это помечено как “Expected result: ε*≈0.35” [Sec.7]. | Нет ни одной воспроизводимой цифры: какой MAE при ε=0.0, 0.3, 0.4? Какой train/test split? Какая cross-validation? “Expected” без вывода — audit hole: нельзя проверить, что ε реально выбран оптимально, а не “на глаз”. | “Вы заявляете ‘ε≈0.35 (minimal MAE≈8.5pp)’, но не приводите ни одной фактической строки вывода grid search. Нет ни таблицы, ни seed, ни файла. Это не калибровка, это устное обещание.” | Включить в приложение реальный вывод grid search (таблица ε→MAE_train, MAE_test), указать точный период train (например 2020–2022) и test (2023–2024). Зафиксировать seed и версию кода. В Range Guarantee/Properties ссылаться на эту таблицу. | Unit-test: прогнать grid search на зафиксированном sample dataset и assert’ить, что argmin MAE совпадает с ε в registry (0.35) с точностью до ±0.05; и что MAE(ε*) меньше, чем MAE(ε=0). V14 | High | Validation / μ Calibration | “Calibration Method for μ (Volatility Penalty)” опирается на “Basel III precedent: VaR penalty α=0.10” и “5 experts propose μ∈[0.05,0.15] → consensus μ=0.10” [Sec.7]. | Связь между Basel III VaR-пенальти (в финансовых рисках) и штрафом за волатильность информационного индекса не формализована. Нет ни одной регрессионной модели “σ_hist vs drop in trust”, ни таблицы “observed drop ~33% при σ=20pp”. Ссылка на Basel носит риторический характер и не создаёт проверяемой калибровки. | “Вы ссылаетесь на Basel III, но не показываете ни одной формулы VaR или mapping σ→drop. Это rhetorical calibration, не статистическая.” | Либо убрать отсылку к Basel, либо включить формальную модель: регрессия ΔT = β·σ_hist + ε с оценкой β и его доверительным интервалом, плюс таблица наблюдаемых кейсов (σ, фактическое падение доверия). По этим данным уже выводить μ. | Тест: на исторических данных посчитать наблюдаемый drop при σ=10,20,50 и сравнить с F_vol(σ). Допуск (расхождение) должен быть явно указан, иначе тест проваливается. V15 | High | Ops / Reproducibility | В коде compute_index_v4 параметры могут быть переопределены через **params, при этом SSOT-регистр параметров в PARAMETERS отделён от входных overrides [Sec.12]. | Это скрытый backdoor: любой аналитик может вызвать compute_index_v4(C,V,T,Z,σ, epsilon=0.5, mu=0.05) и получить “альтернативный” индекс без записи в конфиге/CSV. При этом раздел 11/13 требует жёсткого совпадения с registry CSV. Налицо конфликт между архитектурой “single function configurable” и governance-требованием SSOT. | “Ваш SSOT легко обойти одной строкой: compute_index_v4(..., epsilon=0.6). Это даёт неформальный тюнинг индекса, не отражённый в параметр-регистре. Для внешнего аудитора это непростительная дыра.” | Для production‑кода запретить runtime‑override параметров (убрать **params) и жёстко привязать вычисление к замороженному объекту конфигурации, версионированному в CSV/DB. **params оставить только в тестовом/экспериментальном API с другим именем функции. | Unit-test: попытаться вызвать compute_index_v4 с override параметрами в production‑режиме; тест должен падать (TypeError или явный запрет). Отдельный тест для experimental API может разрешать overrides, но с явной пометкой. V16 | Medium | SSOT / Volatility Domain | Theorem Range Guarantee предполагает σ_hist∈ [Sec.6], но определение σ_hist как std S_i по окну 24 недель с S_i∈ [Sec.5] теоретически допускает σ>50 (например, 12 недель на 150 и 12 недель на 0 дают σ≈75). | Domain σ∈ — это умозрительное ограничение, не вытекающее из определения. Если фактически σ_hist>50, формула F_vol=1/(1+0.10σ) даёт ещё меньший штраф и вылезает за заявленные свойства. | “Вы в теореме ограничиваете σ≤50, но определение σ_hist этого не гарантирует. При экстремальном сценарии 24 недель ‘0/150’ σ≈75, и все ваши свойства для σ невалидны.” | Уточнить domain σ: либо математически показать, что для реальных S_KPI σ≤50 (через ограничение на скорость изменения), либо изменить domain theorem на σ∈ и переформулировать свойства F_vol. В SSOT-регистре явно указать, что значения σ>50 считаются out-of-range и требуют ручного расследования. | Тест: искусственно создать worst-case S_i=[0,…,0,150,…,150] и проверить вычисленный σ_hist; сравнить с заявленным domain. Добавить assert, что при σ_hist>50 включается “extreme volatility mode” (отдельная ветка логики). V17 | Medium | Ops / Backfill | В разделе 11 Step 2: Reproduction Test предполагает, что аудитор может воспроизвести последние 13 недель, имея raw data и compute_index_v4 [Sec.11]. Политика backfill (что делать при пересчёте старых недель при обновлении данных) не описана. | В реальном мире данные доочищаются, пересматриваются, меняются источники. Без строгой backfill‑политики (например: “пересчитываем S_KPI только за последние N недель, дальше freeze”) аудитор не сможет понять, какой именно индекс был “официальным” на дату принятия решения. Это риск юридической не-доказуемости. | “Если вы пересчитаете январский индекс в марте (по обновлённым данным), то какой из них ‘официальный’ для решения, принятого в январе? Документ этого не описывает.” | Ввести политику: (а) “no backfill” для уже опубликованных недель (только annotations), либо (б) “controlled backfill: до 4 недель назад с сохранением обеих версий и логом причины исправления”. Отразить это в governance‑разделе и в структуре файлов (v1/v2). | Тест: симулировать смену источника или исправление raw данных за прошлую неделю и убедиться, что система либо (а) не пересчитывает историю, либо (б) делает это с созданием новой версии отчёта и явной маркировкой. V18 | Medium | Data / Z Measurement | Z_skepticism определяется как “Sentiment analysis, 3 NLP models consensus” [Sec.13], но нет описания языков, доменов, веса моделей, bias‑контроля. | Отсутствует reproducible pipeline: без указания конкретных моделей/языков два подрядчика могут считать Z совершенно по-разному. Это разрушает интер-компарабельность во времени и между регионами, и даёт простор для манипуляций (подбор модели с “нужной” оценкой скепсиса). | “Три неизвестные модели на неизвестных языках — это не SSOT для Z. Это чёрный ящик, который нельзя аудировать.” | Минимизировать свободу: перечислить конкретные модели (например, ruBERT-sentiment, kz-bert, multilingual-X), их веса, регулярные re‑train процедуры и bias‑тесты на опорных корпусах. Ввести отдельный Z_model_version в параметр-регистр. | Тест: прогнать Z‑пайплайн на эталонном наборе текстов (fixed corpus) и проверять, что итоговые значения совпадают для всех релизов модели (или изменения задокументированы). V19 | Medium | Validation / Hindcast | В разделе 16: “1-way Sensitivity” приводятся таблицы изменения S_KPI при изменении ε, μ, k, но нет ни слова о том, как v4 сравнивается с v3 по hindcast MAE/RMSE [Sec.16]. | Без прямого сравнения “v3 vs v4” на одном и том же test‑периоде невозможно утверждать, что v4 лучше (или хотя бы не хуже). Это особенно критично, учитывая новые сильные нелинейности (min+syn+clip). | “Где таблица ‘v3 vs v4’ по MAE на 2023–2024? Возможно, v4 с красивой математикой просто хуже предсказывает реальность, чем старая линейная модель.” | Добавить раздел “v3 vs v4 Hindcast Comparison”: MAE, RMSE, MAPE на общем hold‑out периоде, с указанием доверительных интервалов. Не запускать v4 в прод до тех пор, пока нет явного улучшения или хотя бы не‑ухудшения. | Тест: автоматически считать MAE(v4) и MAE(v3) на фиксированном test‑set; тест должен падать, если MAE(v4) > MAE(v3)+допуск (например 2pp). V20 | Medium | Adversarial / Gaming σ | В Sec.5 σ_hist определяется как std за 24 недели по S_i, без явного уточнения, сохраняются ли в этом окне недели с “аномалиями”/ручными overrides, и без защиты от умышленного “сглаживания истории” (удаление пиковой недели, замена источника) [Sec.5, Sec.11 Step 4]. | Атакующий может “скрыть” одну-две экстремальные недели (манипулируя данными или флагами “ошибка”), σ_hist резко упадёт, F_vol возрастёт, и индекс вырастет без реального улучшения стабильности. При этом заданный аудит Step 4 проверяет только соответствие между σ_hist_reported и std(S_KPI) — если “грязную” неделю удалили до, аудит не заметит. | “Достаточно договориться о том, что ‘эта ужасная неделя с падением S_KPI — ошибка замера’ и исключить её из окна. Ваша проверка σ_hist лишь подтвердит ‘корректный’ std по уже отфильтрованным данным.” | Ввести строгий log всех исключённых/заменённых недель и требование, чтобы в volatility‑аудите использовались сырые значения S_KPI до фильтрации (или параллельно считалась σ_raw). Любое отличие σ_hist(raw) и σ_hist(cleaned) должно триггерить ручной разбор. | Тест: смоделировать сценарий с одной экстремальной неделей, затем её удалить и пересчитать σ_hist. Тест должен подтверждать, что система замечает удаление (через разницу raw vs cleaned и соответствующий флаг).

Сущности