> ## 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.
# Strategy lifecycle: from idea to live trading
> Follow a strategy from Python prototype through Crucible backtesting and Foundry AI code generation to a signed, verified deployment on your execution node.
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
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.
```bash theme={null}
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.
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.
```bash theme={null}
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.
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`**
```json theme={null}
{
"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`.
```json theme={null}
{ "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`.
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`**
```json theme={null}
{
"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`.
```json theme={null}
{ "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.
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.
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.
```bash theme={null}
quanuxctl nest drop edge_nodes --engine spreader
```
Confirm the engine is live:
```bash theme={null}
systemctl status quanux-engine
```
## API reference summary
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.
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.