How Trading System Blueprinter works

Principles the generator encodes

1. The LLM never sees market prices in the research step. The blueprint enforces a "price-blind research" boundary between the data layer and the LLM layer. LLMs that see prices retroactively rationalize positions.
2. Decisions are append-only. Every sizing decision, every trade, every thesis change is logged to memory/decisions.jsonl. Post-mortems are only possible with a complete audit trail.
3. Idempotent execution. The broker layer must accept a client-supplied idempotency key or deduplicate on order-id. Without this, retries cause duplicate fills.
4. Schedule is first-class. launchd/cron controls timing, not the script. This prevents "hot loops" that burn LLM tokens and API quota.
5. Heartbeat + watchdog. A heartbeat file written at every cycle lets an independent watchdog kill the pipeline if it hangs. Without it, silent failures cost real money.
6. Circuit breaker. A circuit.json state file with {paused: true} lets any layer halt the whole pipeline gracefully. Legal review triggers, drawdown breaches, or manual pauses all flow through one mechanism.

Why these specific categories

• Data source: must be picked independently of broker because most retail setups read from one and trade on another (e.g. Databento data + IBKR execution).
• Broker: determines execution latency, commission, and asset-class coverage — not substitutable with data-only providers.
• LLM layer: chosen separately from risk because LLMs produce probabilities, not positions; risk engine converts probability → sizing.
• Storage: separated from logging because storage holds state, logging holds events. Conflating them creates a bottleneck at log write.
• Risk engine: the only component that can refuse an order. Must live between LLM and broker.
• Logging + observability: informs humans; must not be in the trade path.
• Scheduler: the heartbeat of the whole system. Owns cadence.

Known limitations

1. Opinionated shortlist. Only a few options per category — reflects what retail operators actually use in 2026. Not an endorsement; not exhaustive.
2. No microstructure-aware execution. The blueprint assumes simple market-order execution. Strategies that need participation rates, VWAP, or aggressive routing need a dedicated execution layer beyond the generic "broker" block.
3. Python-first. The starter scaffold assumes Python; Rust/TypeScript equivalents are trivially derivable but not generated.
4. No tests for LLM-specific failure modes. Test list covers generic risk failures, not prompt injection, prompt drift, or context poisoning. The Prompt Regression Tester and Hallucination Detector are the companion tools for those.

Changelog

• 2026-04-20 — Initial release with 7 component categories, 4 options per category.