jgrusewski c8c81ab7e4 feat(ml-alpha): Phase 2A-D B1.3 — adaptive gate LR controller
Replaces the fixed 5.0 bootstrap of slot 790 with a real adaptive
controller. ISV slot 790 is now driven by signal observation per
foxhunt-discipline ("no hardcoded constants that should be ISV-
driven"). The constant value remains the bootstrap; the controller
takes over once the signal observation begins.

## Mechanism

* 2 new ISV slots (793 total now):
  - 791 RL_POLICY_GATE_ENTROPY_EMA_INDEX (Wiener-α=0.02 on slot 781)
  - 792 RL_POLICY_GATE_CONTROLLER_BOOTSTRAP_DONE_INDEX (0→1 latch)
* New kernel rl_gate_lr_multiplier_controller.cu — single-thread
  launch (1,1,1)/(1,1,1) matching rl_surfer_scaffold_controller
  pattern. No atomicAdd.
* Control law (per pearl_bootstrap_must_respect_clamp_range +
  pearl_dead_signal_resurrection_discipline):
    if !boot_done: ema = entropy_now; boot_done = 1
    else: ema = (1-α)·ema + α·entropy_now
    over   = 0.85·log(K)   (~0.934 for K=3)
    collapse = 0.20·log(K) (~0.220 for K=3)
    if ema > over:     mult *= 1.003  (escalate +0.3%/step)
    elif ema < collapse: mult *= 0.95  (decay -5%/step, emergency)
    mult = clamp(mult, 1.0, 50.0)
* Per-step launch wired flag-gated AFTER MultiHeadPolicy::
  emit_diag_stats (writes slot 781) and BEFORE next-step host-side
  lr_gate = lr_pi * isv[790] read. Captured inside the flag-on
  CUDA graph; flag-off graph never includes the launch.
* Bootstrap: slot 790=5.0 (B1's empirically-validated starting
  point), 791=0.0 (overwritten on first observation), 792=0.0.
* Diag emit: 3 new fields gate_lr_multiplier, gate_entropy_ema,
  gate_controller_bootstrap_done — inside the existing flag-gated
  multi_head_policy JSON block (flag-off schema unchanged).

## Test results

* 17/17 multi_head_policy_invariants PASS (13 pre-existing + 4 new):
  - bootstrap_initializes_ema_to_first_observation
  - escalates_when_entropy_above_threshold (5.0 → 6.747 in 100
    steps; matches analytical 5·1.003^100 within ±0.1)
  - decays_when_entropy_below_collapse (5.0 → 1.0 in 100 steps,
    clamped to MIN_FLOOR)
  - clamps_at_min_floor_and_max_ceiling (50.0 ceiling, 1.0 floor,
    long-escalate 5.0 → 50.0 over 800 steps)
* Flag-off determinism: exit 0, byte-equal to pre-B1.3 modulo
  elapsed_s (0/200 non-elapsed_s diffs).
* Flag-on determinism: exit 0 (verified 3 consecutive runs).
  Note: one transient first-run FAIL surfaced during verification
  (mamba2_l2_out step 0 Δ≈4773) that disappeared after clean
  rebuild — same build-cache pattern documented in Phase 2A-C
  reports. Three confirmed clean post-rebuild.
* Pre-commit: 0 atomicAdd, 0 raw memcpy_htod/dtoh, 0 TODO.

## Single-seed seed-42 trajectory (b=128, 2000 train steps)

step   entropy_ema   multiplier   notes
   0   1.0986        5.015        bootstrap
 100   1.0972        6.75         escalating
 500   1.0967       22.36
1000   1.0944       50.00         hit MAX_CEIL
1500   1.0820       50.00
1999   1.0830       50.00         stuck at ceiling

Final gate_probs_mean = [0.253, 0.383, 0.365] — close to fixed 5×
endpoint [0.252, 0.382, 0.366]. The controller saturated at the
50× ceiling because entropy_ema never crossed below the 0.934
threshold — but the gate end-state matched 5× regardless. This
is the controller correctly diagnosing "no value of multiplier in
[1, 50] is sufficient to specialize the gate at b=128" — the
binding constraint is scale (signal/noise ratio), not LR. Cluster
b=1024 / 20k steps provides ~80× more gradient signal and is the
right next test.

## Linked

* Phase 2A-A: 0b3e40150
* Phase 2A-B: e22da61cf
* Phase 2A-C: 3e36f4a0e
* Phase 2A-C+: 5f10bcde3
* Phase 2A-D B1: 6f3639bfb (fixed 5.0 multiplier — now superseded
  by adaptive control built on this commit)
* Phase 2A-D B1.2: 20× test verdict — saturates at ~5×, motivated
  adaptive control rather than higher fixed multiplier

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-03 16:35:29 +02:00

Foxhunt

Production HFT trading system in Rust.

Architecture

The workspace contains 32 crates organized as follows:

Core Libraries (16)

Crate Purpose
trading_engine Order processing, FIX 4.4, IB TWS, SIMD, RDTSC timing
risk VaR, Kelly, circuit breakers, kill switches, compliance
risk-data Risk data types and shared structures
trading-data Trading data types
ml DQN Rainbow, PPO, TFT, Mamba2, ensemble inference
ml-data ML data types and feature definitions
data Market data ingestion and storage
backtesting Replay engine, strategy tester
adaptive-strategy Ensemble execution, microstructure analysis
common Shared types, resilience, error handling
storage S3 and local model storage
model_loader Model serialization and loading
market-data Market data feed handlers
database PostgreSQL access layer (SQLx)
config Configuration management
tli CLI commands and tooling

Services (8)

Service Purpose
backtesting_service gRPC backtesting service
broker_gateway_service FIX routing, broker connectivity
trading_service Core trading operations
ml_training_service Model training orchestration
data_acquisition_service Market data acquisition
trading_agent_service Autonomous trading agents
api_gateway gRPC API gateway with auth
web-gateway Axum REST + WebSocket gateway

Frontend

web-dashboard/ -- React 19 + TypeScript + Vite + TradingView charts.

Building

# Check compilation (no PostgreSQL required)
SQLX_OFFLINE=true cargo check --workspace

# Run tests for a specific crate
SQLX_OFFLINE=true cargo test -p <crate> --lib

# Clippy
SQLX_OFFLINE=true cargo clippy --workspace

ML Models

Four production model architectures on Candle v0.9.1 with CUDA:

  • DQN Rainbow -- Deep Q-Network with prioritized replay, dueling heads, noisy nets
  • PPO -- Proximal Policy Optimization with GAE and LSTM policies
  • TFT -- Temporal Fusion Transformer for multi-horizon forecasting
  • Mamba2 -- State space model for sequence prediction

Each model has a standalone trainer and a UnifiedTrainable adapter for the hyperopt pipeline.

Infrastructure

  • Git: Gitea at git.fxhnt.ai (Tailscale-only), Scaleway DEV1-S
  • Observability: OpenTelemetry OTLP (env OTEL_EXPORTER_OTLP_ENDPOINT)
  • Database: PostgreSQL with SQLx offline mode for CI

License

Proprietary. All rights reserved.

Description
No description provided
Readme 849 MiB
Languages
Rust 88.2%
Cuda 7.7%
Python 1.3%
Shell 1.1%
PLpgSQL 0.8%
Other 0.8%