Ниже — разбор в двух плоскостях: (А) что именно изменилось в орбитальной факторизации как алгоритмическом контуре, и (Б) как SYM_SCAN_FLOW

Ниже — разбор в двух плоскостях: (А) что именно изменилось в орбитальной факторизации как алгоритмическом контуре, и (Б) как SYM_SCAN_FLOW дисциплинировал и удешевил L4-вычисления.

A) Как улучшилась орбитальная факторизация

1) Математика вихря почти не изменилась — изменилась “операционная постановка”

Сама процедура “вихря” — это по сути одно и то же:

есть множество узлов U_k (размер n);

есть группа допустимых перестановок Aut_k (подгруппа S_n);

строим орбиты на U_k^3 по действию Aut_k и работаем по представителям:

Orbits_k3 = U_k^3 / Aut_k.

Улучшение внес SYM_SCAN_FLOW не в формулу, а в то, что теперь всегда ясно и воспроизводимо, какие именно U_k и Aut_k вы используете, и почему.

Именно это делает факторизацию “не приёмом”, а постоянным этапом вычисления.

2) Что стало лучше алгоритмически (на практике)

2.1. Исчезла “скрытая неопределённость входа”

Раньше главный источник расползания сложности был не U^3, а то, что:

U мог “плыть” (какие узлы вообще участвуют);

Aut мог “плыть” (что считаем симметрией — зависит от eps/режима/ограничений);

параметры могли меняться “по ходу” без фиксации.

SYM_SCAN_FLOW заставляет оформлять это как снапшот:

S_k = (..., U_k, M, eps, delta, I_k, Aut_k, Orbits_k3, ...)

То есть факторизация больше не стартует “из воздуха”: она стартует из фиксированного состояния.

2.2. Появилась политика режима скана Aut_k (и это влияет на стоимость)

SYМ_SCAN_FLOW вносит ключевую норму:

если n <= 8 — разрешён EXHAUSTIVE (перебор S_n);

если n > 8 — только RESTRICTED (affine / stabilizer / generators), и класс перестановок фиксируется в данных.

Это важно не философски, а вычислительно:

стоимость построения Aut_k становится предсказуемой;

стоимость орбит на U_k^3 становится предсказуемой, потому что зависит от |Aut_k| и способа задания группы (в идеале — генераторами).

2.3. Появился “градиент симметрий” как инструмент инкрементальности

Появились sym_loss(k->k+1), sym_gain(k->k+1), core(k->k+1).

Даже если в текущей реализации вы пока пересчитываете орбиты “в лоб” для каждого S_k, сама структура данных теперь позволяет следующий шаг оптимизации (и он уже легитимен):

если Aut_{k+1} ⊂ Aut_k (sym_loss), орбиты раскалываются (refinement), и вы можете доуточнять разбиение, не пересчитывая всё заново;

если Aut_k ⊂ Aut_{k+1} (sym_gain), орбиты слипаются, и вы можете агрегировать.

Иными словами: SYM_SCAN_FLOW создал почву для настоящей инкрементальной орбитальной факторизации, а не “пересчёт с нуля всегда”.

3) Важная честная оговорка (чтобы не было самообмана)

Если спрашивать строго: “улучшился ли математический алгоритм факторизации?” — ядро вихря то же самое.

Улучшилось то, что:

факторизация теперь включена в протокол (всегда на одном и том же месте);

её входы фиксируются;

режим скана Aut_k становится наблюдаемым и воспроизводимым;

появляется механизм сравнения групп, позволяющий инкрементальную оптимизацию дальше.

Это и есть практическое “улучшение алгоритма” в инженерном смысле.

B) Как SYM_SCAN_FLOW повлиял на L4-вычисления

L4 у вас — это не “четыре числа”, а режим: ориентации, зеркала, кадры, политика инвариантов, набор гейтов. И главный риск L4-расчётов всегда один:

L4-правила тонко зависят от контекста; если контекст меняется незаметно, результат перестаёт быть сравнимым и проверяемым.

SYM_SCAN_FLOW сделал три вещи.

1) “Контекст L4” стал частью снапшота

В L4 вы неизбежно используете параметры вроде:

выбор кадра/ориентации;

фиксированные точки/якоря (delta.fixed_nodes);

режим зеркала (mirror policy);

допустимый класс перестановок (что вы считаете симметрией в текущем расчёте).

Раньше это могло жить “в голове” или “в тексте”.

Теперь это должно быть внутри S_k (в delta/notes/proto.payload) и, главное, смена этих вещей должна проходить через:

PARAM_CHANGE → затем FREEZE (Z0a) → новый S_{k+1}.

Это радикально снижает “дрейф режима” в L4.