Shannon, catalog и inventory

Этот слой нужен, чтобы не потерять важную часть истории Китобоя: мы не только слушали Decima и смотрели фазу. Мы еще применяли информационный отбор сенсоров и строили инвентарь решений.

Коротко:

Shannon mining = найти структуры, где есть информация о будущем ходе
sensor catalog = классифицировать сенсоры как trade/watch/context/disable
catalog director = проверить, что будет, если торговать только разрешенные сенсоры
trade inventory = превратить решения директора в dry-run ордерный журнал

Зачем был нужен Shannon

Decima может услышать много pattern ids. Но не каждый pattern id имеет торговый смысл.

Shannon-линия отвечала на другой вопрос:

несет ли этот сенсор информацию,
или он просто красиво срабатывает на шуме?

В whaler_shannon_tree_specs.py майнер ищет структуры tape, которые отличаются от baseline по будущим исходам. Для этого используются:

  • будущий return по горизонту;
  • edge после комиссии;
  • win lift относительно baseline;
  • KL bits как мера информационного отличия win distribution от baseline.

Это не директор. Это исследовательский фильтр качества сенсора.

Инструменты

Главные файлы:

store/market/tools/whaler_shannon_tree_specs.py
store/market/tools/whaler_shannon_tree_walkforward.py
store/market/tools/whaler_shannon_survivors.py
store/market/tools/whaler_sensor_catalog.py
store/market/tools/whaler_catalog_director.py
store/market/tools/whaler_trade_inventory.py

Роли:

whaler_shannon_tree_specs.py       -> майнит specs по Shannon/edge
whaler_shannon_tree_walkforward.py -> прогоняет mining по train/test шагам
whaler_shannon_survivors.py        -> ищет выжившие signatures
whaler_sensor_catalog.py           -> строит catalog с OOS-статусами
whaler_catalog_director.py         -> paper-директор только по catalog-сенсорам
whaler_trade_inventory.py          -> dry-run inventory/order journal

Sensor catalog

Catalog - это память о сенсорах.

Он не просто говорит "сигнал хороший". Он раскладывает сенсоры по статусам:

trade    = можно проверять как торговый сенсор
watch    = лучший горизонт выглядит торгуемым, но есть токсичность по фазе/горизонту
context  = информация есть, но как сделка слабый
disable  = OOS слабый или токсичный

Пример из v30:

store/market/runs/v30_shannon_tree_wide_train_jan_apr_test_may/sensor_catalog.json

days=30
sensors=256
families=79
trade=11
watch=1
context=43
disable=201
min_trade_count=15
trade_edge_bps=6.0
trade_win_lift=0.04

Это важная дисциплина: большинство найденных структур не получают право быть торговым входом.

Catalog director

whaler_catalog_director.py проверяет, что будет, если брать только сенсоры из catalog.

Пример v30 на Jan-Apr train / May test:

catalog_sensors=5
events=252
trades=170
return=+2.25%
win=77.65%
profit_factor=1.405

Это было полезно: win rate высокий, но trade count большой и edge слабее текущей v42-фазовой схемы.

Что осталось в v42

В v42 all-history есть internal catalog:

store/market/runs/v42_mtf_s300_short_wide_all_history_2026-01-01_2026-05-30/internal_catalog_short_all_history.json

Он содержит 26 trade-сенсоров. Это и есть восстановленный слой "фильтра Шеннона к сигналам" в текущем дереве артефактов.

Связанный catalog director:

store/market/runs/v42_mtf_s300_short_wide_all_history_2026-01-01_2026-05-30/director_short_s300_all_history.json

Сводка:

frames=43200
events=154
catalog_sensors=26
trades=106
return=-0.29%
win=59.43%
profit_factor=0.988
fee=4 bps
entry_exposure=0.5
position_mode=short-only

Это не провал слоя. Это говорит, что один catalog-only director не дал достаточного итогового edge на all-history. Зато он подтвердил, какие сенсоры вообще стоит рассматривать, и дал инвентарь событий/сделок для анализа.

Почему s1800 стал важнее для live

Сильный v42-кандидат появился не от catalog-only торговли, а от связки:

s300 Decima event
  + s1800 phase
  + same-side policy
  + fee-aware inventory

На том же all-history прогоне same_side_matrix показал:

close-if-profit:
  signals=150
  trades=64
  return=+34.14%
  win=67.19%
  profit_factor=2.324
  max_drawdown=10.88%

keep:
  signals=150
  trades=37
  return=+38.56%
  win=48.65%
  profit_factor=3.262
  max_drawdown=11.88%

reopen:
  signals=150
  trades=150
  return=+33.40%
  win=52.0%
  profit_factor=1.584
  max_drawdown=13.50%

Поэтому текущая база:

не catalog-only,
а s300 event + s1800 phase + stateful director

Но catalog/Shannon остается важным upstream-слоем. Его нельзя выкидывать из архитектурной памяти.

Inventory

Inventory - это мост от решений к исполнению.

whaler_trade_inventory.py делает безопасный dry-run слой:

director.json
  -> inventory_state.json
  -> orders.jsonl
  -> inventory.html

Он учитывает:

  • equity;
  • открытую позицию;
  • entry price;
  • exposure;
  • qty;
  • realized pnl;
  • trades;
  • wins;
  • processed decision keys;
  • dry-run order intents.

Ключевой принцип:

директор принимает решение
inventory ведет состояние
order executor исполняет на бирже

Эти роли нельзя смешивать. Для боевого VPS это особенно важно: inventory должен сверяться с биржей, а executor должен уметь не торговать, если состояние расходится.

Правильная роль слоя

Shannon/catalog/inventory в v42 надо понимать так:

Shannon/catalog = доказательная память сенсоров
s1800 phase     = текущий главный контекст входа/выхода
director        = stateful торговая интерпретация
inventory       = учет и будущий мост к ордерам

То есть Shannon-фильтр не отменен. Он просто не является финальным live-директором в текущей базе.