Jev in trading loops

01Rules in code, judgement in Jev

Every build in this category separates two things that trading systems usually mix: the deterministic rule and the discretionary call. The rule lives in code — a moving average crosses, a price band is breached, a block number arrives. The call about what to do next is the part that gets handed to a model.

That split is the same one you see in the agent-loop case, but here it carries a second meaning. If the model can only choose among options the code has already enumerated, then it cannot invent an order. A veto is a schema violation rather than a prompt instruction, and that is a property of the interface rather than a hope about the model’s behaviour.

// the rule is code; only the judgement is a model call
if (crossesBelow(price, movingAverage50)) {
  const verdict = await jev({
    state: { symbol, price, ma50, position, realisedVol },
    questions: {
      action: { type: 'choice', criteria: { buy, sell, hold, flatten } },
      size:   { type: 'score' },   // 0..1, scaled by your own risk limits
    },
  })
  if (verdict.action.confidence < 0.7) return  // below threshold: do nothing
  placeOrder(verdict.action.choice, riskLimit * verdict.size.score)
}

02What is reproducible, and what is not

Two kinds of numbers appear in these posts, and only one of them is worth anything. Latency and per-decision cost are reproducible: they come from the same infrastructure everyone buys, and they land where the benchmark page shows they land. Profit and loss over a short window is not evidence of anything. None of the posts we collected includes an out-of-sample test, a fee model, or a slippage assumption, and without those three a P&L figure is a story rather than a measurement.

There is a structural reason this category looks more convincing than it is. A trading bot generates a stream of decisions, and over any short window a stream of coin flips contains runs. The posts that get shared are the runs. That is not dishonesty on the authors’ part — it is what a demo is — but it means the reproducibility you should care about here is the latency budget and the failure behaviour, not the equity curve.

03Where the decision model belongs, and where it does not

The pattern that holds up puts the model at the point where a human trader would hesitate: is this the same setup as last time, is the regime still the one my rule was tuned for, does this headline change anything. Those are bounded, enumerable questions with a short answer.

What the pattern does not do is size positions, manage risk limits, or decide whether to trade at all. Those stay in code, because they are the places where being wrong is unrecoverable and where the answer has to be the same every time the same state arrives. A decision model returns a probability; a position size is a policy decision about how much of that probability you are willing to be wrong about.

04Failure modes, in the order they bite

Regime change is the one that surprises people. A rule tuned for trending markets keeps asking the same questions in a ranging market, and the model keeps answering them confidently because the answers are internally consistent — it is evaluating the state you gave it, and the state has not changed in the way your rule assumes. The model cannot notice that your question is the wrong question.

Frequency multiplies every error. At one decision per 300 ms block you are making roughly 288,000 judgements a day; a one-in-a-thousand mistake rate that would be invisible in a daily strategy becomes a daily event. This is why the builds with the tightest loops spend most of their code on what happens when the answer is below threshold.

Cold starts are expensive in a way that matters here. Our measurement put a cold call more than 100 ms above the warm median. In a loop that fires on every block, the first decision after any quiet period is the one most likely to miss its window, and it is also the one where your fallback rule has to be good enough to stand alone.

Finally, nothing in this architecture validates the rule. The model answers whether this setup matches what you asked about, not whether what you asked about is profitable. Those are separate claims, and the second one still needs the backtest you would have needed anyway.

05How to read the case list below

Take the per-decision costs and the decision frequencies seriously — they are consistent across independent builds and they tell you what the infrastructure can carry. Disregard the profit figures entirely, including the ones with large dollar signs; they are demonstrations, not results. If you are building in this area, the useful question to ask of these posts is not “did it make money” but “what did it do when the model was unsure”.