ResearchPod Summary
CODY v2 is an automated quantitative trading system designed to manage the full lifecycle of alpha-generating trades across equities, futures, and crypto. Moving away from the v1 model of a single event-driven pipeline, v2 introduces a four-plane architecture where Research, Portfolio, Execution, and Control each possess independent clocks, state management, and failure domains. By decoupling these functions, the system prevents alpha-side bottlenecks from jeopardizing execution or risk management.
Unlike its predecessor, v2 enforces strict contracts. Signals must be emitted as 'View' objects containing expected returns and uncertainty, rather than dimensionless scores. The architecture mandates as-of-correct point-in-time feature storage to prevent look-ahead bias and requires a rigorous, two-door promotion gate (Shadow and Live) that accounts for cost-aware PnL and trial counts (DSR). By mandating native tick ingestion and prohibiting global grids or interpolated pricing, the system maintains high fidelity for both backtesting and live operations.
Sam: A risk check inside your model's own process is a suggestion, not a control. That line sits at the heart of a design document for an automated trading system called CODY. Its argument is simple. Forecasting, sizing, sending orders, and the emergency stop run on different clocks, so they belong in separate programs that fail separately.
Alex: Before we get into the parts, place it for me. Whose document is this, and what kind?
Sam: It's an internal, confidential architecture specification from a quantitative trading team. It covers equities, futures, and crypto. It's version two, dated October 2026, and it replaces an earlier spec written for interns. No authors are named. So it's a design document with rules and reasons, not a study with results.
Alex: Most of our listeners don't trade. Why should someone building, say, machine learning pipelines or lab automation care?
Sam: Because the problem travels. Any system where a model's output becomes an action has to decide where the slow, experimental work ends and where the off switch lives. This spec draws those lines very concretely. We'll cover what broke in version one, the idea behind the redesign, one worked example, and how far to trust a document that has no performance numbers in it.
Alex: Start with version one. What was the original sin?
Sam: Version one was a single pipeline, from raw price tick to order. Research, portfolio construction, and execution all shared one clock, one message bus, and one failure domain. So one component stalling could stall everything. It also snapped every tick onto a fixed millisecond grid and converted all prices to US dollars on the way in.
Alex: Snapping data to a regular grid sounds like ordinary preprocessing. Why does the spec treat it as a mistake?
Sam: Because filling a grid means interpolating, and the spec says that invents trades the exchange never sent. The dollar conversion has a similar problem. A bitcoin trade priced in another currency, converted at the door, can't be replayed against an exchange that never saw that dollar price. So version two's ingest is described as an archivist. It keeps native currency, exchange time, local receive time, and sequence numbers. Each consumer translates for itself.
AI-generated third-party summary by ResearchPod. Not official content or an endorsement by the paper authors or affiliated organizations.
Alex: So what's the core idea of version two, in a sentence or two?
Sam: Four planes, where a plane is a separate failure domain with its own clock. Research runs on minutes to overnight and produces forecasts. Portfolio takes snapshots every second to every few minutes and turns forecasts into target holdings. Execution runs at the speed of a round trip to the exchange and only tries to reach those targets cheaply. Control is always on, in its own binary, and can flatten the book.
Alex: So the research side never touches an order. It hands over a forecast and walks away.
Sam: That's their rule, almost word for word: research emits views, not orders. And a View has a specific shape. It's an expected return over a stated horizon, plus the uncertainty of that forecast. Version one emitted a score between minus one and one instead.
Alex: What's actually wrong with a bounded score? Lots of systems use normalized signals.
Sam: A score isn't a return, and the optimizer needs a return. The spec's warning is vivid. Feed a z-score in as if it were a return, and a two-sigma move becomes a 200 percent expected return, and the optimizer tries to buy the world. There's a subtler rule too. If a model has no opinion, it emits nothing. Emitting zero means "I'm confident the return is zero."
Alex: Walk me through one forecast, start to finish, so I can see the planes hand off.
Sam: The spec's own example is a momentum signal on Apple. Say momentum emits a positive view of 0.8. In the portfolio plane, that view meets trading costs, its correlation with other signals, and a tail-risk budget. The output is "buy 12 basis points of the book," not 5 percent. Then execution slices that order over time, because a single large order moves the price against you.
Alex: And combining signals happens in that portfolio step too, I assume. How did version one do it?
Sam: Version one weighted each signal by the inverse of its own volatility. The spec says that treats momentum and machine learning signals as uncorrelated, and they aren't. Version two combines views using the covariance of their errors, estimated out of sample. Costs sit inside the optimizer, not bolted on afterwards.
Alex: Here's my obvious objection. A kill switch is only as good as its connection to the exchange. If execution is frozen, how does control actually act?
Sam: That's the October revision, and it's the most careful part. Control holds its own exchange sessions, permissioned cancel-only and reduce-only. So it can never open or increase risk. It gets positions from drop-copy, the exchange's own copy of every order and fill, sent straight to control. It never asks execution what we own.
Alex: And if every one of the firm's own machines goes down at once?
Sam: Then the exchange does the work. Execution sessions use cancel-on-disconnect and cancel-after timers where venues support them. If execution stops checking in, the exchange pulls resting orders itself. The last resort is the broker's own kill switch.
Alex: There are two control instances. Two referees who disagree can be worse than one. How do they settle it?
Sam: Strictest decision wins. There's a ladder: permit, reduce, flatten, halt. Either instance can escalate alone. Stepping back toward permit needs both instances plus a human. If their position or profit estimates drift apart beyond a tolerance, that itself triggers a reduce and a page. And duplicate flatten orders are safe, because reduce-only orders can't flip a position.
Alex: What do the actual settings look like?
Sam: An example configuration sets a heartbeat of 750 milliseconds, with a flatten after three missed beats. Maximum daily loss is 2 percent of net asset value, marked to mid price. That's a hard flatten, not a dashboard warning.
Alex: Researchers will care most about how a new model gets switched on. What's the bar?
Sam: It's called the promotion gate. It requires walk-forward testing with overlapping labels purged and a gap at least as long as the forecast horizon. Profit must be measured after fees, spread, and market impact. It uses a deflated Sharpe ratio, which penalizes risk-adjusted return for how many tries you made. And every notebook run counts. Forty runs in a notebook is forty trials.
Alex: That rule would sting in a lot of labs. Anything beyond the statistics?
Sam: Capacity and a live rehearsal. A model that works at small size but is about to be sized much larger hasn't passed. New models run in shadow, live but unsized, before they touch the book. And a model muted for poor live performance can't unmute itself without a human.
Alex: So how much should we trust all this? What's the evidence?
Sam: There isn't any, in the empirical sense, and the document says so. It deliberately publishes no end-to-end latency and no live Sharpe, calling those research claims. One tip says that if a number looks like a live track record, it's a bug. What you get is reasoning, with each design choice tied to a named failure.
Alex: Then what's the limitation that matters most?
Sam: Nothing here shows the redesign works. There's no comparison of version one against version two, no incident history, no test of the kill path. Several thresholds are marked as examples. And in my reading, it's still settling: the promotion gate is called "two doors" while listing six checks. Read it as a well-argued blueprint, not a validated system.
Alex: So who should sit down with the full spec, and where should they start?
Sam: Anyone building trading infrastructure, or any system where models trigger real actions. Start with the control plane section, specifically the kill path and how the two instances arbitrate. Then read the table of what they dropped from version one, and why. Then the signal contract, the rules for a View.
Alex: And for everyone else, the one line to carry around?
Sam: Keep the forecast, the decision, and the off switch in separate processes. And give the off switch its own line out.
Alex: A good rule for anything that can act faster than you can.