3fc67ab9babd125c52b759ece8c33eb6e4a5b8f8
Per the directive "no follow ups include in spec", expanded the
Phase 3 design to include three previously-out-of-scope items:
1. β as a separate 7th reward component (not added to r_trail)
────────────────────────────────────────────────────────────
Contract change from `reward_components_per_sample[6]` →
`reward_components_per_sample[7]`. Migrated atomically per
`feedback_no_partial_refactor` across every consumer:
- experience_kernels.cu (producer site at segment_complete)
- reward_component_ema_kernel.cu (iterate 0..7)
- reward_decomp_diag_kernel.cu (emit column 6)
- reward_component_mag_ratio_compute_kernel.cu (axis 6)
- reward_subsystem_controller_kernel.cu (7-weight output)
- gpu_experience_collector.rs + gpu_dqn_trainer.rs (buffer alloc
+ HEALTH_DIAG print format)
- reward_component_monitor.rs (7-component EMA reader)
- health_diag_kernel.cu (snap layout)
- training_loop.rs (sp11_reward + reward_split lines)
New ISV slot REWARD_AUX_ALIGN_EMA_INDEX for the component EMA.
2. SP11 controller emits scale_β adaptively
─────────────────────────────────────────
New ISV slot `SP22_AUX_ALIGN_SCALE_INDEX`. Producer:
reward_subsystem_controller_kernel extended to 7 weight outputs.
Anchor: REWARD_AUX_ALIGN_EMA_INDEX. Target: ~10% of total reward
magnitude. Bounds [0.05, 2.0]. Cold-start sentinel 0 per
`pearl_first_observation_bootstrap` — β no-op until first emit.
state_reset_registry registers both slots as FoldReset category.
3. Encoder-state[121] gradient routing — DECISION committed
─────────────────────────────────────────────────────────
Option (i) — both paths open. `dbatch_states[121] +=` flows
gradient into both α's W and the encoder's column for slot 121.
Long-term robust: encoder may eventually learn additively (belt
+ suspenders). Empirical observable: compare W magnitudes vs
encoder column-norm for state[121] in post-smoke telemetry.
Explicitly OUT of scope (with reasoning, not deferral)
──────────────────────────────────────────────────────
A2 (eval-side α + β + aux trunk forward at eval): the same
architectural deferral logic from H6 Phase 1. Adding aux
infrastructure to GpuBacktestEvaluator should follow positive
training-side evidence rather than precede it. A3 NULL-fallback at
eval makes both α and β no-ops at eval-time, isolating the verdict
to training-side. Becomes a separate spec if Phase 3 confirms.
Scope estimate updated
──────────────────────
~21–31 hr engineering (roughly 3-4 working days) — up from the
earlier "~10–16 hr" YAGNI estimate. The bulk of the addition is the
7-component contract migration touching ~8 kernel/source files
atomically and the SP11 controller extension.
Verification gates expanded
───────────────────────────
6. **7-component contract sanity** (smoke cycle 1): HEALTH_DIAG
sp11_reward shows 7 weights including w_aux; reward_split shows 7
components including aux_align; both non-zero within the first
epoch after the SP11 controller's first emit. If still zero,
either the controller emit is broken OR the β producer isn't
firing.
Refs
────
- pearl_no_deferrals_for_complementary_fixes (combined plan)
- pearl_no_partial_refactor (7-component atomic contract)
- pearl_controller_anchors_isv_driven (SP11 scale_β anchor)
- pearl_first_observation_bootstrap (cold-start sentinel 0)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…
…
…
…
…
…
…
…
…
…
…
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
Languages
Rust
88.2%
Cuda
7.7%
Python
1.3%
Shell
1.1%
PLpgSQL
0.8%
Other
0.8%