Cod3x — Research, live execution and an evidence-backed trading record

The problem

A convincing backtest is easy to produce. A trustworthy research process is harder. Data may have arrived after a simulated decision, a cost series may be misaligned, and a running service may be using a different configuration from the one that was tested. Cod3x explores how to make those differences visible before treating a result as evidence.

The system I designed

I designed Cod3x as a research and validation pipeline, with explicit boundaries between generating an idea, testing it, reviewing the evidence and permitting an operational action. Candidate strategies pass through common evaluation stages rather than receiving special treatment because an early result looks promising.

Historical data, features, simulation, risk checks and execution adapters have distinct responsibilities. Research records retain rejected approaches and the reasons they failed. That history matters when new coding sessions or agents revisit the same problem: a plausible explanation should not erase a previously tested result.

Engineering decisions

Time is part of the data model. A replay must use information available at the decision time, not merely data that exists today. An audit found places where mutable current artifacts were being reused in historical analysis, along with differences between live and simulated inputs. These findings limit which historical results can be trusted; they are not evidence that every replay is now point-in-time correct.

Validation must resemble the operational path. Tests with successful mock responses cannot establish that a real provider, order path or account integration behaves correctly. Promotion requires evidence beyond a green unit-test suite.

Missing required inputs must produce a visible stop or a clearly labeled degraded result. Treating an unavailable source as an empty dataset can quietly turn an outage into corrupted research.

Live HIP-4 evidence

Cod3x traded HIP-4 daily markets with real capital. While the strategy ran as designed, from May 2 to May 16, 2026, it realized +$977.62, recorded in Hyperliquid's on-chain fills.

The forecasting model was scored against how the markets actually settled. Over 22 daily markets its forecasts had a Brier score of 0.147, against 0.312 for the market's own prices (lower is better).

The losses that followed came from implementation failures, not from the model's forecasts. The figures below pair each period with what went wrong; the next section shows how each failure was fixed.

The short version: the model was right and the code around it wasn't. When the strategy ran as designed, it made money, and the forecasts beat the market. The record shows a net loss because of failures I had to engineer out, and the report estimates that fixing the regime switch alone would have turned it into a gain. The money was the cost of the lessons; the lessons are the hooks and guards below, and they paid for themselves. Model good, me bad.

How the implementation failures were fixed

Each loss traced back to how the system was built or operated, so each fix went into the engineering, not the model.

Agents can no longer improvise live orders. A pre-execution hook denies any command that places, closes or cancels a live order unless the agent has read the recorded procedure in the knowledge base within the last 45 minutes. It was verified with pass/fail tests: ordinary commands pass, a trade without a fresh read is denied, the same trade after a read is allowed.

Agents can no longer quietly change the live bot. Two agent regressions once blocked every order for four days (June 3–6) without any alert. A second hook now blocks edits to the live bot's launch script, order executor and canonical configuration unless the recorded decision behind them was read first, and the regressions were reverted.

The side of every position is checked against the bot's own log before anyone acts on it, which closes the misread that turned a winning position into a loss. The exit watcher was disarmed to report-only, so the strategy holds to settlement as designed. The bot is only called ready after checking the running process's real environment and a live account read, not just that a process exists. Journals are reconciled against on-chain fills, so a cut position can no longer appear as still open.

One lesson came from the fix itself: the first version of the hooks was written to disk but never registered, so it enforced nothing. A stale marker file exposed that, and the hooks were then wired in and proven to fire on a real command. A fix counts as done only when it is verified in place.

Wiring the regime switch into the live bot became the top engineering priority after the May 17–20 losses.

A failure that changed the design

An upstream settlement-data source began returning a web page instead of structured data. Some callers treated that failure as “no records.” A refresh path could then overwrite the historical cache with an empty result.

The client was changed to report an explicit source-unavailable error. Refresh logic preserves the prior cache on failure or an empty response, and downstream reports disclose degraded data sources. Regression tests cover the HTML response and malformed structured data; a recorded before/after comparison confirmed the saved cache was preserved.

What this demonstrates

The engineering contribution is an auditable research workflow: explicit assumptions, reproducible checks, operational boundaries and a memory of failed approaches. The case study reports dated live results, the model's measured forecast accuracy, and the implementation failures behind the losses with the fixes that followed, without claiming future profitability.

Role and limits

I conceived the system, set its research and risk constraints and retained operational decisions. Coding agents assisted with implementation, auditing and review. Source and proprietary strategy parameters remain private. Selected dated financial evidence is disclosed with its scope and provenance.