Designing for Novelty

The natural tendency of an LLM given market data is to produce safe, consensus analysis. “BTC is in an uptrend. Support at X.” This is worthless. If it is obvious to the model, it is obvious to everyone, and it is already in the price.

The discovery prompt is structured to explicitly counteract this tendency:

• Mandate to disagree. Each model is told that contradicting the other models is rewarded, not punished. Agreement scores nothing. A unique finding that turns out to be correct is the highest-value output.
• Cross-tradition thinking. “What would a commodities trader notice? A quantitative researcher? An options market maker? Set aside the existing framework and look with fresh eyes.”
• Concrete requirements. Every hypothesis must include a precise entry signal, a precise exit signal, the mechanical reason it should work, and historical examples the model can point to in the data.
• Leaderboard context. Each model sees the current standings and knows that safe, consensus observations score zero. The incentive structure rewards originality.

From Unstructured Wisdom to Testable Rules

A profitable trader explains their approach in a two-hour video. The methodology is real, but it is buried in context, examples, and narrative. The challenge is converting this unstructured explanation into precise, mechanical rules that a backtesting engine can evaluate.

The pipeline:

1. Automated transcript extraction — Headless browser automation retrieves full transcripts from video content
2. Rule parsing via LLM — A model extracts: instruments traded, timeframes, session preferences, entry conditions, exit conditions, and filters
3. Ambiguity handling — When the source is ambiguous, produce ranked candidate interpretations rather than guessing. The distinct element between two interpretations might be the edge.
4. Hypothesis registration — Parsed rules enter the hypothesis registry for automated testing

What the Registry Tracks

For each hypothesis, the registry maintains:

• The rules — Precise entry conditions, exit conditions, timeframes, and target markets
• Provenance — Which model proposed it, when, based on what data
• Multi-model confidence — Each model’s assessment, updated after every ensemble session. Not averaged — preserved individually so disagreements are visible.
• Performance history — Paper and live results: trade count, win rate, expected value, risk-adjusted return, confidence intervals. Broken down by market regime.
• Lifecycle status — Where the hypothesis sits in the lifecycle (observing, paper trading, live eligible, live, suspended, killed)
• Kill reason — If dead, why. What the data showed. What the failure conditions were.

The Anti-Pattern Library

After every losing trade, the system runs loss attribution: what data was available at the time of entry that, in hindsight, predicted the loss? These failure conditions are recorded per hypothesis, building a growing library of anti-patterns.

Over time, this library becomes as valuable as the strategy rules themselves. The system does not just learn what works — it learns what doesn’t work, and under which conditions. This is the other half of intelligence that most systems ignore entirely.

Two Paths, One Goal

When both paths test the same hypothesis, the results can be compared. If they agree, confidence increases. If they disagree, the discrepancy reveals either a bug in the generated code or a limitation in the building blocks — both are valuable information.

The natural temptation is to pick a strategy you believe in and test it on the instrument you are most familiar with. This introduces selection bias before you have any data. The better approach: test dozens of strategies across dozens of instruments and let the results determine where to focus.

When you run a strategy across many instruments simultaneously, patterns emerge that you would never see in a single-instrument test:

• Some strategies work on an entire asset class but fail on another
• Some instruments support multiple strategy types; others support none
• The best instrument for a given strategy is often not the one you would have guessed

Breadth first, depth on the survivors. Let the matrix of results guide your focus.

Why Single-Timeframe Fails

Most published strategies operate on one timeframe. “When RSI crosses below 30 on the daily chart, buy.” This produces a testable signal, but it only fires when conditions align on that one timeframe. The resulting trade count is often too low for statistical validation, and the strategy misses setups that are valid on adjacent timeframes.

The Multi-Timeframe State Machine

Profitable traders do not operate on one timeframe. They maintain a mental model across multiple timeframes simultaneously (as described in Module 0’s five-layer model). The multi-timeframe architecture replicates this:

• Higher timeframes establish bias and context (trend direction, key levels, regime)
• Medium timeframes identify setups (pullbacks, pattern formations, zone entries)
• Lower timeframes provide entry triggers and exit management

When all three layers align, a trade fires. When they don’t, the system waits. This produces dramatically more trades than single-timeframe approaches because the alignment can occur across many different timeframe combinations.

This finding was counterintuitive. We expected strategy quality to be the primary driver of results. Instead, the cost-to-move ratio (introduced in Module 1.3) dominates. A strategy that is marginally positive on a high-cost instrument becomes clearly profitable on a low-cost one — and vice versa.

The implication: choose your instruments first, then find strategies that work on them. Most people do it the other way around — they develop a strategy and then look for an instrument to trade it on. This is backwards. The instrument determines the cost environment; the cost environment determines which edges can survive.

When the system first started producing results, the kill rate was discouraging. The vast majority of proposed hypotheses — whether from LLM discovery, video transcript extraction, or seeded ideas — failed the verification harness. Some failed spectacularly. Some failed boringly. A few showed promise and then died in walk-forward testing.

This is exactly what should happen. A system where most ideas survive is not rigorous enough. The academic literature on quantitative strategy research consistently shows that the base rate for genuine, tradeable alpha from systematic testing is low — somewhere around one in ten proposals at best.

The kill reasons are themselves informative:

• Some edges are structurally fragile — they depend on a single market condition that may not recur
• Some produce phantom edges from directional bias — they look profitable because the underlying asset went up during the test period, not because the entry logic was correct
• Some die on costs — the edge is real but too small to survive transaction costs on the available instruments
• Some are overfitted — they work beautifully in-sample and fail immediately out-of-sample

Generalized Failure Patterns

The scoring system rewards two things above all else: finding unique edges and correctly identifying when an edge is degrading. Both are hard. Both are valuable.

• A hypothesis that clears the statistical gate earns points. A hypothesis that goes live and remains profitable earns more.
• A degradation flag raised before a strategy starts losing money earns significant points. This is harder than finding a new edge — it requires seeing the early signs of decay.
• A contradiction that is later proven correct earns points. Being a contrarian who turns out to be right is the highest-skill output.
• Noise is mildly penalized. Wrong contrarianism is significantly penalized. This prevents models from gaming the system with volume or reflexive disagreement.

The incentive structure is asymmetric by design: the reward for being uniquely right is much larger than the penalty for being uniquely wrong. This encourages risk-taking in hypothesis generation, which is where the value is.

Every model expresses confidence ratings on hypotheses and market assessments. The system tracks these ratings against actual outcomes, building a rolling calibration profile for each model:

• When Model A says “high confidence” on macro calls, is it right more often than when it says “medium”?
• Is Model B well-calibrated on crypto but consistently overconfident on FX?
• Does Model C’s accuracy vary by regime — sharp in trending markets, unreliable in ranges?

Over time, these calibration profiles become a weighting function. When the system needs a quick consultation during a live signal — “should we take this trade?” — it knows which model to ask based on the asset class, market regime, and historical calibration.

This is a compounding advantage. A new system with the same models starts with equal weighting. A system with months of calibration data knows who to trust about what.

Why Order Matters

In a parallel ensemble, each model sees the same input and produces independent output. The outputs are then combined. This produces four independent views, which is useful but misses the value of interaction.

In a sequential ensemble, each model sees the data and what previous models said about it. This changes the dynamic entirely:

• The second model can agree, disagree, or build on the first model’s analysis
• The third model sees two prior perspectives and can identify where they agree, where they conflict, and what both missed
• The orchestrator sees all prior analysis and synthesizes — resolving conflicts, flagging unresolved disagreements, and determining what is actionable

This mimics how a well-run investment team works: analyst presents, second analyst challenges, macro strategist provides context, portfolio manager synthesizes and decides.

Mandatory Disagreement

Each model is required to produce two mandatory sections in every analysis: explicit contradictions of other models’ claims, and degradation flags for strategies the model believes are losing their edge. These sections cannot be omitted. Saying “I agree with everything” is technically possible but scores zero.

Any system that accumulates knowledge develops anchoring. The models learn the existing framework, the current hypotheses, and the historical patterns. This is valuable — but it can also create blind spots. The models start seeing what they expect to see.

The fresh eyes session counteracts this. A model given raw data with no context is forced to analyze from first principles. It cannot anchor on existing hypotheses because it does not know they exist. It cannot conform to the current framework because it has not seen it.

The most valuable output from fresh eyes sessions is often not a new hypothesis — it is a challenge to an existing assumption. “Why are you treating this as a mean-reverting market? The data suggests a regime change that your framework has not recognized.”

The Kelly Criterion

The Kelly criterion provides the mathematically optimal fraction of your bankroll to risk on each bet, given your edge and odds. In its simplest form:

f* = (p × b − q) / b

Where p is win probability, q is loss probability (1 − p), and b is the ratio of average win to average loss. ATLAS uses a conservative fraction of the Kelly amount — typically half — because full Kelly produces equity curves with drawdowns that are psychologically and practically unsustainable.

What Drives Sizing

Position size in ATLAS is not fixed. It is determined by:

• Statistical confidence in the edge. A hypothesis with a narrow confidence interval and many trades gets sized larger than one with a wide interval and few trades.
• Current portfolio exposure. Before any trade, the system checks aggregate directional exposure. If multiple strategies are all pointing the same direction on correlated instruments, that is one concentrated bet, not diversification. Sizing is reduced when exposure is concentrated.

Why Exchange-Side Orders Are Non-Negotiable

A stop-loss managed by your software (“if price reaches X, send a market sell order”) fails when your software is not running. A stop-loss placed as an exchange-side order (“the exchange will close this position at X regardless of whether my bot is connected”) works even if your entire infrastructure is offline.

The same applies to take-profit targets. Both must be exchange-side orders, placed immediately upon entry, and confirmed by the exchange. Software-side risk management is a supplement, not a replacement.

Mark Price vs Last Price

Exchanges offer two trigger types for stop-loss orders:

• Last price: Triggers based on the most recent trade on this exchange. Can be manipulated by a single large order creating a wick.
• Mark price: Triggers based on a composite price derived from multiple exchanges. Much harder to manipulate, but may not reflect the actual price on your specific venue during extreme conditions.

Exchanges use mark price for liquidation calculations specifically to prevent manipulation. Your stop-loss trigger type should be a deliberate decision based on the instrument and venue, not a default you never examined.

Why Paper Trading Is Mandatory

Backtests run on historical data with a simulated broker. Paper trading runs on live data with simulated execution. The difference is critical:

• Data ingestion bugs only appear with live data (delayed feeds, format changes, connection drops)
• Signal timing issues only appear in real time (race conditions, stale cache, timezone confusion)
• Exit logic edge cases only appear in production (session boundaries, overnight holds, holiday schedules)

Paper trading finds these bugs at zero cost. Skipping paper trading finds them with real money.

The Graduation Gate

Strategies graduate from paper to live when they meet statistical gates that require evidence, not intuition:

• Sufficient trade count for meaningful confidence intervals
• Paper performance consistent with backtest expectations (within a tolerance band)
• Robustness across the market regimes encountered during paper trading
• Explicit human approval as the final gate

The human gate is deliberate. The system can identify candidates autonomously, but deploying real capital is a decision with consequences that justify human confirmation — at least until the system has built a sufficient track record to justify full autonomy.

Why Auto-Suspend Fails

Many automated systems include a rule: “if a strategy loses N trades in a row, suspend it.” This sounds prudent. It is actually destructive for a large class of validated strategies.

Many profitable trading approaches have low win rates — sometimes well below 50%. They are profitable because their winning trades are significantly larger than their losing trades. A strategy with a 30% win rate and 3:1 reward-to-risk will routinely produce five, seven, even ten consecutive losses as normal operation. Auto-suspending after five losses guarantees you will always cut the strategy before its next large winner arrives.

What Does Get Stopped

While losing streaks don’t trigger suspension, some conditions do warrant automatic intervention:

• System malfunction — Zero trades generated, execution errors, data feed failures. These are infrastructure problems, not strategy problems.
• Account-level circuit breaker — If the total account drawdown exceeds a hard threshold, all trading pauses and the operator is alerted. This is a catastrophic-event safety net, not a strategy management tool.

Why Containers

• Fault isolation. A crash in the monitoring stack does not take down the trading engine. A database restart does not crash the application — the application reconnects.
• Reproducible environments. The exact same environment runs in development, testing, and production. No “works on my machine” surprises.
• Resource limits. Each service has explicit CPU and memory constraints. A runaway backtest cannot starve the live trading engine of resources.
• Independent updates. You can update the monitoring dashboard without restarting the trading engine. Database upgrades do not require rebuilding the application.

Key Design Choices

• Shared data layer. All services read from the same time-series database. This prevents data divergence — there is one source of truth for candles, trades, and hypotheses.
• Health checks. Services wait for their dependencies to be healthy before starting. The application does not launch until the database is accepting connections.
• Persistent volumes. Database data and cache state survive container restarts. A docker restart does not lose your trade history.

The Subtle Bugs

The most dangerous data bugs are not crashes or connection failures — those are loud and obvious. The dangerous ones are silent:

• A feed fails silently — The connection stays open but no new data arrives. Strategies scan stale candles and may generate signals based on outdated information.
• A schema conflict — An internal naming collision causes the database layer to reject writes without raising an obvious error. The application runs normally but no new data is stored.
• A backfill gap — The pagination logic miscounts or skips a page, leaving a hole in the historical data. Indicators calculated across the gap produce incorrect values.

Each of these has happened. Each was fixed. The lesson is always the same: your ingestion layer needs active health monitoring that measures data freshness, not just connection status.

Dual Persistence

• Fast cache for real-time state: current scanner positions, pending signal evaluations, session tracking. This needs to be fast (milliseconds), small (kilobytes), and expendable (can be rebuilt from durable state if lost).
• Durable database for everything else: candle data, trade records, hypothesis registry, model logs. This is the system of record. It must survive container restarts, server reboots, and disk failures.

The cache is configured for persistence across normal restarts. If the cache is lost (rare), the system rebuilds it from the database on startup. This means a clean restart recovers the exact state from before shutdown, with a brief warm-up period.

The Operator’s Daily Touchpoint

ATLAS produces a daily briefing delivered to the operator’s messaging platform. It contains:

• Current open positions and their P&L
• Top signals from the most recent ensemble session
• Any conflicts between models that remain unresolved
• Strategies pending approval for status changes
• System health: data freshness, service status

The briefing is designed to be readable on a phone in under two minutes. The operator does not need to log into dashboards or read logs during normal operation. If something requires attention, the briefing tells them.

What Gets Measured

• Data freshness per source — How old is the most recent candle from each feed?
• Service uptime — Are all containers running and healthy?
• Strategy performance vs expectations — Is each strategy tracking within tolerance of its backtest expectations?
• Model output quality — Are the models producing structured, parseable output? (LLMs can degrade in subtle ways.)

After every losing trade, the system examines the state at the time of entry and asks: what was different about this trade compared to the winners? Was there a regime signal the strategy did not check? A session condition that correlates with losses? A cross-asset indicator that was flashing a warning?

The answers accumulate into an anti-pattern library for each hypothesis. Over time, the library becomes a precision filter: the system knows not just when to trade, but when not to trade — and the “when not to” conditions are derived from real losses, not theoretical edge cases.

This is the other half of intelligence. Pattern discovery finds what works. Loss attribution finds what kills. A system that does both improves twice as fast as one that only does pattern discovery.

Individual strategies have their own performance profiles. But the aggregate system — all strategies running together — may exhibit patterns that transcend any single strategy:

• Does the system perform better in the first week after deploying a new strategy? (novelty advantage before the market adapts?)
• Does aggregate performance correlate with macro variables that no individual strategy explicitly tracks?
• Are there time-of-day or day-of-week effects in system-level performance that don’t appear at the strategy level?

The meta-strategy layer treats these questions as hypotheses and tests them with the same rigor applied to any trading idea. If a system-level pattern is real, it becomes a portfolio-level overlay: adjust total exposure based on conditions that predict system-wide performance.

Calibration data accumulates with every ensemble session and every resolved prediction. Over time, distinct profiles emerge:

• One model may be consistently well-calibrated on certain asset classes but overconfident on others
• Another may have poor overall accuracy but excellent timing on regime-change calls
• A third may be the most reliable during high-volatility periods but add noise during quiet markets

These profiles are not static — they evolve as models are updated and as markets change. The system continuously recalculates calibration scores on a rolling basis, ensuring that the weighting reflects current, not historical, reliability.

This is fundamentally different from fixed model weighting. A system with fixed weights cannot adapt. A system with calibration-derived weights improves its judgment automatically as evidence accumulates.

Consider what ATLAS accumulates over six months of operation:

• Market state embeddings with known outcomes for every candle close across every market
• Calibration profiles for each model, broken down by asset class and regime
• Anti-pattern conditions derived from every losing trade
• A hypothesis graveyard with detailed kill reasons for every failed idea
• Model disagreement resolution data showing who was right about what, and when

A competitor can copy the architecture. They can use the same models, the same graph structure, the same verification harness. But they start with an empty memory, uncalibrated models, no anti-pattern library, and no disagreement history. They are six months behind on day one, and the gap widens every day.