how q7 aegis ai works.

Q7 AEGIS AI is the production trading system built and operated by Quant7 Alpha. The team is a small, deliberate group of Wall Street operators — quantitative researchers, economists, former US regulators, and Big Four consultants — drawn from the largest global financial institutions and hedge funds. Each member has spent a career inside the kind of organization where a single error in a risk model becomes a regulatory event, and that experience is the source of every design decision in the system you are reading about.

The system was not built to look impressive in a backtest. It was built to operate the way the team's previous employers operated: with calibrated parameters rather than hand-tuned ones, with documented controls rather than ad-hoc overrides, with risk units that survive leverage changes, and with an audit trail dense enough that any trade can be reconstructed and any loss explained. What retail platforms call "advanced features" Quant7 Alpha calls table stakes.

Quant7 Alpha operates Q7 AEGIS AI under the Seven Principles of a Hedge Fund Framework — the institutional discipline that separates fiduciary capital management from retail signal services. Each principle is implemented somewhere concrete in the system; none of them is a slogan.

1. 1. Testable Investment Thesis. Non-ambiguous hypothesis validated by data. Per-engine defined market-condition exploitation.
2. 2. Robust Risk Management. Multi-layer risk stack. ELU cap. Circuit breakers. Rolling halts. LIQ_GUARD. Regime suppression.
3. 3. Structured, Repeatable Process. 100% rule-based. Same data = same trades. RX cycle governance. Version-controlled.
4. 4. Sophisticated Execution. 4-leg adaptive exits. MFE ratchets. Vol-adaptive TP. Per-engine allocation. Keltner trailing.
5. 5. Continuous R&D. Quarterly machine learning retraining. Warm-start optimization. Λ-Vol research integration. Alpha-decay awareness.
6. 6. Rigorous Attribution. 20-point defect scan. FX-tagged changes. Trade-level engine-tagged attribution.
7. 7. Operational Excellence. Institutional MRM executed by a multi-agent system. SR 11-7 aligned (fit-for-purpose); agentic AI governed and auditable by design.

The framework is not a marketing layer. It is the precondition for the architecture being publishable to outside capital. Every section that follows describes how one or more of these seven principles is enforced in code.

Q7 AEGIS AI does not pick stocks. It does not predict price. It is a systematic decision pipeline — a sequence of independent engines, each looking for one specific kind of opportunity, gated by a hybrid AI overlay that votes on every trade before the system commits capital. The result is not a strategy. It is a portfolio of strategies, each running in parallel across four assets and four timeframes, all adjudicated by the same risk substrate.

Six of these strategies exist today. Each one covers a different market: digital-asset perpetuals, US index micro-futures, commodity micro-futures, commodity spot CFDs, bond yield-curve spreads, and FX futures. Every one of them has been validated through the same 16-of-16 calibration gate. None of them ships until they all pass.

The architecture you will read about below — the engines, the exit ladder, the risk units, the agent loop — is the same architecture under all six. What changes between strategies is the market, the data, and the per-configuration parameters the calibration pipeline finds. The framework does not.

Q7 does not have one strategy. It runs four pattern engines side-by-side, each hunting a different kind of market behavior. On every bar, every engine emits an independent long/short opinion. A selector layer ranks them by historical edge in the current regime and picks the engine with the strongest case. The other three sit out the bar.

• TRND — Trend. Pullback entries inside confirmed trends. The engine waits for the EMA stack to align, ADX to confirm trending strength, and price to retrace into dynamic support before firing. It is patient in its setup and assertive in its sizing. TRND is the workhorse engine in directional markets.
• BRK — Breakout. Compression-then-thrust. The engine identifies tight Bollinger-band consolidation in the bottom percentiles of its rolling distribution, then triggers on the first decisive close beyond a 30-bar range with a volume confirmation. BRK is the engine that pays during regime transitions.
• MR — Mean Reversion. Fade extreme extensions in non-trending markets. The engine requires low ADX (range conditions), an exhausted RSI reading, and a pin-bar wick at a Bollinger band — the classic confluence of "this move is too far, too fast." MR earns its keep in chop and weekend sessions.
• SWP — Sweep. Reversals after stop-hunting. The engine watches for liquidity sweeps of obvious levels — prior highs, prior lows, session opens — followed by an immediate reclaim inside one to three bars. The thesis: the sweep was manufactured, the reversal is the real move. SWP fires rarely but cleanly.

The selector itself is not a black box. It scores each engine's trade by recent expected value, weights by configuration-specific gating, and applies directional confluence adjustments that raise the bar for whichever side of the market is structurally weaker for that asset/timeframe. Trending markets get TRND. Compressed markets get BRK. Ranging markets get MR. Post-sweep markets get SWP. The market chooses the engine; the engine does not choose the market.

Crypto perpetuals (S1) ship with a fifth engine that the other strategies do not need: BTC_MOM. It is a pullback-continuation engine that hunts a very specific pattern — modest volatility, moderate ATR, EMA pullback, RSI in the mid-range, higher-timeframe alignment, and ADX trending. It also incorporates a cross-asset cascade signal: when BTC moves materially in five minutes and an altcoin hasn't caught up, the catch-up trade fires.

BTC_MOM is additive, not a replacement. It runs at the lowest priority in the engine selector — the four core engines fire first when their trades are clean. BTC_MOM catches the residual cases where price is moving with conviction but no other engine has aligned. In production it delivers material lift on BTC and on altcoins that lag BTC's lead.

Why not put BTC_MOM in the other strategies? Because the pattern it hunts is specific to crypto's lead-lag structure. Bond spreads, FX futures, and commodity micros do not have a "BTC" — they have their own dominant reference assets, and the cross-asset cascade has to be modeled per-market. When the calibration pipeline finds an analogous primitive in another asset class, it will get its own engine. Until then, the four core engines plus BTC_MOM is the production configuration.

Every Q7 trade opens as four independent positions, not one. Each leg has its own take-profit target, its own stop, and its own life. When leg 1 hits its target and closes, legs 2 through 4 keep running with progressively wider stops and progressively further targets. When leg 1 stops out, only leg 1 closes — the rest keep hunting.

This eliminates what the founder calls the single-stop-kills-everything problem. A conventional one-stop trade either takes the small win, the small loss, or the catastrophic gap. A four-leg trade scales out into strength, lets the runner ride, and bleeds out small partial losses on losing trades. The math compounds in the system's favor over thousands of trades.

Each engine has its own leg allocation profile, calibrated per cycle. TRND legs the trade differently from MR, which legs differently from SWP. The principle is universal: the larger fraction of the position closes early at a tight profit target, and a smaller fraction stays in for the outlier capture. The exact percentages are a calibration output — the architecture does not pick them; the optimization process does.

Risk at Q7 is a closed loop. The input sidedecides every trade's position size and exit parameters from real-time conviction. The output sideaccumulates trade outcomes into halt-eligible units that trip literal trigger counts. Both ends use the same risk unit, the ELU. The system sizes itself by present conviction and halts itself by past damage.

Input — live order flow drives sizing and exit geometry. Every candidate trade is scored by a live Order Flow validator. The validator consumes book depth, tape aggression, queue imbalance, large-print activity, and microstructure features into a single 0–100 conviction score (the OF score). Below 50 the trade is blocked outright — the system refuses to enter conditions where the order flow does not support the thesis. Above 50 the score becomes the formula-driven input to the rest of the risk architecture.

The OF score does three things, in deterministic order:

1. 1. Confidence-based leverage. The score is mapped to an effective leverage by a closed-form rule: effective leverage scales linearly between a floor of 25× and the per-asset cap as OF rises from 50 to 100. A BTC trade with OF=85 takes more leverage than the same BTC trade with OF=55. A SOL trade with OF=85 takes the SOL-cap-adjusted version of the same scaling. No discretion, no override.
2. 2. Risk-parity position sizing. The leverage and the asset's volatility regime multiplier feed into a risk-parity sizing rule that normalizes every trade to roughly equal expected ELU risk. A volatile-asset trade gets a smaller notional than a stable-asset trade for the same leverage; an unusually wide ATR shrinks the position; an unusually tight ATR enlarges it. The objective is constant risk per trade, not constant notional.
3. 3. Exit-system parameterization. The same OF score and the leverage it produced flow into the four-leg exit ladder. TP distances scale with conviction (high OF widens the runner; low OF tightens leg 1). The MFE ratchet thresholds shift with conviction (high OF gives the trade more room before the breakeven lock; low OF locks profit faster). Per- engine leg allocations adjust within their calibrated bounds. The result is a trade whose exit geometry is not a one-size-fits-all template but a unique function of the conviction at its entry moment.

Higher conviction means larger position, longer hold, wider runner. Lower conviction means smaller position, tighter stop, faster scale-out. Same engine, same asset, same timeframe — different OF score produces a different trade. The formula chain is deterministic and fully audited: every shipped trade carries the OF score, the resulting leverage, the resulting size, and the resulting exit parameters as part of its event record.

Output — ELU accumulates outcomes into halt triggers. Once trades close, the system needs a unit for risk accounting that survives leverage changes. Most retail systems express risk in dollars or in percent of equity. Both break down at high leverage. A $200 stop at 25× leverage and a $200 stop at 100× leverage destroy radically different fractions of the account, but a percentage-of-equity rule treats them as identical. A leverage-aware system needs a leverage-aware unit.

Q7's answer is ELU — the Equity Loss Unit. Every trade is normalized so that one full stop-loss exit equals exactly 1.0 ELU at any leverage. Liquidations count as more than 1.0 because they are worse than a normal stop. Partial losses count as fractions. The system runs four parallel accumulators against this unit:

• Daily. Resets at session boundary.
• Weekly. Rolling 5-day window.
• Drawdown-from-peak. Continuously updated against the equity high-water mark.
• Consecutive losses. Streak counter, resets on the first profitable close.

Each accumulator trips literal trigger counts, not percentages: 5 losses → engine cooldown · 10 ELU/day → daily halt · 12 ELU drawdown → soft drawdown (size cut by half) · 15 ELU → tier-2 scale (size cut to a quarter) · 18 ELU → emergency close all positions · 22 ELU → kill switch (latched; manual reset required) · 25 ELU/week → weekly halt.

The ordering is guaranteed by construction. Soft drawdown always trips before tier-2, which always trips before emergency-close, which always trips before kill-switch. There is no path through the system where a worse condition fires before a milder one. This is what "leverage-aware risk" actually means — not a ratio, but a unit.

Markets are not stationary. Realized volatility on BTC at a given hour-of-day is not the same as on XAU at a different hour-of-day, and what looks like a "wide stop" in one regime is a hairline trigger in the other. The system needs more than a static volatility multiplier; it needs a real-time decomposition of where volatility is, where it came from, and where it is heading.

Λ-Vol Regime Intelligence is that decomposition. Developed by Sebastian Plano at Quant Research Decoded, the Λ-Vol framework provides a mathematically rigorous decomposition of volatility dynamics into three interacting forces: regime dynamics (the baseline flow), feedback loops (trend- reinforcing versus mean-reverting pressure), and dissipation (persistence drag, shock absorption, crowding and saturation).

The decomposition is implemented as a four-feature partial-differential-equation reading of vol — level, slope, dispersion, velocity — that expands to five regime states with per-engine weight profiles. The decomposition maps cleanly onto the four-engine architecture: each engine has its own Λ-Vol response function, and the regime classifier shifts engine weights and exit-system parameters as the regime changes underneath the trade.

Λ-Vol is the fourth predictive layer of the Hybrid AI overlay (described next). A trade does not execute unless the Λ-Vol regime classification agrees with the XGBoost direction prediction, the FinBERT sentiment reading, and the regime-match classifier. Vol is not a background variable in this system. It is a vote.

Pure machine-learning systems have a problem: when they fail, you can't tell why. You can't audit them, you can't calibrate them, and you can't explain a loss to anyone who matters. Pure rule-based systems have the opposite problem: they are perfectly auditable, but they cannot adapt to conditions the rules did not anticipate.

Q7's Hybrid AI overlay (HAI) is the reconciliation. The base trade comes from a deterministic Pine-script strategy — auditable, calibratable, fully documented. Four independent AI layers then validate every candidate trade. If any layer fails, the trade is discarded with a reason code. Only when all four agree does the trade execute.

1. AI 1 — XGBoost direction classifier. A gradient-boosted tree model trained on a feature vector of price, momentum, structural, and confluence inputs. Two hundred estimators, depth six, sixty-three percent out-of-sample directional accuracy. Predicts whether the engine's proposed direction agrees with the model's own direction estimate. Disagreement rejects the trade with ML_PREDICTION_MISMATCH.
2. AI 2 — FinBERT sentiment gate. A transformer language model that scores live financial news headlines on a [-1, +1] sentiment axis. Strong bearish sentiment (below −0.70) suspends all entries; mild bearish restricts to longs only; neutral or bullish passes through. The filter is asymmetric by design — bad news moves markets harder than good news, and sentiment extremes precede volatility expansions that other gates can't see. Catches earnings shocks, regulatory events, guidance cuts.
3. AI 3 — Regime-match classifier. A trailing 20-day rolling-return classifier that tags the macro state per asset as bullish, bearish, or neutral. In conservative operating mode, bearish regimes block all new entries regardless of engine trade — the system goes flat in a downtrend rather than fade it, suppressing systemic-drawdown exposure.
4. AI 4 — Λ-Vol regime intelligence. The Plano Λ-Vol decomposition (described in the previous section) classifies the current volatility regime into one of five states with per-engine weight profiles. The classifier acts as a conviction filter: trades that align with the current Λ-Vol regime pass through; trades that fight the regime are discarded. Vol is a vote, not a parameter.

The four layers are not redundant. Each looks at different data — model-implied direction, language sentiment, trailing realized return, volatility regime decomposition — and each catches a category of trade the others would miss. A trade that survives all four is, by construction, a trade where the engine pattern, the model's price judgment, the news flow, the prevailing regime, and the volatility topology all agree. Disagreement at any layer is a pass. A single trade must clear all four predictive layers and the full risk-management gate stack to reach execution.

HAI is calibrated per-strategy. S1 ships with sixteen trained models — one per (asset × timeframe) configuration. S2 through S6 ship with their own. Models retrain on a rolling schedule against the same precision gates as the rule-based parameters; if a model drifts and fails its forward-test thresholds, the agent system flags it and routes the configuration into recalibration.

Around the engines, the exit ladder, the order-flow validator, the ELU accumulator, and the HAI overlay sits a layer of supporting subsystems. Each one exists to handle a specific failure mode the calibration pipeline surfaced. They are small, named, individually toggleable, and each one earns its keep against a measurable diagnostic.

None of these is decorative. Each entered the system because a calibration cycle surfaced a specific defect pattern — commission spirals, win-rate collapses, gap-day damage, ratchet prematurity — and the subsystem closed the hole. They are documented internally with the same defect codes the calibration pipeline emits, so when a future cycle re-encounters the pattern, the response is already in the toolbox.

Every numerical parameter in the production system — every confluence threshold, every ATR multiplier, every ratchet tier, every HAI feature weight — is the output of the precision calibration pipeline, not a hand-tuned guess. The pipeline runs as discrete RX cycles, numbered in sequence per strategy. Each cycle searches the parameter space against a fresh, no-shortcut baseline and either ships an improvement or it doesn't.

The pipeline rests on two named financial-modeling pillars — Bayesian Optimization for parameter search and Monte Carlo Simulation for outcome validation. Around them sits a layer of supporting techniques that turn a probabilistic search into an audit-grade decision.

Pillar 01 — Bayesian Optimization

The search engine. Replaces brute-force trial sampling with Gaussian Process Bayesian Optimization, using a Monte-Carlo expected-improvement acquisition function that samples the posterior surface a thousand times per candidate and proposes the move that maximizes expected improvement under quantified uncertainty. Brute- force search picks the highest-scoring point in the trial set — by construction the most overfit. Bayesian Optimization picks the point with the best expected score under uncertainty, which finds plateaus rather than peaks.

• · 5–10× sample-efficient vs. Tree-structured Parzen Estimator search for the same convergence quality
• · Native uncertainty quantification — every shipped parameter set carries a posterior variance; the gate rejects candidates whose neighborhood is poorly explored
• · Plateau-seeking by construction — flat regions of the GP posterior have low improvement potential, so the optimizer naturally lingers in stable basins
• · Warm-start from prior PASS cycles — the GP posterior carries forward across RX cycles. Empirically: warm-started S1 BTC-1M ships at WR 78.1% / PF 1.79 vs. cold-start 69.5% / 1.78 (~26% net improvement, same trial count)
• · GPU-accelerated backend — BoTorch (Meta's PyTorch BO stack); falls back to scikit-learn's GaussianProcessRegressor when GPU is unavailable

Pillar 02 — Monte Carlo Simulation

Bayesian Optimization finds candidates; Monte Carlo Simulation decides whether they are real. The pipeline runs every SHIP-eligible candidate through tens of thousands of resampled paths under the historical return distribution to produce empirical distributions of every headline metric. The shipped numbers are lower 95% CI bounds under the MC distribution, not the single observation from one in-sample window.

Two simulation levels run on every cycle.

• Level A — path-level bootstrap (always-on). The 15 OOS paths from CPCV are bootstrap-resampled to produce empirical distributions of Sharpe, profit factor, drawdown, trade count, and net P&L. Block- bootstrap of contiguous return blocks of historically realistic length — preserves serial correlation that standard bootstrap would destroy.
• Level B — trade-order, forward-path, sign-permutation. When the backtester returns the per-trade P&L stream, three additional MC tests fire: trade-order bootstrap (does the equity curve depend on path-luck?), forward-path Monte Carlo (size the next-30-day live deployment gate), and sign-permutation null test (is observed net statistically distinguishable from random noise?).

Four MC criteria gate every SHIP decision:

• · MC drawdown upper 95% CI ≤ 35%
• · MC P(no edge) ≤ 20%
• · MC P(structural-fail tail) ≤ 15%
• · MC sign-permutation p-value on net P&L ≤ 5%

Headline backtest metrics are lottery tickets — one observation drawn from the distribution of possible histories. A configuration with a 2.0 Sharpe and a 5% MC p_no_edge is robust evidence; the same configuration with a 35% p_no_edge is a coincidence the next regime will dissolve. Monte Carlo turns the question from "does this look good?" into "under how many of the plausible histories does this still work?"

Supporting techniques

1. Combinatorial Purged Cross-Validation. Six time groups, fifteen out-of-sample combinations, embargoed (López de Prado). Every candidate evaluated against fifteen genuine OOS paths.
2. Deflated Sharpe Ratio + PSR. Discounts naive Sharpe by the expected-maximum a random search would produce given the same trial count and series length.
3. Block-bootstrap confidence intervals. Ships the lower 95% CI bound on Sharpe, PF, drawdown, and trade count — not the point estimate.
4. Population-Based Training jitter. Evolves a population of perturbed candidates; selects directly for plateau location.
5. DoubleML causal attribution. Separates parameters with causal predictive power from those riding spurious correlations. Causal-only parameters ship; spurious-correlate parameters get pruned to default.
6. Hawkes-process slippage modeling. Self-exciting point process on the tick stream — intensity-aware slippage matches live execution instead of assuming constant ticks.
7. Three-executor parity verification. Pine ↔ Python ↔ Live agreement ≥ 99.5% on entry, direction, exit, and fill price. No daylight allowed between what was tested and what executes.
8. Conformal prediction. Distribution-free per-signal P(win) interval whose lower bound must exceed 0.50 for the signal to clear the gate. Coverage guarantees hold even when the underlying probabilistic model is miscalibrated.
9. Determinism module. Pinned RNG seeds across numpy, random, and torch — bit- for-bit reproducibility across machines, an audit precondition.
10. Online conformal prediction. Live-shadow drift detection with mathematically-valid intervals; the system halts on conformal breach, not on an arbitrary threshold.

The precision gate

Every candidate configuration receives a verdict of SHIP / WHITELIST / REJECT. WHITELIST is the middle tier: ships, but with a flag operators see in the dashboard and that subscribers can opt out of. A configuration is SHIP-eligible iff it clears every one of:

• · CPCV path-level lower 95% CI Sharpe ≥ 0.5
• · Conformal lower bound on per-signal P(win) excludes 0.50
• · Jitter PnL CV ≤ 15% across ±5% perturbation
• · MC drawdown upper 95% CI ≤ 35%
• · MC P(no edge) ≤ 20%
• · MC P(structural-fail tail) ≤ 15%
• · MC sign-permutation p-value on net P&L ≤ 5%
• · Three-executor parity ≥ 99.5%
• · Stress-DSR (under regime perturbation) ≥ 60% of clean-DSR
• · In-sample trade count ≥ 100 with the forward 30-day gate appropriately sized
• · Hard rejects: PF < 0.5, MDD > 30%, or net < 0 — structural, no amount of more data fixes

A configuration ships when it passes every precision gate. A strategy ships when all sixteen of its configurations ship. There is no partial release. If fifteen pass and one fails, the strategy stays in calibration until the sixteenth crosses the line. Six strategies, ninety-six configurations, one bar — applied uniformly, no exceptions, every cycle.

The output of every cycle is a signed package: the baked Pine source, the per-configuration parameters, the round- by-round Bayesian-search history, the Monte Carlo distribution artifacts, the audit document, and a phase report. Every artifact is reproducible from the seeded source, version-controlled, and operator-auditable end- to-end. The same package that ships to subscribers is the same package the agent system reads when it watches for drift.

Calibration is not a one-time event. Markets drift, exchanges change microstructure, regimes shift, and a configuration that passed every gate six months ago will eventually fail. The system needs to know when this is happening, in real time, without a human asking. That is the job of the AEGIS agent system.

The agents run in tiers, each with a defined responsibility and a defined escalation path. They live inplatform/backend/agents/and run as background loops inside the same Python service that ingests TradingView webhooks and routes orders to the broker. The agent system and the trading system are not separate stacks — they share the same memory, the same database, and the same audit trail.

Tier 1 — sensors. Five always-on monitors emit telemetry continuously and at zero per-user cost: the chart monitor watches per-config price and signal output, the P&L monitor watches realized and unrealized exposure, the latency monitor watches webhook → execution roundtrip, the error-tail monitor watches the structured log stream for elevated rates, and the watchdog watches the watchers. Sensors emit; they do not act.

Tier 3 — ops core. Three agents consume Tier 1 telemetry and decide what is anomalous. The watcher enriches sensor events into structured incidents. The repair agent proposes a remediation — a parameter adjustment, a configuration pause, a worker restart — and by default runs in dry-run: it logs what it would do without doing it. Promotion to active repair is a deliberate operator action through the ops API, not an automatic escalation. The validator verifies any proposed fix against safety preconditions before it ships.

Tier 4–6 — Adaptive Repair Loop (AARL). Above ops core sits the long-horizon loop. Tier 4 is the aggregator: it computes rolling-30-day per-configuration metrics — net P&L, profit factor, win rate, drawdown, trade count — and stores them as cell baselines. Tier 5 is the drift detector: it sweeps the cell-baseline table and fires when a configuration's recent performance crosses outside its statistical confidence band. Tier 6 is the kickoff agent: it enqueues a fresh Optuna recalibration job for any flagged configuration, polls for completion, and routes the result back through the same SHIP/WATCH/ REJECT gates as a manually-triggered cycle. A triage-and-planner sublayer (Tier 6c) ranks queue priority so the most-impactful drifts are recalibrated first.

Tier-stability oversight. A separate monitor runs across the entire agent stack and verifies the agents themselves are healthy — heartbeat freshness, loop iteration cadence, queue depth, validator rejection rates. If the agent system is the system that watches the trading system, the stability monitor is the system that watches the agent system.

The same engines, the same exit ladder, the same ELU accumulator, the same HAI overlay, the same calibration pipeline, the same agent system. What changes between strategies is the market — the data, the venue, the liquidity, the per-configuration parameters the calibration pipeline finds. All seven strategies are at 16-of-16 SHIP against the precision gates as of this writing; their RX cycle numbers reflect how many independent recalibrations it took to get there.

Each strategy ships sixteen configurations — four assets × four timeframes — for a system-wide total of ninety-six configurations. Every one passes the same calibration gates. Every one runs under the same risk substrate. Every one is monitored by the same agent loop. The architecture is the product; the strategies are instances.

Q7 AEGIS AI is the result of a simple discipline applied at scale: every component must justify itself against a measurable test, no parameter ships without calibration, and no trade fires without three independent gates of agreement. The architecture is conservative because the capital it manages is real.

Past performance, including backtested performance, is not indicative of future results. Trading involves substantial risk of loss. The system halts itself at literal trigger counts because no model — rule-based or AI — anticipates every regime. The discipline is not "the system never loses." The discipline is "the system knows when it has lost enough and stops."

This document describes how the system works. Thearchitecture diagram shows where each component lives. Theperformance page shows what the calibration pipeline produced. Theprogram page describes how to access it. Questions from prospects and subscribers go through thecontact form.