Using TypeSafe Jev as the Decision Engine for Jev FCPO

How the real TypeSafe Jev model was wired into Jev FCPO, what two live FCPO sessions measured, and the defects they exposed.

1. Background: what Jev FCPO is, and why we built it

Jev FCPO is a personal monitoring and paper-trading workstation for Crude Palm Oil Futures (FCPO) on Bursa Malaysia Derivatives. It is not a broker and it does not place live orders. It is a monitoring platform with an autonomous decision layer, built to do three jobs at once:

1. Watch the market across four timeframes. It receives live FCPO bars (1m, 3m, 5m, 30m) pushed from TradingView webhooks, keeps a rolling window per timeframe, and derives a regime for each sleeve (for example STRONG_BULLISH, BULLISH_PULLBACK, CHOPPY_SIDEWAYS).
2. Score each bar with a decision model. Every bar close is compiled into a structured market snapshot and sent to TypeSafe Jev, which returns a typed verdict: an action, a setup grade, and an exhaustion-risk figure.
3. Simulate execution honestly. A paper book applies real Bursa friction (1 tick = RM 1 per ton = RM 25 per contract, RM 15 round-turn commission, 1-tick slippage) so the record reflects what a real account would experience.

The name is deliberate. The interface and the decision loop are modelled on jev-trade, a crypto perpetuals trading tool. Jev FCPO ports that shape to Malaysian palm oil futures, swapping the crypto tick model for Bursa's contract spec and replacing the generative decision logic with TypeSafe Jev.

What problem this solves

A retail FCPO trader working a single chart has to hold four timeframes in their head at once: the 30-minute tide, the 5-minute structure, the 1-minute trigger, and the risk maths that ties them together. Under a live session, that is where discipline breaks. Jev FCPO externalises the whole loop. It does not tell you what to feel; it prints the verdict and logs it, so the trader can benchmark their own calls against an unemotional, repeatable process.

The four-step rulebook the engine enforces

The decision model is not asked to freeform. It scores against a fixed 4-step trend SOP drawn from Elder's Triple Screen, Raschke's EMA pullback, Dow structure, and Wilder ATR sizing:

Two invariants sit above the steps: never trade against the 30m tide, and never open a new position within ten minutes of a session close. Everything the model can say is bounded by those rules.

Why we are pushing Jev here

The build exists to test a specific claim: that a typed, non-generative decision model can hold a repeatable intraday process better than a human under pressure. That is why the engine logs every verdict with its latency and cost, why the paper book models real friction instead of pretending fills are free, and why this report bothers to measure the model rather than assert that it works. The question is not "can Jev produce a signal". The question is whether its signal is stable, affordable, and disciplined enough to be worth acting on. The rest of this report answers that with data from a live session.

2. Why Jev matters to this build

Jev FCPO is not a charting toy. It ingests multi-timeframe FCPO bars and asks a decision model a structured question: what is the best immediate action, how good is the setup, and how exhausted is the move? Everything downstream (the paper book, the stop sizing, the R:R filter) hangs off that answer.

The original code shipped an offline keyword simulator (jev-fcpo-sim-v1) because no model key existed. The simulator scored grade by matching words in a text prompt, which is why early sessions reported Grade A on every single bar. That is not a decision engine; it is a lookup table wearing a lanyard.

The first live session replaced it with the real model.

3. Integration contract

Jev is reachable two ways, and the code prefers them in this order:

400: "~typesafe/jev-latest is a decisions model and cannot be used with the
chat/completions endpoint. Use the /api/alpha/decisions endpoint instead."

The decisions endpoint accepts the exact { model, state, questions } contract the existing code already built for TypeSafe, so the real model drops in without reshaping the schema. Each question (choice, score, noul) must carry an instructions field or the payload is rejected.

Response shape

{
  "model": "typesafe/jev-1.13-20260917",
  "answers": {
    "action":          { "choice": "ENTER_LONG", "probabilities": { "ENTER_LONG": 1, "ENTER_SHORT": 0, "HOLD": 0 }, "confidence": 1 },
    "setup_quality":   { "score": 2.84, "probabilities": { "2": 0.15, "3": 0.85 }, "confidence": 0.84 },
    "exhaustion_risk": { "noul": 0.22 }
  },
  "usage": { "input_tokens": 442, "output_tokens": 78, "cost": 0.000018564 },
  "provider": "TypeSafe",
  "id": "gen-dec-1790003587-YJla9sL0ZkB5NbiVD2cv"
}

4. Measurements

Latency sample combines 15 live FCPO bar-close evaluations from the first session with a 12-call controlled benchmark across four synthetic market states (aligned-bullish, aligned-bearish, chop, conflict), 3 repeats each. Full data: docs/jev-bench.json. The 95-call instrumented run in section 4.6 is measured separately and is not folded into this sample.

4.1 First session: latency distribution

4.2 First session: decision filter funnel

4.3 First session: verdict mix

4.4 Determinism and outcome stability

The controlled benchmark repeated each of four market states three times. Scores are continuous and near-stable; the action is not, in the one ambiguous regime.

4.5 Second session: moving off the laptop, and learning to measure

The night session moved the engine off the laptop tunnel and onto the host that already runs the other fleet services, behind nginx and TLS. This matters more than it sounds. A Cloudflare quick tunnel is bound to a process on a laptop: close the lid, lose the feed. The engine now runs as a supervised service that survives a reboot, and the webhook endpoint is a stable public URL the TradingView alerts can keep pointing at week after week.

The deployment also forced one security change. The webhook accepted any request that simply omitted the secret field - harmless on localhost, an open door on a public endpoint. Anyone could have posted fabricated bars, and every bar triggers a paid model call and can move the paper book. The secret is now required, not optional. Verified: a request with no secret returns 401, the same as one with a wrong secret.

The second change was measurement. Until this session, Jev's verdicts lived in a 50-entry in-memory ring buffer that emptied on every restart, so the obvious question - when Jev said this, what actually happened? - was unanswerable after the fact. The engine now appends every evaluation to a durable log and stores the answer next to the question:

4.6 The instrumented run, and what it revealed

A 95-evaluation run exercised the full path end to end. The caveat belongs before the numbers: this run was driven by replayed bars generated for the test, not by the live market, though all 95 evaluations were real model calls against a synthesised snapshot. It is an integration test with a real decision model, not market evidence, and it is archived separately from the live log so it cannot contaminate calibration data.

The four entry signals were the interesting part, and none was a close call:

4.7 Ingestion and cost

The cost figure is the decisive one: a session costs well under a cent. There is no economic case for the offline simulator whenever a key is present.

5. Defects these sessions exposed and fixed

6. Conclusions and carry-forward

1. Jev is a decisions model, not a language model. It refuses chat endpoints and speaks a typed choice/score/noul contract. That contract already existed in the codebase; the integration was a transport swap.
2. Latency is hundreds of milliseconds, not tens. p50 427 ms, p95 1287 ms, CV 0.54. Fine for bar-close decisions, not for anything tick-driven.
3. Clear regimes are reproducible; boundary regimes are not. Aligned states repeated identically across runs; the one conflicting state flipped action on an identical prompt. The grade gate is the guard that keeps this out of the paper book.
4. Cheap enough to run unconditionally. $0.0318 per 1,000 calls removes any cost argument for the simulator.
5. Decision quality is bounded by how many sleeves are feeding it. With all four connected, the model produced a genuine spread including Grade C entries. With only the 5m sleeve, the setup score never left the bottom two rungs in 95 calls. Check ingestion before interpreting any threshold result.
6. Require the webhook secret. An optional check is not a check. This is the difference between a localhost toy and a public endpoint.
7. Measure before tuning. Every threshold decision in the next phase depends on the durable log, which did not exist before this work.
8. Operational traps to remember. Do not run the simulation script against a live engine - test_rich_feed.mjs pushes ~4200-price bars into the same in-memory state as live ~4905 bars and fabricates positions. Validate timeframes on ingest, since anything outside 1/3/5/30 is accepted but invisible to /api/status and the UI.