Research Protocol v1.0: Segment Engine + dh-dynamics

1. Объект исследования: сегмент Core v2

Сегменты строит тот же авторский core.py, что лежит у нас в s0/base/. Все уровни отсчитываются от S0 в шагах STEP в сторону сегмента: вверх у LONG, вниз у SHORT.

2. Новый слой: dh-dynamics

3. Исходы сегмента — пять групп

Группа складывается из события выхода и того, был ли до него PARTIAL. TARGET и PARTIAL нельзя сливать в одну «успешную» группу: протокол прямо называет это методической ошибкой. Вместе они составляют IMPULSE — сегменты, где цена дошла хотя бы до 6·STEP.

По impulse_profile.csv сверено. В профиле протокола PARTIAL_ONLY = 43 и GAP_WITH_PARTIAL = 1: один гэп с частичной фиксацией вынесен отдельно. PARTIAL_ONLY здесь — это REVERSAL после PARTIAL. Стоп после PARTIAL (STOP_AFTER_PARTIAL) в коде предусмотрен, но в данных RIZ6 не встретился.

Картина простая: весь минус дают STOP_ONLY (59 % сделок, −31220). TARGET и PARTIAL вместе зарабатывают +23480, но этого не хватает. Поэтому любой фильтр оценивается по тому, сколько STOP он отсекает и сколько IMPULSE при этом теряет.

4. Принципы методологии

5. Конвейер

После каждого шага в протоколе есть ручная проверка: число событий, exit_event.value_counts(), распределение групп, размер файла сигналов.

6. Три ключевых признака

1. Lag от S0 — самый сильный одиночный предиктор сверено

Медиана времени от появления S0 до входа. Если цена прошла 3 STEP за 1–2 свечи, это импульс, и он чаще доходит дальше. Медленное подползание к KEY — признак будущего стопа. Оптимум для IMPULSE: lag ≤ 10 (precision 0,43, recall 0,56).

2. Состояние Width на входе сверено

У TARGET длинное окно сжато, а короткое раздуто: расхождение, новое движение внутри спокойного фона. У STOP раздуты оба окна, рынок уже «расплескался». Профиль TARGET: l_abs < 700, s_abs > 300, ratio > 0,40, spread < 400. Как самостоятельный фильтр он не работает (precision 0,23), зато зеркальное правило-запрет работает.

3. Контекст двух предыдущих сегментов

Важно, что было до (prev) и до-до (prevprev). REV_NO_PARTIAL в роли prev почти вдвое повышает шанс следующего TARGET (lift 1,85). PARTIAL_ONLY, наоборот, понижает (lift 0,79). Если prevprev = REV, после TARGET рынок продолжил движение в 5 случаях из 5. Сжатие длинного окна от prevprev к TARGET (delta_l_abs > 100) даёт precision 0,75.

7. Каталог гипотез

Часть I — Width и lag в сегментах

Часть II — цепочки и удержание

Часть III — сигналы dh

По архиву часть III уже прогнана: есть attach_signals_v2, signal_deep_analysis и combined_filter v3 с PRIORITY_STRONG. Протокол ссылается на «часть V» с открытием «сигнал внутри сегмента», но самой части V в файле нет (см. раздел 14).

8. Фильтр входа v2

9. Правила после входа

10. Сигналы dh: каналы A и B

Четыре отношения сигнала к сегменту

Открытие сессии 3: решает inside, то есть сигнал не до входа, а во время сделки. Отсюда правило №4 и PRIORITY_STRONG. Сигнал after слабо намекает, что следующий вход в ту же сторону сработает. Это отложено. Следующий уровень детализации — когда внутри сегмента пришёл сигнал: ранний подтверждает вход, поздний — продолжение.

11. Что опровергнуто

• SkipB не отличается от случайного пропуска (p = 28,9 %).
• «Ждать два стопа» не работает: серии STOP продолжаются, а не разворачиваются.
• REV как триггер продолжения: только 2 из 32.
• Пики Width на REV все ведут к STOP или REV, не к TARGET.
• Простой Width-фильтр на вход: precision 0,23.
• Объединять TARGET и PARTIAL методически неверно.
• TARGET-skip отдельно слаб, работает только в связке.

12. Часть IV — протокол профилирования (v1.2, концепция)

Было: зафиксированные пороги → натягиваем на инструмент.
Стало: процедура исследования → порождает пороги для каждого инструмента.

base:        271 сегм, avg −39.9, wr 32.8
single:      lag ≤ 10 (P 0.43, R 0.56)
veto:        FORBID 850/550/0.22 → 0.80
             PARTIAL_VETO 700 → 0.71
             REV_VETO 600 / lag 10 → 0.83
transitions: REV→TARGET lift 1.85
             STOP×3 → TARGET, n 11, +470
hold_mode:   delta_l_abs 100, EV 1.77·STEP
dh_signals:  null (not tested yet)
combined:    47 / +56.5 / oos_ok

Калибровка под другой инструмент: FORBID нужно пересчитать от медиан l_abs и spread, LAG_MAX — от медианы lag у TARGET, delta_l_abs — от STEP или R. Открыт вопрос, как сравнивать результаты: парсить stdout скриптов хрупко, альтернатива — переделать их в библиотеку функций.

13. Первый профиль по части IV: BTCUSDT 5M прогон 15.10.2026

Протокол прогнан на нашем контуре BTCUSDT 5M (Bybit, бессрочный USDT-фьючерс). Сегменты взяты из живой цепочки сайта: S0 = 78236,6 от 01.09.2026, STEP = 350, снимок 15.10 10:30 UTC. Это 61 закрытый сегмент и 12972 свечи без единого пропуска. Ширина есть у всех 61, lag — у 60 (кроме первого).

STEP 1. База: поток уже в плюсе

Всего +9646 пунктов, в среднем +158 на сделку (+0,45 STEP), прибыльных 41 %. У RIZ6 было −0,33 STEP на сделку. TARGET на BTC втрое чаще (34 % против 12 %). Поэтому задача протокола здесь другая: не отсеять убыточный поток, а не испортить прибыльный.

RIZ6 и BTCUSDT рядом

Что показал прогон

1. Lag работает наоборот. Lag ≤ 10 мин на BTC почти всегда означает вход сразу после разворота: все 14 случаев с lag = 0 идут за REVERSAL. Это наш мгновенный обратный сегмент (#114). Такие 19 сделок дают в среднем −130, остальные 42 дают +289. Правило автора «lag ≤ 10» оставило бы на BTC худшие сделки. Свип: lag ≤ 10 → 19 сделок, −130; ≤ 120 → 30, +136; ≤ 360 → 44, +212; без ограничения → 61, +158.
2. Ширина на входе почти ничего не говорит. Медианы l_abs, s_abs, ratio и spread у TARGET и STOP совпадают. Свипы находят пороги, но только на 7–15 сделках, например ratio ≤ 0,25: 15 сделок, +712. Ни один не проверен вне выборки.
3. Переходы — инерция. После TARGET следующий TARGET в 57 % случаев, после REV в 11 %. Поэтому TARGET-skip автора («после TARGET в ту же сторону не входить») на BTC вредит: он выкидывает 9 сделок на +1144. Лучшая цепочка из трёх предыдущих — TARGET → TARGET → TARGET: дальше 7 случаев, в среднем +545. После двух стопов подряд — 11 случаев, в среднем +390. После трёх — уже 4 случая, +21; «STOP×3 → TARGET» автора здесь не повторяется.
4. Правило автора через STEP не переносится. LAG ≤ 10, FORBID и veto в пересчёте на STEP 350 пропускают 6 сделок, все в минус, в среднем −372. FORBID в этом пересчёте выкидывает 9 TARGET из 14 пойманных.
5. Свой фильтр BTC — подгонка. На всех 61 он отбирает 14 сделок, +415 (lag ≤ 360, FORBID 1040 / 937 / 0,13, veto). Честно: пороги на первых 36, затем последние 25. В выборке 11 сделок, +386; на проверке 9 сделок, −73 против +161 у всего потока. Вердикт профиля: не применять.
6. Сигналы dh. Из 9 каналов до входа на обеих половинах устоял один: B_st at, касание буфера 1/8 на коротком окне в пределах ±5 мин от входа. Первая часть: 11 сделок, +301 против +92 без сигнала. Вторая: 7 сделок, +444 против +51. кандидат — 18 случаев, и канал выбран как лучший по всей выборке. Ещё A_m before: 7 / +408 и 3 / +431, но это слишком мало.
7. Сигнал inside — артефакт длины сделки. Сегменты с сигналом внутри живут медианно 100–210 свечей, без него 7–58. Чем дольше сделка, тем вероятнее в неё попадёт сигнал, а дольше всех живут TARGET. Поэтому «+930 при A_s inside» ничего не говорит о будущем. Это касается и правила №4 и PRIORITY_STRONG у RIZ6: их нужно проверять с учётом момента сигнала, а не по факту его наличия.
8. Удержание за TARGET. Из 21 TARGET дальше в ту же сторону пошли 9 (A), развернулись 12 (B). delta_l_abs > 300 даёт A в 2 из 3, prevprev = REV — 2 из 2. EV не посчитан: без прогона по свечам (hold_strategy_sim.py у автора в плане) это догадка.

base:        61 сегм, avg +158 (+0.45 STEP), wr 41.0
single:      lag ≥ 10 (P 0.49, R 0.77) — наоборот RIZ6
             l_abs TARGET 1040 = STOP 1037
veto:        FORBID 1040/937/0.13 → 0.57, 28 пойм.
             PARTIAL_VETO 1146 → 3 из 3 STOP
             REV_VETO prev_lag > 0 → 0.71
transitions: REV→TARGET lift 0.32
             TARGET→TARGET lift 1.66
hold_mode:   A 9 / B 12, EV null
dh_signals:  B_st at — кандидат (обе половины)
combined:    14 / +415 в выборке
             test 9 / −73 → oos_ok false

Файлы прогона: research/protocol/out/btcusdt-5m/ — profile_BTCUSDT_5M.json (полный профиль STEP 0–9), filtered_segments_with_signals_v2.csv, ряд ширин, сигналы A и B, logs/ с выводом каждого скрипта автора. Сравнение инструментов — research/protocol/profiles_comparison.csv (RIZ6 из протокола + BTCUSDT). Повторный прогон: prepare_contour.py btcusdt-5m …, затем скрипты по разделу 5, затем step_protocol.py. signal_segment_analysis.py ждёт старый формат v1 файла сигналов и на v2 не запускается; его тесты H3.x покрывает signal_deep_analysis.py.

14. Как я это понял — выводы и замечания

Что стоит учитывать, прежде чем переносить цифры

1. Width есть не у всех сегментов. В impulse_profile.csv ширины пустые у первых 91 сегмента: всё до 10.09 12:00. Есть только у 180 из 271. сверено Причина в dh_dynamics.py: для 5M он по умолчанию считает только последние 5000 свечей (--max-candles). При торговом дне MOEX это примерно месяц от 10.10 назад. Значит, в срезе «до 6 сентября» Width не было ни у одного сегмента. Пустое сравнение даёт «ложь», поэтому FORBID и запреты по prev_l_abs там ничего не отсекали. Этот срез проверял только LAG и правила по prev. Устойчивость именно Width-правил на первой половине не проверена.
2. Это не настоящий out-of-sample. Пороги 850/550/0,22, 700, 600 подбирались на всём файле, потом этот же файл резался на две половины. Честная проверка — подобрать пороги на первой части и только потом применить ко второй. Как раз это и есть план oos_check.py (уровень 7).
3. Малые выборки. PRIORITY_REV: n = 3, PRIORITY_PARTIAL: n = 1, «prevprev = REV → 5 из 5», «STOP×3 → TARGET»: n = 11. Это наблюдения, а не правила. Протокол сам это признаёт, но в рекомендации они уже попали.
4. Lag считается по календарю. Это entry_time − exit_time предыдущего сегмента. Ночной перерыв MOEX попадает внутрь лага и делает его «длинным». Контроль lag_min_* есть у признаков Width, но не у самого lag.
5. Пороги в пунктах РТС. 850, 600, 500 — это 7, 5 и 4 STEP при STEP = 120. На другом инструменте их надо выражать через STEP или через профиль. Часть IV об этом и говорит.
6. Hold-mode пока только оценка. +1,77·STEP посчитаны по следующему сегменту, а не прогоном по свечам с реальным стопом.
7. Документ склеен из нескольких сессий. «Сессия 3» встречается дважды. В плане enrich_events «доработать», в части IV — «уже доработан». Часть III числится в плане, хотя скрипты по ней уже есть. Нет «части V» с результатами inside-сигналов. Нет 6.4 «Данные».
8. STOP записан как «S0 ∓ 2·STEP», а в данных он с той же стороны, что и KEY (раздел 1).

15. Что это значит для нашего проекта

16. Файлы

Скрипты архива лежат в s0/calibrator/ без правок, там же протокол (RESEARCH_PROTOCOL_v1.0.md) и README с картой «скрипт → шаг». Из архива не взят только volatility_phase.py: он совпадает с s0/base/volatility_phase.py. dh_dynamics.py из архива новее копии в пакете 02.10 (окна 5/15/45, ширина в пунктах, выгрузка ряда), поэтому взят он.