There's a running argument about whether a calibrated-probability model like Jev belongs anywhere near a trading system. I read through a batch of the GitHub backtests people posted, and honestly the argument misses the point. The models weren't the problem. The data feeding them was.
Let me lay out what I actually saw in those backtests, because the numbers are instructive, and then show you the boring thing I ended up building instead of another strategy.
The backtests were negative, and not because the model was dumb
One BTC/USD run set up five validation gates: random permutation test, multiple-comparison correction, a held-out out-of-sample window, Sharpe confidence intervals, and a buy-and-hold comparison. The holdout window ran about 65 days. Across ten different data representations, holdout discrimination came in at 0.471 to 0.503, where 0.5 is the random baseline. The best strategy returned -15.73% while buy-and-hold bitcoin over the same window returned +25.55%. Total model API cost for the whole thing: $2.5848.
A second project ran an order-book simulation, synthetic data replayed against real Kraken data. It made 339 decisions at a 67.8% hit rate. Gross P&L was +28.90, but after fees the net was -62.69. Break-even required fees below 0.316 basis points, which is lower than most real execution environments will ever give you. A 67.8% hit rate that still loses money. That's the whole lesson right there.
The takeaway isn't "the model is bad." It's that a calibrated probability is a decision primitive, not a strategy. Forcing an output on every tick is just calibrated coin-flipping once fees eat the edge. There's an arXiv paper from August 2026 that pushed this further: after statistical correction, the model-derived features contributed nothing, and a near-zero-cost baseline did better. The paper proposed a "calibration feasibility checkpoint" run before any inference, to verify the features actually carry predictive weight.
That checkpoint idea is what stuck with me. Because before you even get to "do these features predict anything," there's a dumber question almost nobody checks.
Do your timestamps line up?
This is the part that bites you after you've already wired everything together. Your model receives an input, produces a probability, and you assume the input represented a single coherent moment in the market. If it didn't, the probability isn't wrong so much as un-attributable. It said 72% based on what, exactly?
Priced at which second?
Here's the concrete trap I hit doing multi-market research. US equities carry different field structures for pre-market, regular session, and post-market. In one trading-sessions feed the regular session (09:30–16:00) has no `trade_session` field at all, pre-market (04:00–09:30) carries `trade_session: 1`, and post-market (16:00–20:00) carries `trade_session: 2`. So you can't switch on the field's value. You have to switch on whether the field exists. Code that checks `if trade_session == 0` to detect the regular session throws during the regular session, because the field isn't there to compare.
And it isn't one rule. Hong Kong runs a lunch break 12:00–13:00 that leaves a hole in the data. A-shares close with a call auction 14:57–15:00. Three markets, three session structures. If your decision system runs across markets, the data layer has to know which market and which session each row belongs to, rather than trusting one local clock.
Daily K-line data usually stamps each bar with a Unix-millisecond `time` field. That field is your evidence for what "current price" actually meant. In daily research the mismatch between when text was generated and when a quote was sampled might not matter. Intraday, it matters a lot, and it fails silently. Nobody sees a stack trace. The model just quietly gets fed rows from three different moments and hands back a confident number.
Build the pre-flight, not another strategy
So the thing worth building is unglamorous: a checker that inspects a batch of time-series rows before any model sees them, flags what's broken, and writes every flagged row somewhere you can actually look at and fix. This is squarely inside what a small team can host on VicroCode, and it doesn't require you to solve alpha first.
The core is a Python job. You can run Python online that ingests a feed, sorts by timestamp, and runs a handful of deterministic checks:
- **Monotonicity**: are timestamps strictly increasing, or did two bars arrive with the same or a backwards time?
- **Gaps**: given the expected interval for the market and session, is there a bar missing where there shouldn't be one, like the HK lunch hole showing up outside lunch?
- **Session membership**: does each row's timestamp fall inside a valid session for its market, using field existence rather than field value where the feed demands it?
- **Lookahead**: does any feature attached to a row carry information timestamped after that row's own time? This is the one that quietly inflates every backtest.
Each failed row gets logged, not just counted. Write them to a SQLite table with the original timestamp, the market, the check that failed, the expected value, and a status column you can flip to "reviewed" or "corrected." A built-in SQLite editor lets you open that table, eyeball the flagged rows, and correct or annotate them by hand before the cleaned batch moves on. That editable middle step is the whole point. You're not auto-dropping rows you don't understand; you're building an audit trail of what your data layer caught and what you decided to do about it.
From there you can wrap the checker as an API endpoint hosted in-platform, so your ingestion pipeline calls it as a gate: submit a batch, get back the flagged rows and a pass/fail, and refuse to hand anything downstream until it's clean. That's the calibration-feasibility checkpoint applied one layer earlier, at the data itself.
A fair boundary worth stating: this tool doesn't connect to any specific market data vendor or trading venue for you. It validates whatever structured rows you feed it. Pulling live quotes, executing orders, and vendor-specific auth all sit outside what I'm describing here. What's in scope is the deterministic, hosted checking layer and the inspectable log.
Why this is the better use of a weekend
The honest read on those negative backtests is that people put a judgment primitive in the execution seat and skipped the plumbing underneath it. The plumbing is where the real, repeatable value is, and it's testable in a way a strategy never is. A timestamp checker either catches the lookahead or it doesn't; you can write fixtures for every case and know it works.
It's also the kind of thing you can package and share. A hosted checker with a clean input contract and an editable audit table is genuinely useful to anyone running time-series into a model, quant or not, and it can live alongside your other online tools as something you publish rather than rebuild each time. Build the boring gate once, and every model that comes after it gets data you can actually stand behind.