The Architecture

An autonomous platform that runs itself

Sovereign Trading is operated by a layered AI architecture. Inside each trading bot, Claude is the MPYA brain — the same intelligence makes per-trade decisions. At the platform layer, Claude is the meta-MPYA brain — operating the bots themselves. Self-healing, self-validating, self-expanding. This page is a factual account of exactly what's been built.

Sentinel cycle

5 min

Capacity cycle

15 min

Forge cycle

24 hr

Quality gates

Bots monitored

Operator clicks/day

The autonomy stack

Four background daemons run continuously, with one Claude brain on top. Each layer can fail safe — if the brain is offline, the daemon falls back to its hardcoded behavior. Defense in depth, not single-point-of-failure.

Sentinel LIVE

A 5-minute self-healing SRE agent. Every cycle it runs 8 health checks (bot responsiveness, brain status, platform surfaces, database, gap alerts, auth failures, deploy state, Forge bot health) and routes detected issues to one of five healers (propagate secrets, force sync, clear lockouts, manual redeploy, Forge rollback).

5-min cycle · 8 checks · 5 healers · 5 safety guards

Forge LIVE

A 24-hour autonomous bot generator. Enumerates candidate variants (capital tier × underlying combinations of existing validated strategies), runs each through a real 5-year yfinance backtest, applies a three-gate quality wall, and auto-deploys passing variants via GitHub API. Inferior variants are rejected categorically.

24-hour cycle · real yfinance backtest · 3-gate wall · paper-only deploy

Capacity Monitor LIVE

A 15-minute capacity guardian. Every active Sentinel version's AUM is tracked against its validated capacity ceiling. At 70% utilization a successor version is auto-spawned. At 90% existing customers receive 30-day transition notices. At 95% transitions execute. Customer Agreement §4C pre-authorizes all of this.

15-min cycle · 70/90/95 thresholds · DB-immutable audit log

Sentinel Brain (Claude as meta-MPYA) LIVE

Every issue Sentinel detects is routed to Claude with 24-hour audit context. Claude decides: HEAL_WITH_<X> / WAIT_AND_RETRY / IGNORE_BENIGN / ESCALATE_HUMAN — with root-cause analysis, confidence rating, and reasoning. Only genuinely novel issues become human-visible RED alerts. Known patterns are healed silently with the brain's reasoning written to audit.

Per-issue Claude consult · 6-hour pattern cache · fingerprint deduplication

The MPYA Brain — conviction-scaled sizing

Every Sentinel runs the same four-shield rule layer — regime detector, signal-score thresholds, minimum credit, deterministic position sizing. That core is what 20 years of backtesting validated. On top of that core sits the MPYA Brain: a Claude reasoning layer that reads the market context before each trade (regime, news headlines, FOMC distance, macro setup) and returns one of four conviction signals: SKIP (do not trade), REDUCE (size down 25–50%), PROCEED (size normally), or AGGRESSIVE (size up to 50% larger — exceptional conditions only).

Each Sentinel has a base deployment percentage — the share of capital the rule layer puts at risk on a normal day. The MPYA conviction multiplier then scales that base. On a low-conviction day the bot trades smaller or stands down entirely. On an exceptional setup in a favorable regime the bot leans in. Realized at-risk capital ranges from 0% (SKIP) to approximately 2.1× the base (GOLDILOCKS regime × AGGRESSIVE conviction).

This is the core difference between Sovereign and a static rules engine. The rules are non-negotiable — strikes, widths, stops, regime thresholds, the four shields. The conviction is responsive — the brain sizes the bet to the opportunity, within the rules' guardrails.

Sentinel	Base deployment	Realized range
POLARIS	2%	0% – 4.2%
GENESIS V1	2%	0% – 4.2%
KAIROS	6%	0% – 12.6%
CHOCHMA	8%	0% – 16.8%
GENESIS V2	8%	0% – 16.8%
PRECISION	14%	0% – 29.4%
ELI	14%	0% – 29.4%
ORACLE V1	14%	0% – 29.4%

Numbers compound on capital growth — as the account grows, the same base percentage represents more dollars at risk. The conviction multiplier preserves the same ratio.

The "never close" architecture

Most quantitative funds close to new investors when capacity fills (Renaissance Medallion is the canonical example). The strategy hits a capacity ceiling and adding more capital degrades returns for everyone. Sovereign's architecture sidesteps this with six independent expansion axes that compound multiplicatively.

Axis 1 · Multi-vehicle LIVE

Each Sentinel runs as multiple versions (v1, v2, v3...). When v_n hits 70% capacity, v_n+1 is auto-spawned with byte-identical strategy code and a fresh capacity allowance. Customer fee tier, locked rate, and signup date preserved at the database-immutability level.

Backed by sentinel_versions table + capacity_audit_log + DB triggers

Axis 2 · Multi-strategy LIVE

Eight SPX commercial Sentinels, each with its own capacity ceiling. Forge generates new validated variants. As old strategies age, new ones emerge through the superior-or-reject quality wall.

Forge generates · 3-gate wall validates · paper-only initial deploy

Axis 3 · Multi-underlying PARTIAL

SPX live. SPY in waitlist mode (Phase A Lite calibration pending). XSP supported in code for micro-tier accounts. Each underlying is an independent liquidity pool — adding underlyings multiplies platform capacity.

SPX active · SPY waitlist · QQQ/IWM expansion planned

Axis 4 · Multi-broker PARTIAL

Tastytrade live. Seventeen broker adapters scaffolded (6 US + 10 international) with a 47-test contract battery validating each integration. Each broker's fill capacity is independent — adding brokers multiplies platform capacity.

Tastytrade active · 16 broker scaffolds · 47-test battery per adapter

Axis 5 · Time-stagger LIVE

Each Sentinel version runs as a fleet of shards — independent bot instances with byte-identical strategy logic but staggered schedule offsets across a 60-second window. Customers are assigned to shards by load balance. Same alpha, no concentrated per-second market impact. Auto-spawns more shards as load grows.

60-second window · auto-balance at 70% load · up to 60 shards/version

Axis 6 · AI evolution PARTIAL

Forge with real yfinance backtester is shipped. Claude-driven variant proposal (intelligent mutations based on market regime) is the next layer. As old strategies age, the platform generates new ones — institutional memory in code form.

Layer 1 (yfinance backtest) live · Layer 2 (Claude proposer) next

The three-gate quality wall

Every Forge-generated variant runs the same gate before any customer-facing deployment:

Absolute floors (categorical reject)

CAGR ≥ 35% · Win rate ≥ 97% · Sharpe ≥ 4.0 · MaxDD ≤ 3% — calibrated against the existing fleet's actual minimums (excluding outliers). Variants that fail ANY absolute floor are rejected categorically, no override.

Per-dimension relative floor

Every metric must beat the fleet median. No single dimension below median — even if other dimensions are strong. POLARIS variants with an extreme Sharpe still get rejected if their CAGR is 0.97× the fleet median.

Composite fitness

Product of all four ratios (CAGR / Sharpe / DD-inverted / WR) must be ≥ 1.10× baseline. The variant must be 10%+ better overall to deploy. Most candidates fail here — by design.

Current Forge cycle result: 0 of 42 candidates pass. That's not a bug; the existing fleet is so strong that almost no projection-extrapolated variant clears the bar. The day something passes, it'll be because real backtest data confirms genuine superiority on every axis.

Paper-trading validation — three independent gates

No Forge-generated bot can place a real trade until three independent gates open:

Environment gate. Forge sets TASTYTRADE_SANDBOX=true in every variant's Render service config — bot points at cert.tastyworks.com (paper API). Changing this requires manual Render dashboard intervention.
Code gate. Bot source uses the /orders/dry-run Tastytrade endpoint, which never executes. Switching to /orders requires manual code change to the bot file.
Feature flag gate. The platform's activation_enabled flag is locked at 0. Customer-facing activation can only be flipped via typed step-up confirmation on the admin feature-flags page.

All three gates must be opened — no autonomous process can flip any of them. This is the firewall between "we've generated a promising variant" and "real customer money is being traded."

The factory production loop

Day 0: Forge enumerates candidate (parent × tier × underlying) tuples Day 0: Each candidate backtested against 5 years of yfinance ^GSPC/SPY/^VIX Day 0: 3-gate quality wall applied. Most candidates rejected. Audit-logged. Day 0: Single best passing variant (if any): → bot file generated from parent template → committed to sovereign-bots via GitHub API → Render auto-deploys → service comes up in PAPER mode Days 1-30: Sentinel watches the new bot via 5-min cycle. → Brain analyzes every anomaly with reasoning → Healing actions fire autonomously → If unhealthy in first 24h: AUTO-ROLLBACK (file deleted via GitHub) Day 30+: Variant is now a validated paper-calibration record. → Customer-facing exposure requires manual founder approval → Real-money activation requires three-gate manual unlock → No autonomous process can flip any of those gates.

What's required of a human operator

Task	Frequency	Why human
Set API keys on platform service (one-time)	Once	Can't bootstrap own secrets
Approve real-money activation per Sentinel	Once per Sentinel	Money movement — protected category
Review explicitly-escalated RED verdicts	Rare	Genuinely novel anomalies (most are auto-healed)
Legal document changes	Quarterly	Counsel review (Oren Litwin)
Strategic business decisions	As needed	Inherent founder work

The operator's promise. Everything not in that table — bot operations, secret rotation, anomaly response, capacity management, variant generation, validation testing, deploy automation, rollback triggers — runs without human intervention. The platform sends "all healthy" pings, not error queues.

Live paper-calibration outcomes

Updated automatically as Forge variants accumulate paper-trading days. Empty until Forge first deploys a variant that passes the three-gate quality wall.

Forge has not yet deployed any variants. As of the most recent cycle, all 42 enumerated candidates failed the three-gate quality wall — the existing fleet is strong enough that no projected variant currently passes. When Forge deploys its first variant, this section will populate with the variant's backtest projection alongside its live paper outcomes, updated daily.

An honest delineation

What's genuinely shipped

Sentinel (5-min self-healing) · Capacity monitor (15-min auto-spawn) · Forge with real yfinance backtester (24-hour autonomous variant generation) · Sentinel Brain (Claude routing every anomaly) · Time-stagger sharding (per-second market-impact protection) · Customer Agreement §4C pre-authorization · Three-gate quality wall · Five-gate "do no harm" safety system · DB-immutable audit log for every autonomous action.

What's partial

Multi-broker activation (Tastytrade live, 16 other adapters scaffolded but not yet wired) · SPY tier (waitlist mode, Phase A Lite calibration pending) · Stripe payment processing (scaffolded but stubbed — no real charges flow yet) · Claude-driven variant proposer (Layer 2 of Forge, design complete, build pending).

What requires founder authorization to ever run

Real-money trading activation (three independent gates) · Bot strategy logic changes (CLAUDE.md §4 protected) · Money-movement code (Stripe charges) · Broker authorization scope changes · The activation_enabled feature flag. These cannot be flipped by any autonomous process — the architecture forbids it.

This page is intentionally factual. Every claim above corresponds to a specific file, table, or commit. The autonomy described is operational today. Real-money customer activation remains gated on manual founder approval and is currently closed (activation_enabled = 0) pending paper-calibration completion and regulatory finalization.