Why the wide-bracket gap remains, taken apart on the SAME evaluations: 'order of the model' explains only a third. Of the 262 evaluations lost on 33 problems, 178 sit on fun3-fun6 - pure powers of order 3, 5, 9, 19 - where no interpolating model works (our step 0.41-0.81 bracket halvings per evaluation, IQI from our own points 0.01-0.17) and Chandrupatla wins by BISECTING 93-100% of his steps; our step is slower than bisection there and our 2x-bisection guarantee licenses it. His band inside our step confirms it per family: fun4/5/6 573/456/456 -> 296/239/235 against his 293/228/228, while +164/+111/+170/+144 on fun1/2/8/9 where it refuses good steps - slot 2's total was two opposite effects summed. Only fun1 (58) is model order: IQI from our three points 10.37 halvings against our 0.62; a convex two-point step cannot carry IQI's negative weight (428/428 non-degenerate states; five underflowed to -0.0).

The flat regime is not detectable by the three-point order estimate: m >= 2 (the exact condition for a tangent step to lose to a halving) fires on 0.2% of APS states and on only 5.8% of states of pure powers of order 3-19. Paper corrected where it said the whole gap is model order (widelimit, decision, abstract, future work - the refuted log transform removed). WARNING recorded in FINDINGS_model_order.md: article/sim_numerics.tex has carried a STALE header since the first commit (current text = sim_numerics.md, unchanged since 08-24); every paper edit of 09-20/21 went into the .tex, the .md has none of them. Which file is canonical is Valeri's call. The new text numbers trace to results_diag_*.txt but are not yet machine-checked by verify_article.py. Trace hook in pure_root is behaviour-neutral and pinned; 762 pass on the server twice.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

FINDINGS_model_order.md

@@ -0,0 +1,74 @@
+# 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`, но машинной сверки для них
+пока нет.