PreDEX

PreDEX started from a question I'd been chewing on for years: what would algorithmic trading feel like if a genuinely capable AI lived inside the platform — not bolted on as a chatbot, but woven through the entire workflow? I wanted a research environment where the model does the heavy lifting most people never find time for — watching dozens of market and news feeds, distilling sentiment, designing strategies, and backtesting whole fleets of them — while the human stays unambiguously in command.

And I wanted it to meet you wherever you are. If you're merely curious, Dex can take you from a vague hunch to a tested, parameterized strategy in plain language. If you're a senior quant, it's a tireless research partner that never loses the thread across hundreds of experiments. Same system, different altitude.

Coming from trading-systems architecture, my first question was never “can the model trade?” — it was “if a position exists, can I explain exactly why?” PreDEX answers that by construction. Every position traces back to a deterministic strategy's gate evaluation against a snapshotted set of parameters, or to a manual order I placed myself.

The embedded co-pilot — Dex — reasons across the whole lifecycle: ideation, research, backtest, live, and retrospective. But it can only ever propose. Its write-capable tools don't execute anything; they render an approval card I have to confirm. The model's hands are tied on purpose.

PreDEX is a Turborepo monorepo running as five services on Railway: a Next.js trading terminal, a market-data ingestion hub subscribing to Hyperliquid and Paradex over WebSocket, a headless strategies runtime with four strategy archetypes and a backtest engine, an internal-only execution gateway (the only thing that can touch the live account, behind an order-management layer and a 30-second reconciler), and a news service that LLM-scores headline sentiment per instrument.

State lives in Postgres — raw pg, no ORM. Strategies climb an explicit L0→L5 promotion ladder, and every promotion is stamped to a fleet_epoch that records its hypothesis and parent lineage. So I can query the database to ask why a strategy is live and trace it back to the original idea.

The infrastructure discipline showed up most when things went wrong. An early bug let roughly 30 seconds of fills keep landing after I hit Stop — an in-flight async dispatch race. The fix was a synchronous halt flag checked at the execution boundary, so “stop” means stop now, not “stop once the queue drains.”

A reconciler continuously checks runtime intent against what the database and exchange actually believe, and a pre-launch plumbing audit caught three independent cross-venue data gaps before they could reach a live order. Keys never leave the client — the wallet signs orders in the browser; the server never sees a private key.

If there's one idea I've been chasing across this whole build, it's that the hard part of trustworthy AI in a high-stakes loop isn't the model — it's the architecture around it. Give the model rich tools, full read access, and a great reasoning surface; then make it structurally impossible for it to do the one thing you can't take back.

Get that balance right and the AI stops feeling like a gimmick and starts feeling like a genuine partner — capable enough to lift real weight, constrained enough to trust. More than any single feature, that's what I've been aiming for.