Live odds рождаются не в одном «калькуляторе коэффициентов». Система сначала строит состояние матча из событий, затем оценивает вероятность, после чего trading layer применяет продуктовые и риск-правила. Между этими этапами нужен явный контракт, иначе команда не сможет объяснить, почему цена изменилась.

Event state должен переживать corrections

Модель вероятности нельзя кормить только последним пришедшим сообщением. Счёт, игровое время, удаления и другие значимые факторы должны формироваться из подтверждённого и версионируемого состояния. При поздней correction требуется пересчёт зависимых рынков.

Вероятность и цена — не одно и то же

Модель выдаёт оценку вероятности. Торговый слой может преобразовать её в публикуемую цену с учётом маржи, лимитов, экспозиции и качества входного feed. Разделение этих слоёв важно для диагностики: сбой pricing rules не должен маскироваться как ошибка модели.

Suspend — защитное состояние, а не сбой интерфейса

После критичного события система может временно остановить рынок, пока не подтвердит новое состояние. Клиенту нужно передать этот статус явно. Попытка продолжать показывать старую цену ради визуальной непрерывности создаёт более опасную ошибку, чем краткая недоступность.

Replay-тест: прогнать сохранённый поток событий через state builder и pricing, добавить correction, пропуск и позднее сообщение, затем сравнить последовательность состояний. Такой прогон показывает, на каком шаге меняется состояние и как система ведёт себя при исправлениях, пропусках и поздних событиях.

Что связывать в трассировке

Для спорного изменения цены должны восстанавливаться входное событие, версия состояния матча, версия модели и сработавшее trading rule. Такая цепочка полезнее попытки объяснять live-pricing только графиком финальных коэффициентов.

Практический контекст

Где проходит граница между моделью и trading

Вероятностная модель отвечает за оценку, а торговый слой — за применение продуктовых правил, ограничений и реакции на качество данных. Если эти обязанности смешаны, изменение маржи или guardrail может выглядеть как «переобучение модели». Отдельные версии и журнал решений позволяют объяснить каждое изменение цены.

Контрольные вопросы

  • фиксировать версию event state и модели для каждого пересчёта
  • разделять модельную вероятность и публикуемый коэффициент
  • останавливать рынок при сомнительном входном состоянии
  • уметь воспроизвести расчёт по сохранённому потоку событий

Для пользователя главное — не внутреннее устройство движка, а корректное состояние. Краткий suspend после критичного события обычно безопаснее, чем показ цены, которую система уже не может подтвердить.

Manual override должен быть такой же версионной операцией

Ручное вмешательство полезно как защитный механизм, но опасно, если существует вне общего state model. Операторский override стоит записывать как отдельную версию с actor, reason, scope и сроком действия, а автоматический контур должен понимать, может ли он её перекрыть. Иначе модель через секунду «исправит» ручное решение или, наоборот, временный override останется навсегда. Для расследования важно видеть, какая именно версия правила определяла published price в конкретный момент.

Версия цены должна объяснять, почему она стала именно такой

В live-pricing недостаточно хранить последнее число. Для расследования полезно знать, на какой версии спортивного состояния была рассчитана вероятность, какая model version использовалась, какие trading rules применились и какой published version увидел downstream. Это не означает, что весь расчёт нужно дублировать в каждом логе. Достаточно устойчивых ссылок между слоями, позволяющих восстановить решение без приблизительного сопоставления по времени.

Операционный смысл этой линии становится заметен при работе с SLO для live odds. Если цена быстро рассчитана, но публикация запаздывает, модельный контур не виноват. Если же market ушёл в защитный suspend из-за сомнительной freshness, это тоже не обычный downtime. Разделение причин позволяет строить SLO вокруг пользовательского состояния, а не смешивать model latency, delivery latency и safety decisions в один процент.

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

Не менее важно наблюдать ручные вмешательства. Если оператор меняет market state или применяет override, система должна отличать это от автоматического пересчёта и сохранять причину изменения. Иначе последующая аналитика видит скачок цены, но не понимает, был ли он следствием новых данных, модели или ручного решения. Для regulated-контура такая различимость важна и для расследования, и для последующего review operational controls.

Для самых чувствительных рынков полезно отдельно хранить причину защитного состояния: feed stale, manual suspend, model unavailable, risk rule или scheduled stop. Пользователь снаружи видит один статус, но для эксплуатации эти причины принципиально разные. Они определяют, что разрешено восстановить автоматически, где нужен оператор и какие данные следует перепроверить до повторной публикации цены.