# FINDINGS — почему остаётся разрыв на широких скобках

Запрос Валерия 2026-09-21: «Разбери, почему остаётся разрыв по порядку модели». Все числа — с сервера
(Linux), выводы лежат рядом: `results_diag_model_order.txt`, `results_diag_model_order_checks.txt`,
`results_diag_flat_detectable.txt`, `results_diag_band_by_family.txt`.

## Метод разбора: та же информация, две модели

Нового метода нет. Трассировочный крючок в `pure_root` (не меняет поведения, пишет только по запросу)
записывает состояние перед каждым шагом. В каждом состоянии нашей собственной траектории на ОКИ из тех
же трёх уже оплаченных оценок и наш шаг даётся по одной дополнительной оценке; мера — половинения
скобки, как в исходном замере 0.93 против 2.26. Выборка: 33 задачи CHA, которые мы решаем и на которых
проигрываем Чандрупатле, 822 состояния.

## Главный вывод: «порядок модели» объясняет только треть

Разрыв на этих задачах — 262 оценки:

| часть | семейства | оценок | чем выигрывает Чандрупатла |
|---|---|---|---|
| **2/3** | fun3–fun6 = (x−3)³, 6(x−2)⁵, x⁹, x¹⁹ | **178** | **делением**: 93%, 96%, 100%, 100% его шагов |
| **~1/5** | fun1 = x³−2x−5 на широких скобках | **58** | моделью: ОКИ из НАШИХ точек 10.37 половинения против наших 0.62 (fun1.4) |
| ~1/10 | fun2, fun8, fun9 | 26 | смешанно, 40–84% делений |

**Плоские семейства — не модель, а решение, когда от модели отказаться.** Там не работает никакая
интерполяционная модель: наш шаг снимает 0.41–0.81 половинения скобки за оценку, ОКИ из тех же точек —
0.01–0.17. Чандрупатла не выигрывает их моделью — он её не использует и делит, получая ровно 1.0. Мы
проигрываем, потому что наш шаг медленнее деления, а наша гарантия (≤ 2× деление) именно это и
разрешает.

**Подтверждение по семействам из уже посчитанной сетки** (его полоса в нашем шаге, предохранитель
`project`): fun4/5/6 — 573/456/456 → **296/239/235** при его собственных **293/228/228**; и одновременно
+164, +111, +170, +144 на fun1/2/8/9, где полоса отвергает хорошие шаги. Итог полосы по набору (3066)
был суммой этих двух противоположных эффектов — поэтому слот 2 и выглядел как «место решения разрыва не
держит». **Держит, но ни одно измеренное чтение не принимает это решение верно для НАШЕГО шага.**

**fun1 — действительно порядок модели, и причина структурная.** Наш шаг
`x + (1−S)(far − x) = S·x + (1−S)·far` — выпуклая комбинация двух точек. У квадратичного интерполянта
в тройке, охватывающей корень, ровно один лагранжев вес **отрицателен** (проверено на всех 428
невырожденных состояниях; в остальных пяти отрицательный вес ушёл в −0.000 переполнением вниз).
Похожесть в [0,1] отрицательного веса дать не может — это Предложение 4 статьи, продолженное с двух
точек на три.

## Можно ли узнать плоский режим — измерено, пока нет

Условие проигрыша касательного шага делению выводится точно: шаг ложится в `e(1−1/m)`, что хуже
половины при `m ≥ 2` (двойка — это ½ деления, не выбор). Но трёхточечная оценка `_local_order`
режима не видит:

| группа | состояний | m ≥ 2 |
|---|---|---|
| APS | 990 | **0.2%** — верное молчание |
| CHA прочие | 240 | 0.0% |
| CHA плоские (m = 3…19 по построению) | 659 | **5.8%** — слепота |

Гейт по ней построить нельзя. Непроверенный кандидат (только идея, не замер): отношение двух подряд
остатков — на подходе порядка m под касательными шагами оно устанавливается на `(1−1/m)^m`, а у
простого корня уходит в ноль.

## Что исправлено в статье

`§sec:widelimit` утверждал, что весь предел — порядок модели; это верно для fun1 и **неверно для двух
третей разрыва**. Исправлено, как уже дважды исправлялся неверно записанный механизм. Исправлены
также вывод в `§sec:decision`, аннотация (рекорд APS 2523, раскладка разрыва) и «Future work»:
логарифмическая замена оттуда убрана, она опровергнута.

## ⚠️ Открытый вопрос, который решает Валерий

`article/sim_numerics.tex` с **первого** коммита репозитория несёт заголовок «STALE … current text is
sim_numerics.md, do not build a PDF from it». Все правки статьи сессий 20–21 сентября сделаны в `.tex`;
в `.md` (не менялся с 24 августа) нет ни одного из этих результатов, а в `.tex` — первых
поправок из `.md`. Какой файл каноничен, не решено. Новые числа в тексте **ещё не проведены через
`verify_article.py`** — они прослеживаются к файлам `results_diag_*.txt`, но машинной сверки для них
пока нет.