How does QuantDinger use Jev? As a gate in front of entry orders. A strategy decides
to buy or sell, then Jev answers six questions and the code decides whether the order
goes out. It's a safer design than the bots in part 1 that let Jev
decide everything: exits never go through the AI, and the decision rules live in code,
not in a prompt. But the gate lets orders through whenever it can't decide, and there's
no way to backtest it. That last point is what made me run my own test.

Where the gate sits

Part 2 covered QuantDinger as a platform. Jev is an optional
feature on top of it, switched on per strategy or for manual "Quick Trade" orders.

Everything below comes from reading the source at commit 96cec2d (21 Sep 2026),
mainly ai_decision_filter.py and ai_decision_context.py. I didn't run the platform;
it needs Docker, Postgres and Redis, and I only wanted to know how the gate decides.

How does the Jev gate decide?

In this order:

  1. The strategy produces a signal. Plain code checks risk and the order budget first.
  2. Is it an entry? Exits, stop losses, take profits and emergency closes skip the AI
    completely.
  3. Grid, DCA and martingale bots skip it too.
  4. One credit is charged. Jev gets the state and six questions, with an 8-second timeout.
  5. If Jev errors, answers in the wrong format, or isn't confident enough, the platform
    asks an ordinary LLM (OpenRouter, OpenAI and so on) instead.
  6. If no LLM is available either, the order goes through and the credit is refunded.
  7. Every decision is written to an audit table.

It only runs on live strategies, not in backtests or paper trading.

What does it ask Jev?

Six multiple-choice questions, sent together:

Question Choices
Is the data good enough to decide? sufficient / partial / insufficient
Does the signal agree across timeframes? aligned / mixed / conflict / insufficient
Does the market regime suit this entry? favorable / neutral / adverse / insufficient
Size, leverage, drawdown, losing streak clear / caution / block / insufficient
Fresh price, valid SL/TP? clear / caution / block / insufficient
Final decision pass / reject

The order goes out only when the final answer is pass, neither the risk nor the
execution check says block, and the timeframes don't show conflict in an adverse
regime at the same time. The state it sends is compact: a summary of up to 120 bars on
two or three timeframes (returns, MAs, RSI, MACD, ATR, support and resistance, data age),
open positions, and the strategy's recent results.

What it gets right

  • Exits never wait on the AI. A broken or slow model can't trap you in a position.
    This is the single most important choice and they made it correctly.
  • Rules in code. Jev answers fixed questions. It doesn't write the rule that decides.
  • Strict response checks. Every choice must be valid, probabilities must cover every
    option and sum to 1, and the chosen answer must be the most likely one. Anything else
    counts as a failure.
  • A full audit trail: the state sent, all six answers, probabilities, latency,
    provider, fallback reason, and the credit charged.
  • Tests for the main paths, including "exits bypass the AI".

Where is the filter weak?

Four places, in the order I'd fix them.

It lets trades through when unsure. If Jev's confidence on the key questions is
below 0.55 (the default), the platform treats that as an error and asks a different,
uncalibrated LLM. If that isn't configured, the trade goes through. So the moments when
the AI is least sure are exactly the moments the filter stops filtering.

Running out of credits switches it off. With no credits left, orders pass without any
check. A user can believe the filter is on when it isn't doing anything.

The prompt leans towards "pass". It tells the model that missing evidence alone must
not reject and to reject only on concrete evidence. Together with the fail-open paths,
the gate only blocks when the model is confident something is wrong.

You can't backtest it. The filter runs only live. There's no way to replay history
and see whether it would have helped or hurt, and the README gives no numbers either.

Two smaller ones. The data-quality answer is collected but never used in the decision.
And caution on risk or execution doesn't reduce position size; it's treated the same
as clear.

The question this left me with

Everything above assumes Jev reads the market the right way round. The gate can only help
if, when Jev says adverse or conflict, the trade really is worse than average. If Jev
reads the evidence backwards, the gate blocks good entries and passes bad ones, and
because it only runs live, nobody would see that until the P&L did.

How much damage that would do depends on how often the gate says no, and the prompt
leans towards pass. That's also something you can't measure without a backtest.

So I stopped reading code and asked the simpler question directly: given clean indicators
on data it has never seen, can Jev tell which way a market is about to move? That's the
experiment in part 5.

What I'd change

If I put an AI gate in front of an MT5 EA, I'd keep QuantDinger's two best ideas (exits
never go through the model, and the rule lives in code) and change three things:

  • Low confidence falls back to a fixed rule I chose, like "skip the trade" or "half
    size". Not to a different model.
  • caution cuts the lot size. Otherwise the answer is wasted.
  • Backtest the gate before going live. Save the state for every historical signal,
    ask the model offline, and compare results with and without the filter on the same
    tick data. It costs cents with Jev's pricing.

What I didn't check

  • I didn't run QuantDinger. This is a code reading at one commit; later versions may
    differ.
  • I didn't test QuantDinger's own prompt and questions against market data. Part 5 uses
    my own setup.
  • The SaaS version may be configured differently from the open-source defaults.

Next in this series: the experiment. I gave Jev 12 indicators on 1,500 Bitcoin candles it
had never seen and compared it with a plain model.