Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.quanux.org/llms.txt

Use this file to discover all available pages before exploring further.

A QuanuX strategy moves through a defined sequence of stages before it can run on a live execution node. You start in Python—where iteration is fast and the full data science ecosystem is available—then move through backtesting, AI-assisted C++ generation, and deterministic verification before deployment. No strategy can skip the final step: every binary that runs on the C++ core must carry a SHA-256 hash that matches a signed Git commit. This is not a policy you configure; it is enforced at the hardware level by the Sovereign Sentinel.

​
The full lifecycle

1

Prototype in Python

Write and iterate on your strategy logic in Python using the standard QuanuX Anaconda environment. The Anaconda channel (conda install quanux) provides tight package management and serves as the source of truth for dependencies. At this stage you have access to the full data science stack—NumPy, Pandas, PyTorch, and any other packages in your Conda environment.
conda config --add channels QuanuX
conda install quanux
Use the QuanuX Python API to connect your prototype to live or historical market data and validate your signal logic before investing time in compilation.
2

Backtest with Crucible

Once your prototype signal looks promising, run it through the Crucible backtesting engine. Crucible uses TSC-injection to feed the same C++ engine object code historical Databento L3 packet timestamps—the engine’s internal state machine replays sessions with zero behavioral drift from the live path.
quanuxctl crucible start my_strategy --version 1.0.0
Monitor progress with quanuxctl crucible status and pull the metrics report with quanuxctl crucible report my_strategy. Because the backtest and live engine share the same compiled code path, there is no sim-to-live drift in execution behavior.
Backtest results are written to the HDF5 Memory Vacuole (.h5 journal). You can analyze these files directly from Python using the Anaconda environment to validate your metrics before moving to the Forge.
3

Forge: AI-assisted C++ generation

The Foundry Forge translates your strategy intent into high-performance C++ (or Cython) via an AI generation pipeline. You describe the component you want—an indicator, entry logic, exit logic, or a complete strategy—and the Forge dispatches a job over NATS to the AI generation backend.POST /api/foundry/forge
{
  "component_type": "strategy",
  "name": "momentum_crossover",
  "target_lang": "cpp",
  "prompt": "EMA crossover with notional size capped at 5 contracts"
}
The API returns a job_id immediately. The generation runs asynchronously over the NATS subject sys.foundry.request.forge.
{ "status": "accepted", "job_id": "job_3a4f1c2e" }
The component_type field accepts: indicator, entry, exit, or strategy. The target_lang field accepts: python, cython, or cpp.
4

Verify mathematical equivalence

Before the generated C++ can be deployed, it must pass the Foundry’s deterministic sandbox—a mathematical equivalence test that confirms the compiled logic produces identical outputs to your Python prototype.POST /api/foundry/verify
{
  "strategy_name": "momentum_crossover"
}
Like the forge step, verification is asynchronous and returns a job_id. The sandbox publishes results over the NATS subject sys.foundry.request.verify.
{ "status": "accepted", "job_id": "job_9b2e7d1a" }
Do not skip this step. A strategy that passes verification has been proven mathematically equivalent to your Python prototype. One that fails verification has behavioral divergence that will appear as PnL drift in live trading.
5

Sign and commit (Git-as-Governance)

After verification passes, you commit the generated strategy to your repository with a GPG-signed commit. QuanuX extracts the SHA-256 hash of this commit and records it in the Forge audit log.No strategy binary can run on the C++ core unless its hash matches a record in this log. The Sovereign Sentinel enforces this at the hardware level: if invoke_hot_swap is called with a binary whose hash does not match a verified, signed commit, the Sentinel keeps the risk_interlock in STATE_HALT. There is no administrative bypass.This replaces traditional “who authorized this?” audit trails with mathematical certainty—the commit history is the authorization record.
6

Deploy to execution node

Once the commit is signed and recorded, deploy the strategy to your execution node using quanuxctl nest drop with the updated engine payload. The engine compiles natively on the edge node and the Sovereign Sentinel lifts the interlock once it confirms hash parity.
quanuxctl nest drop edge_nodes --engine spreader
Confirm the engine is live:
systemctl status quanux-engine

​
API reference summary

POST /api/foundry/forge

Initiates AI code generation for a strategy component. Accepts component_type, name, target_lang, and an optional natural-language prompt. Returns a job_id for tracking the async job over NATS.

POST /api/foundry/verify

Triggers the deterministic sandbox to verify mathematical equivalence between the generated C++ and the Python prototype. Accepts strategy_name. Returns a job_id for tracking the async verification job.
The legacy POST /api/strategy/generate endpoint is deprecated. All strategy generation goes through the Foundry endpoints described above.