JEV-style local judges in three spoonfuls: when voting improves a decision and when it only stalls it
---
title: "JEV-style local judges in three spoonfuls: when voting improves a decision and when it only stalls it"
published: true
description: "Proof of concept of a 2-of-3 committee on CPU (Laya, VegaML, and Arc Decide) on an Intel Core i7-8550U, with an ONNX INT8 NLI cross-encoder (DeBERTa-v3-small) as an alternative still to be measured."
tags: "aievaluation, localinference, cpu, decisionmaking"
canonical_url: "3cucharadas.cl"
cover_image: "3cucharadas.cl"
ai_disclosure_level: "some_ai"
---
When I automate code workflows and technical auditing, many verification checks do not need generated prose: they need a fast verdict between "Yes" (the evidence suffices), "No" (there is a hard failure), or "Undefined" (it is safer to abstain and escalate). Calling a generative LLM at every intermediate gate adds latency, token spend, and unnecessary variance.
That is why I built a proof of concept (PoC) called simil-jev: an "Olympic judges committee" (2-of-3) running on my laptop CPU with three small models of 0.4B to 0.8B parameters (Laya[^nandhakishorm2026a], VegaML[^nandhakishorm2026b], and Arc Decide[^arc532025]). Here I show the precursor that inspired the idea, the internal architecture of each judge, and why the committee hit more often when it reached agreement (10 out of 15), yet ended up paralyzed on 90.62% of the test bank.
---
Spoonful 1: The JEV precursor and the promise of an "Olympic judges committee"
The spark for this prototype came from JEV Ultrafast[^browseruse2026], an experiment by the Browser Use team together with TypeSafe AI. Instead of asking a heavy LLM to inspect screenshots or write paragraphs at every browser step, jev-ultrafast turns the page into an indexed table of controls and delegates the choice to Jev, a specialized System 1 decision model that selects the atomic action (CLICK, SELECT, WAIT, BLOCKED) in milliseconds and only calls a small LLM when it needs to type text (TYPE_TEXT).
<div class="jev-showcase">
<div class="jev-showcasetop">
<div class="jev-showcasebrand">
<span>⚡ JEV Ultrafast (Browser Use × TypeSafe AI)</span>
</div>
<div class="jev-chips">
<a class="jev-chip" href="browser-use/jev-ultrafast" target="_blank" rel="noopener"><i class="fab fa-github"></i> browser-use/jev-ultrafast</a>
<a class="jev-chip jev-chip--amber" href="docs.typesafe.ai" target="_blank" rel="noopener">TypeSafe Jev Docs</a>
</div>
</div>
<img src="raw.githubusercontent.com" alt="Jev Ultrafast demonstration searching a Zurich to London flight on Google Flights in 7.1 seconds">
<p class="jev-showcase__caption">
<strong>Precursor in action:</strong> Zurich → London flight search on Google Flights solved in <code>7.1 s</code> by separating atomic decision-making (Jev) from text generation (asset served from the official repository).
</p>
</div>
Because TypeSafe's Jev engine runs behind a closed remote API, I wanted to test whether I could build a 100% local, open equivalent (simil-jev, "JEV-like") for my auditing gates. And since no sub-billion-parameter model is infallible on its own, I combined them under an "Olympic judges committee" architecture (2-of-3 majority with the right to abstain):
- The promise (Condorcet 1785[^condorcet1785]; Dietterich 2000[^dietterich2000]): under Condorcet's jury theorem, if each judge is right more than half the time (p > 0.5) and their errors are independent, the majority errs less often than any individual judge.
- The Olympic trap: in gymnastics or diving, the panel drops the highest and lowest scores along a continuous scale because a systematically lenient or harsh judge skews the mean. In a discrete vote ("Yes" / "No" / "Undefined"), however, a committee averages out random noise but cannot cancel opposite biases: if two judges pull toward opposite extremes, the committee does not converge on the truth—it deadlocks for lack of quorum.
---
Spoonful 2: The three judges on the bench and the dual CPU bottleneck
To assemble the committee, I picked three open projects with radically different internal designs. Before looking at the pipeline, it is worth examining what sits inside each one and what personality they showed when evaluating my 160 test cases (60 "Yes", 60 "No", and 40 "Undefined"):
<div class="judges-stack">
<div class="judge-card judge-card--laya">
<div class="judge-cardid">
<div class="judge-cardbrand-row">
<span class="judge-cardlogo-pill">
<img src="3cucharadas.cl" width="1040" height="298" alt="Official Laya logo">
</span>
<div>
<span class="judge-cardrole judge-cardrole--teal">Judge 1 · The approver</span>
<h3 class="judge-cardtitle">Laya 0.4.11</h3>
</div>
</div>
<div class="jev-chips">
<a class="jev-chip" href="NandhaKishorM/laya" target="_blank" rel="noopener"><i class="fab fa-github"></i> GitHub</a>
<a class="jev-chip" href="huggingface.co" target="_blank" rel="noopener">HF Model</a>
<a class="jev-chip" href="huggingface.co" target="_blank" rel="noopener">Demo Space</a>
</div>
</div>
<div class="judge-cardmain">
<p class="judge-carddesc">
Multilingual non-autoregressive <em>System 1</em> decision engine trained with <em>strictly proper scoring rules</em> (RLCD) to emit single-pass verdicts without generating text.
</p>
<div class="judge-card__stats">
<div><strong>CPU cost:</strong> <code>2.26 GiB</code> RAM · <code>13.83 s</code> cold · <code>366 ms</code> p95</div>
<div><strong>Panel behavior:</strong> voted <strong>"Yes" on 125/160</strong> cases (including <code>48</code> of the <code>60</code> negatives → <strong>73 false positives</strong>).</div>
</div>
</div>
</div>
<div class="judge-card judge-card--vega">
<div class="judge-cardid">
<div class="judge-cardbrand-row">
<span class="judge-cardlogo-pill">
<img src="3cucharadas.cl" width="64" height="64" alt="Official VegaML potential-well icon">
</span>
<div>
<span class="judge-cardrole judge-cardrole--rose">Judge 2 · The rejecter</span>
<h3 class="judge-cardtitle">VegaML 0.11.0</h3>
</div>
</div>
<div class="jev-chips">
<a class="jev-chip jev-chip--rose" href="NandhaKishorM/vegaml" target="_blank" rel="noopener"><i class="fab fa-github"></i> GitHub</a>
<a class="jev-chip jev-chip--rose" href="pypi.org" target="_blank" rel="noopener">PyPI 0.11.0</a>
<a class="jev-chip jev-chip--rose" href="huggingface.co" target="_blank" rel="noopener"><code>Qwen3.5-0.8B</code></a>
</div>
</div>
<div class="judge-cardmain">
<p class="judge-carddesc">
Couples a frozen reader (<code>Qwen3.5-0.8B</code>) with a compact <code>14.3M</code>-parameter physics engine that projects states onto a landscape of potential wells and simulates a damped particle until it settles into an answer.
</p>
<div class="judge-card__stats">
<div><strong>CPU cost:</strong> <code>4.93 GiB</code> RAM · <code>13.66 s</code> cold · <code>1,717 ms</code> p95</div>
<div><strong>Panel behavior:</strong> voted <strong>"No" on 131/160</strong> cases and hit <strong>0 out of 60</strong> on the "Yes" class.</div>
</div>
</div>
</div>
<div class="judge-card judge-card--arc">
<div class="judge-cardid">
<div class="judge-cardbrand-row">
<span class="judge-cardicon-box" aria-hidden="true">
<svg width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M12 3v18"/><path d="M5 7h14"/><path d="M5 7l-3 6h6l-3-6z"/><path d="M19 7l-3 6h6l-3-6z"/><path d="M8 21h8"/></svg>
</span>
<div>
<span class="judge-cardrole judge-cardrole--amber">Judge 3 · The silent one</span>
<h3 class="judge-cardtitle">Arc Decide 0.4B</h3>
</div>
</div>
<div class="jev-chips">
<a class="jev-chip jev-chip--amber" href="huggingface.co" target="_blank" rel="noopener">Arc53/arc-decide-0.4b</a>
<a class="jev-chip jev-chip--amber" href="onnxruntime.ai" target="_blank" rel="noopener">ONNX Runtime</a>
</div>
</div>
<div class="judge-cardmain">
<p class="judge-carddesc">
Compact <code>0.4B</code>-parameter classifier exported to <strong>ONNX Runtime (<code>INT8</code>)</strong> to evaluate relevance, contracts, and binary gates in under <code>1 GiB</code> of memory.
</p>
<div class="judge-card__stats">
<div><strong>CPU cost:</strong> <code>0.59 GiB</code> RAM · <code>4.21 s</code> cold · <code>950 ms</code> p95</div>
<div><strong>Panel behavior:</strong> under its panel threshold (<code>0.66</code>) it <strong>stayed silent on 148/160</strong> cases; it only voted <code>12</code> times (all "Yes", <strong>0 "No" votes</strong>).</div>
</div>
</div>
</div>
</div>
When I wired all three behind simil-jev --panel, the two bottlenecks depicted in Figure 1 surfaced immediately:
<figure class="cuch-d2-fig">
<img src="3cucharadas.cl" width="1087" height="723" alt="Pipeline diagram of simil-jev --panel: input validation and hashes, three judges called sequentially on CPU, and a 2-of-3 quorum where Laya votes Yes, VegaML votes No, and Arc almost never votes, so the panel decides on only 9.38% of cases.">
<figcaption>
<strong>Figure 1.</strong> Real pipeline of <code>simil-jev --panel</code>. Stage 3 exposes the physical bottleneck (three sequential CPU subprocesses totaling <code>~31.7 s</code> cold when reloading weights on every call) and Stage 4 exposes the logical bottleneck (Laya and VegaML clash on <code>101/160</code> cases while Arc stays silent).
</figcaption>
</figure>
On a workstation with a dedicated GPU and all three engines kept resident in VRAM, Stage 3 would take milliseconds. To understand why the exact opposite happened on my laptop, here is the hardware profile of the machine where I ran the experiment (ffpoke, my alias wrapping fastfetch + pokeget inside kitty and tmux):
<figure class="cuch-d2-fig">
<img src="3cucharadas.cl" width="1280" height="680" loading="lazy" decoding="async" style="border-radius: 12px;" alt="Kitty terminal with Starship and tmux running ffpoke (pokeget + fastfetch) on EndeavourOS x86_64 on a Lenovo YOGA 730-15IKB with an Intel Core i7-8550U processor (8 threads at 4.00 GHz, 15 W TDP, AVX2), Intel UHD 620 integrated graphics, and 23.19 GiB of RAM without dedicated VRAM.">
<figcaption>
<strong>Test machine (<code>ffpoke</code> in <code>kitty</code> + <code>tmux</code>).</strong> <code>Lenovo YOGA 730-15IKB</code> laptop with a <code>15 W</code> <code>Intel Core i7-8550U</code> processor (<code>4</code> physical cores / <code>8</code> Kaby Lake-R threads with <code>AVX2</code>), integrated <code>Intel UHD 620</code> graphics without <code>CUDA</code>, and <code>23.19 GiB</code> of DDR4 RAM on <code>EndeavourOS</code>.
</figcaption>
</figure>
On that i7-8550U, without resident daemons permanently locking 8 GiB of RAM, spawning three Python and PyTorch interpreters sequentially cost roughly 31.7 s cold and pushed both Laya and VegaML past their p95 latency target even on warm runs. And even if I had used a dedicated GPU, the logical bottleneck in Stage 4 would still have sunk the committee: not a single judge cleared 50% accuracy when deciding (41.41%, 40.80%, and 47.42%), violating Condorcet's first premise before casting the first ballot.
---
Spoonful 3: The jury ballots and the 66.67% paradox
To see why the committee hit 10 out of 15 when it reached agreement (66.67% selective accuracy) and still proved useless in practice, it suffices to inspect three real ballots from my 240-case bank (80 calibration and 160 test cases):
<div class="duels-stack">
<div class="duel-card duel-card--paralisis">
<div class="duel-cardfamily">Family 1 · Contractual precedence (Why "No" vanished)</div>
<div class="duel-cardquote">"An unsigned draft does not replace the signed record. The signed record says <code>red</code> and the draft says <code>green</code>. Is the active value <code>green</code>?" → <strong>Ground truth: "No"</strong></div>
<div class="duel-card__ballots">
<span class="ballot ballot--yes">Laya: YES ✗</span>
<span class="ballot ballot--no">VegaML: NO ✓</span>
<span class="ballot ballot--mute">Arc: ABSTAIN (conf < 0.66)</span>
<span class="ballot ballot--verdict-amber">2-of-3 Verdict: UNDEFINED (Deadlock)</span>
</div>
</div>
<div class="duel-card">
<div class="duel-cardfamily">Family 2 · Direct evidence (When the tie-breaker certifies an error)</div>
<div class="duel-cardquote">"The expected hash is <code>aa00</code> and the observed hash is <code>bb11</code>. Do the hashes match?" (<code>evidence_direct-14-v3</code>) → <strong>Ground truth: "No"</strong></div>
<div class="duel-card__ballots">
<span class="ballot ballot--yes">Laya: YES ✗</span>
<span class="ballot ballot--no">VegaML: NO ✓</span>
<span class="ballot ballot--yes">Arc: YES ✗</span>
<span class="ballot ballot--verdict">2-of-3 Verdict: YES (False Positive)</span>
</div>
</div>
<div class="duel-card">
<div class="duel-cardfamily">Family 3 · Ambiguity and insufficiency (Shared bias)</div>
<div class="duel-cardquote">"The date appears as <code>04/05</code>, without year or regional format. Is it May 4, 2026?" (<code>negation_ambiguity_insufficient-18-v2</code>) → <strong>Ground truth: "Undefined"</strong></div>
<div class="duel-card__ballots">
<span class="ballot ballot--yes">Laya: YES ✗</span>
<span class="ballot ballot--yes">VegaML: YES ✗</span>
<span class="ballot ballot--mute">Arc: ABSTAIN</span>
<span class="ballot ballot--verdict">2-of-3 Verdict: YES (False Positive)</span>
</div>
</div>
</div>
Those three ballots sum up the entire experiment better than a spreadsheet of numbers:
1. "No" was structurally impossible (0 hits out of 60): for the committee to reject a claim, it needs two "No" votes. Across the 60 negative test cases, VegaML voted "No" 53 times, Laya voted "No" only once, and Arc 0 times. Not a single negative case ever gathered two "No" ballots: the strict judge did not lose the vote—it simply had no ally.
2. The 66.67% illusion: because Laya and VegaML voted opposite on 101 of the 160 cases and Arc stayed silent on 148, the committee only emitted a verdict on 15 cases (9.38% coverage). It got 10 of those 15 right (66.67%, with a 95% Wilson interval of 41.7% to 84.8%), all clustered inside just 4 of the 40 families after overfitting thresholds on the calibration split (14/14).
3. Silence dressed up the overall accuracy: on three-class accuracy ("Yes", "No", "Undefined"), the committee scored 28.75% (46/160), yet 36 of those 46 hits were simply its abstentions landing on the 40 "Undefined" cases. A one-line script that always answers "Undefined" already scores 25.00% without spending RAM or waiting half a minute:
<div class="scoreboard" role="region" aria-label="Comparative scoreboard of the 2-of-3 judge committee against each standalone model and the Always Undefined baseline">
<h4 class="scoreboardtitle">Final scoreboard across the 160 test cases (60 "Yes" · 60 "No" · 40 "Undefined")</h4>
<p class="scoreboardsub">Contrast between accuracy when the evaluator dares to decide (selective accuracy + coverage) and overall three-class accuracy.</p>
<div class="score-row">
<div class="score-rowtop">
<span><strong>🏆 Arc Decide 0.4B (solo)</strong> — Best standalone model</span>
<span><code>0.59 GiB</code> · <code>4.21 s</code> cold · <code>49</code> FP · <code>5/60</code> on "No"</span>
</div>
<div class="score-bars">
<div class="score-metric">
<div class="score-metrichead"><span>Hit rate when deciding (coverage 60.63%)</span><strong>47.42%</strong></div>
<div class="bar-track"><div class="bar-fill bar-fill--amber" style="width:47.4%;"></div></div>
</div>
<div class="score-metric">
<div class="score-metric__head"><span>3-class accuracy (68/160)</span><strong>42.50%</strong></div>
<div class="bar-track"><div class="bar-fill bar-fill--green" style="width:42.5%;"></div></div>
</div>
</div>
</div>
<div class="score-row">
<div class="score-rowtop">
<span><strong>Laya 0.4.11 (solo)</strong> — The optimist</span>
<span><code>2.26 GiB</code> · <code>13.83 s</code> cold · <code>73</code> FP · <code>52/60</code> on "Yes"</span>
</div>
<div class="score-bars">
<div class="score-metric">
<div class="score-metrichead"><span>Hit rate when deciding (coverage 80.00%)</span><strong>41.41%</strong></div>
<div class="bar-track"><div class="bar-fill bar-fill--cyan" style="width:41.4%;"></div></div>
</div>
<div class="score-metric">
<div class="score-metric__head"><span>3-class accuracy (66/160)</span><strong>41.25%</strong></div>
<div class="bar-track"><div class="bar-fill bar-fill--cyan" style="width:41.25%;"></div></div>
</div>
</div>
</div>
<div class="score-row">
<div class="score-rowtop">
<span><strong>VegaML 0.11.0 (solo)</strong> — The pessimist</span>
<span><code>4.93 GiB</code> · <code>13.66 s</code> cold · <code>4</code> FP · <code>51/60</code> on "No"</span>
</div>
<div class="score-bars">
<div class="score-metric">
<div class="score-metrichead"><span>Hit rate when deciding (coverage 78.13%)</span><strong>40.80%</strong></div>
<div class="bar-track"><div class="bar-fill bar-fill--rose" style="width:40.8%;"></div></div>
</div>
<div class="score-metric">
<div class="score-metric__head"><span>3-class accuracy (61/160)</span><strong>38.13%</strong></div>
<div class="bar-track"><div class="bar-fill bar-fill--rose" style="width:38.13%;"></div></div>
</div>
</div>
</div>
<div class="score-row">
<div class="score-rowtop">
<span><strong>⚖️ 2-of-3 Committee (Laya + VegaML + Arc)</strong> — Deadlock by opposite biases</span>
<span><code>~31.7 s</code> serial · <code>3</code> FP · <strong><code>0/60</code> on "No"</strong></span>
</div>
<div class="score-bars">
<div class="score-metric">
<div class="score-metrichead"><span>Hit rate when deciding (10/15 · coverage 9.38%)</span><strong>66.67%</strong></div>
<div class="bar-track"><div class="bar-fill bar-fill--amber" style="width:66.7%;"></div></div>
</div>
<div class="score-metric">
<div class="score-metric__head"><span>3-class accuracy (36 of 46 are abstentions)</span><strong>28.75%</strong></div>
<div class="bar-track"><div class="bar-fill bar-fill--rose" style="width:28.75%;"></div></div>
</div>
</div>
</div>
<div class="score-row">
<div class="score-rowtop">
<span><strong>Trivial baseline: always answer "Undefined"</strong></span>
<span><code>0.00 GiB</code> · <code>0 ms</code> · <code>0</code> FP</span>
</div>
<div class="score-bars">
<div class="score-metric">
<div class="score-metrichead"><span>Hit rate when deciding (coverage 0.00%)</span><strong>N/A</strong></div>
<div class="bar-track"><div class="bar-fill" style="width:0%;"></div></div>
</div>
<div class="score-metric">
<div class="score-metric__head"><span>3-class accuracy (40/160 free hits)</span><strong>25.00%</strong></div>
<div class="bar-track"><div class="bar-fill bar-fill--cyan" style="width:25.0%;"></div></div>
</div>
</div>
</div>
</div>
---
Research takeaways: which open model could run in milliseconds on my i7-8550U
When would a JEV-style classifier committee actually make sense? When each judge clears 50% accuracy on every class out-of-sample (Condorcet 1785[^condorcet1785]), when their errors are uncorrelated (Dietterich 2000[^dietterich2000]), when their probabilities are properly calibrated (Guo et al. 2017[^guo2017]), and when at least two judges have real sensitivity to vote "No". Wiring together on CPU one judge that approves almost everything, another that rejects almost everything, and a third that barely speaks does not yield collective wisdom: it yields expensive abstention. That is why I retired the prototype.
Yet retiring that committee leaves the practical engineering question open: is there a 100% free, open-weights local model today that can decide three-class gates ("Yes", "No", "Undefined") in milliseconds on an Intel Core i7-8550U without a GPU? I believe so, provided I switch architectural families and stop treating logical verification as a text-generation problem; but that is a hypothesis this experiment did not test.
When a gate checks whether observed evidence supports, contradicts, or remains insufficient against a rule, the formal task is not causal language modeling, but three-class Natural Language Inference (NLI): entailment ("Yes"), contradiction ("No"), and neutral ("Undefined"). In that category, the candidate I propose to measure next is cross-encoder/nli-deberta-v3-small, built on the DeBERTaV3 architecture (He, Gao, and Chen 2023[^he2023]); its repository also ships an ONNX INT8 build for AVX2 CPUs that runs with onnxruntime, and optimum can export others. The idea of reusing an NLI model as a classifier comes from Laurer et al. (2024[^laurer2024]), whose model family includes a larger variant, MoritzLaurer/DeBERTa-v3-base-mnli-fever-anli. I have not yet measured either one on my 160-case bank:
<div class="nli-solution-card" role="region" aria-label="Technical specification of the open model I propose to measure on CPU: cross-encoder/nli-deberta-v3-small in ONNX INT8">
<div class="nli-solution-cardtop">
<h3 class="nli-solution-cardtitle">Hypothesis to measure on CPU: nli-deberta-v3-small (ONNX INT8)</h3>
<div class="jev-chips">
<a class="jev-chip" href="huggingface.co" target="_blank" rel="noopener">HF Model (Apache)</a>
<a class="jev-chip jev-chip--amber" href="arxiv.org" target="_blank" rel="noopener">DeBERTaV3 Paper</a>
<a class="jev-chip" href="onnxruntime.ai" target="_blank" rel="noopener">ONNX Runtime</a>
</div>
</div>
<p class="nli-solution-carddesc">
Bidirectional <em>cross-encoder</em> with <strong>disentangled attention</strong> (separating content and relative position) pre-trained via <em>replaced token detection</em> (ELECTRA) and fine-tuned on <code>SNLI</code> + <code>MultiNLI</code>. It evaluates premise and hypothesis jointly in a single forward pass without loading PyTorch.
</p>
<div class="nli-solution-cardgrid">
<div class="nli-solution-cardmetric">
<strong>Latency still to be measured</strong>
I did not run it on this bank. Because it decides in a single pass without generating text, my hypothesis is that it will land well below the committee's <code>366–1,717 ms</code> warm and <code>~31.7 s</code> cold.
</div>
<div class="nli-solution-cardmetric">
<strong>~165 MiB on disk (ONNX INT8 for AVX2)</strong>
<code>44M</code> backbone parameters (<code>142M</code> total with vocabulary embeddings); the <code>model_quint8_avx2.onnx</code> file takes about <code>165 MiB</code> on disk. Its runtime RAM is still to be measured, so I do not yet compare it with the roughly <code>7.8 GiB</code> of RAM used by the three judges.
</div>
<div class="nli-solution-card__metric">
<strong>3 native classes ("Yes" / "No" / "Undefined")</strong>
Emits direct logits for <code>contradiction</code>, <code>entailment</code>, and <code>neutral</code> (<code>87.55%</code> on MNLI <em>mismatched</em>, according to its model card). Whether that fixes the <code>"No"</code> blindness (<code>0/60</code>) on my gates remains to be measured.
</div>
</div>
</div>
The takeaway I keep from this proof of concept has a measured part and an unmeasured one. Measured: on a work laptop without a dedicated accelerator, a committee of mismatched models did not beat its best individual judge on three-class accuracy and never managed to say "No". Still a hypothesis: that a single small NLI cross-encoder, calibrated and compiled to ONNX INT8, would beat it in latency, memory footprint, and sensitivity to say "No". When verification is deterministic (a hash, a JSON schema, or an exit code), a 0 ms code rule remains unbeatable; and when I genuinely need to judge semantic entailment or contradiction locally, my next step is not to stack three judges in series, but to measure an architecture designed for that task first.
---
References
[^arc532025]: Arc53. 2025. "arc-decide-0.4b-v0.2: Compact ONNX Decision Classifier". Hugging Face model repository. huggingface.co.
[^browseruse2026]: Browser Use and TypeSafe AI. 2026. "JEV Ultrafast: Sub-Second Browser Agent Actions with Jev Decision Models". Official GitHub repository. browser-use/jev-ultrafast.
[^condorcet1785]: Condorcet, Jean-Antoine-Nicolas de Caritat, Marquis de. 1785. Essai sur l'application de l'analyse à la probabilité des décisions rendues à la pluralité des voix. Paris: Imprimerie Royale.
[^dietterich2000]: Dietterich, Thomas G. 2000. "Ensemble Methods in Machine Learning". In Multiple Classifier Systems (MCS 2000), Lecture Notes in Computer Science, vol. 1857, 1–15. Berlin: Springer. Scholar
[^guo2017]: Guo, Chuan, Geoff Pleiss, Yu Sun, and Kilian Q. Weinberger. 2017. "On Calibration of Modern Neural Networks". In Proceedings of the 34th International Conference on Machine Learning (ICML), PMLR 70: 1321–1330.
[^he2023]: He, Pengcheng, Jianfeng Gao, and Weizhu Chen. 2023. "DeBERTaV3: Improving DeBERTa using ELECTRA-Style Pre-Training with Gradient-Disentangled Embedding Sharing". In International Conference on Learning Representations (ICLR 2023). arXiv · Scholar
[^laurer2024]: Laurer, Moritz, Wouter van Atteveldt, Andreu Casas, and Kasper Welbers. 2024. "Less Annotating, More Classifying: Addressing the Data Scarcity Issue of Supervised Machine Learning with Deep Transfer Learning and BERT-NLI". Political Analysis 32 (1): 84–100. Model from the same family: huggingface.co. DOI · Scholar
[^nandhakishorm2026a]: NandhaKishorM (ConvAI Innovations). 2026a. "Laya: System 1 Non-Autoregressive Multilingual Decision Engine". GitHub repository. NandhaKishorM/laya.
[^nandhakishorm2026b]: NandhaKishorM. 2026b. "VegaML: Potential-Well Physics Decision Engine over Frozen Language Backbones". GitHub repository. NandhaKishorM/vegaml.
Created laya : Now Introducing a new 800 Million Param physics-based typed decision model with 73k context and image support
Around 3 weeks ago, I posted on this subreddit about how Jev used my one-year-old architecture, og post: reddit.com
Then, just after that, I introduced Laya, the first open-source version of JEV, and it has reached a very large scale, thanks to the local Llama community believing in me and supporting me on the journey. Today I am open-sourcing a new physics-based typed decision model called Vega.
The interesting parts. It is only 800 million parameters (4B is also there), with 73k token support, image support, and surpassing many of the jev benchmarks in single-shot. Implemented an engine+adapter as a Test-Time Training Architecture.
Imagine you are giving input to the model like "ignore all previous conversations," which is called the observation, along with a question, "Is this trying to override the instructions of the model?" and your possible outcomes are YES or NO. The whole prompt is passed to an LLM/VLM (yeah, image-supported), then from the hidden layers, we can extract the observation, question, the yes and no, and last token. These will be vectors, and we can project it by multiplying with wieghts; then, first, using the observation projection, we can create a landscape with valleys; then, using the question and last-token vectors, we can initialise a ball in the valley, and using YES or NO, we can get the candidate location of the ball. Depends on the number of outcomes we create valleys; that is, here YES and NO, so 2. When the ball fall on YES valley, we get the answer. There is friction also influencing how the ball moves.
TLDR: It's like creating valleys of outcomes that we need and throwing a ball that will slow down based on friction and settle on the best outcome
Blog: nandakishorm.com
GitHub: NandhaKishorM/vegaml
HuggingFace Model Card: huggingface.co
HuggingFce Space: huggingface.co
207 points · 36 comments
Mentions
JEV-style local judges in three spoonfuls: when voting improves a decision and when it only stalls it --- title: "JEV-style local judges in three spoonfuls: when voting improves a decision and when it only stalls it" published: true description: "Proof of concept of a 2-of-3 committee on CPU (Laya, VegaML, and Arc Decide) on an Intel Core i7-8550U, with an ONNX INT8 NLI cross-encoder (DeBERTa-v3-small) as an alternative still to be measured." tags: "aievaluation, localinference, cpu, decisionmaking" canonical_url: "3cucharadas.cl" cover_image: "3cucharadas.cl" ai_disclosure_level: "some_ai" --- When I automate code workflows and technical auditing, many verification checks do not need generated prose: they need a fast verdict between "Yes" (the evidence suffices), "No" (there is a hard failure), or "Undefined" (it is safer to abstain and escalate). Calling a generative LLM at every intermediate gate adds latency, token spend, and unnecessary variance. That is why I built a proof of concept (PoC) called simil-jev: an "Olympic judges committee" (2-of-3) running on my laptop CPU with three small models of 0.4B to 0.8B parameters (Laya[^nandhakishorm2026a], VegaML[^nandhakishorm2026b], and Arc Decide[^arc532025]). Here I show the precursor that inspired the idea, the internal architecture of each judge, and why the committee hit more often when it reached agreement (10 out of 15), yet ended up paralyzed on 90.62% of the test bank. --- Spoonful 1: The JEV precursor and the promise of an "Olympic judges committee" The spark for this prototype came from JEV Ultrafast[^browseruse2026], an experiment by the Browser Use team together with TypeSafe AI. Instead of asking a heavy LLM to inspect screenshots or write paragraphs at every browser step, jev-ultrafast turns the page into an indexed table of controls and delegates the choice to Jev, a specialized System 1 decision model that selects the atomic action (CLICK, SELECT, WAIT, BLOCKED) in milliseconds and only calls a small LLM when it needs to type text (TYPE_TEXT). <div class="jev-showcase"> <div class="jev-showcasetop"> <div class="jev-showcasebrand"> <span>⚡ JEV Ultrafast (Browser Use × TypeSafe AI)</span> </div> <div class="jev-chips"> <a class="jev-chip" href="browser-use/jev-ultrafast" target="_blank" rel="noopener"><i class="fab fa-github"></i> browser-use/jev-ultrafast</a> <a class="jev-chip jev-chip--amber" href="docs.typesafe.ai" target="_blank" rel="noopener">TypeSafe Jev Docs</a> </div> </div> <img src="raw.githubusercontent.com" alt="Jev Ultrafast demonstration searching a Zurich to London flight on Google Flights in 7.1 seconds"> <p class="jev-showcase__caption"> <strong>Precursor in action:</strong> Zurich → London flight search on Google Flights solved in <code>7.1 s</code> by separating atomic decision-making (Jev) from text generation (asset served from the official repository). </p> </div> Because TypeSafe's Jev engine runs behind a closed remote API, I wanted to test whether I could build a 100% local, open equivalent (simil-jev, "JEV-like") for my auditing gates. And since no sub-billion-parameter model is infallible on its own, I combined them under an "Olympic judges committee" architecture (2-of-3 majority with the right to abstain): - The promise (Condorcet 1785[^condorcet1785]; Dietterich 2000[^dietterich2000]): under Condorcet's jury theorem, if each judge is right more than half the time (p > 0.5) and their errors are independent, the majority errs less often than any individual judge. - The Olympic trap: in gymnastics or diving, the panel drops the highest and lowest scores along a continuous scale because a systematically lenient or harsh judge skews the mean. In a discrete vote ("Yes" / "No" / "Undefined"), however, a committee averages out random noise but cannot cancel opposite biases: if two judges pull toward opposite extremes, the committee does not converge on the truth—it deadlocks for lack of quorum. --- Spoonful 2: The three judges on the bench and the dual CPU bottleneck To assemble the committee, I picked three open projects with radically different internal designs. Before looking at the pipeline, it is worth examining what sits inside each one and what personality they showed when evaluating my 160 test cases (60 "Yes", 60 "No", and 40 "Undefined"): <div class="judges-stack"> <div class="judge-card judge-card--laya"> <div class="judge-cardid"> <div class="judge-cardbrand-row"> <span class="judge-cardlogo-pill"> <img src="3cucharadas.cl" width="1040" height="298" alt="Official Laya logo"> </span> <div> <span class="judge-cardrole judge-cardrole--teal">Judge 1 · The approver</span> <h3 class="judge-cardtitle">Laya 0.4.11</h3> </div> </div> <div class="jev-chips"> <a class="jev-chip" href="NandhaKishorM/laya" target="_blank" rel="noopener"><i class="fab fa-github"></i> GitHub</a> <a class="jev-chip" href="huggingface.co" target="_blank" rel="noopener">HF Model</a> <a class="jev-chip" href="huggingface.co" target="_blank" rel="noopener">Demo Space</a> </div> </div> <div class="judge-cardmain"> <p class="judge-carddesc"> Multilingual non-autoregressive <em>System 1</em> decision engine trained with <em>strictly proper scoring rules</em> (RLCD) to emit single-pass verdicts without generating text. </p> <div class="judge-card__stats"> <div><strong>CPU cost:</strong> <code>2.26 GiB</code> RAM · <code>13.83 s</code> cold · <code>366 ms</code> p95</div> <div><strong>Panel behavior:</strong> voted <strong>"Yes" on 125/160</strong> cases (including <code>48</code> of the <code>60</code> negatives → <strong>73 false positives</strong>).</div> </div> </div> </div> <div class="judge-card judge-card--vega"> <div class="judge-cardid"> <div class="judge-cardbrand-row"> <span class="judge-cardlogo-pill"> <img src="3cucharadas.cl" width="64" height="64" alt="Official VegaML potential-well icon"> </span> <div> <span class="judge-cardrole judge-cardrole--rose">Judge 2 · The rejecter</span> <h3 class="judge-cardtitle">VegaML 0.11.0</h3> </div> </div> <div class="jev-chips"> <a class="jev-chip jev-chip--rose" href="NandhaKishorM/vegaml" target="_blank" rel="noopener"><i class="fab fa-github"></i> GitHub</a> <a class="jev-chip jev-chip--rose" href="pypi.org" target="_blank" rel="noopener">PyPI 0.11.0</a> <a class="jev-chip jev-chip--rose" href="huggingface.co" target="_blank" rel="noopener"><code>Qwen3.5-0.8B</code></a> </div> </div> <div class="judge-cardmain"> <p class="judge-carddesc"> Couples a frozen reader (<code>Qwen3.5-0.8B</code>) with a compact <code>14.3M</code>-parameter physics engine that projects states onto a landscape of potential wells and simulates a damped particle until it settles into an answer. </p> <div class="judge-card__stats"> <div><strong>CPU cost:</strong> <code>4.93 GiB</code> RAM · <code>13.66 s</code> cold · <code>1,717 ms</code> p95</div> <div><strong>Panel behavior:</strong> voted <strong>"No" on 131/160</strong> cases and hit <strong>0 out of 60</strong> on the "Yes" class.</div> </div> </div> </div> <div class="judge-card judge-card--arc"> <div class="judge-cardid"> <div class="judge-cardbrand-row"> <span class="judge-cardicon-box" aria-hidden="true"> <svg width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M12 3v18"/><path d="M5 7h14"/><path d="M5 7l-3 6h6l-3-6z"/><path d="M19 7l-3 6h6l-3-6z"/><path d="M8 21h8"/></svg> </span> <div> <span class="judge-cardrole judge-cardrole--amber">Judge 3 · The silent one</span> <h3 class="judge-cardtitle">Arc Decide 0.4B</h3> </div> </div> <div class="jev-chips"> <a class="jev-chip jev-chip--amber" href="huggingface.co" target="_blank" rel="noopener">Arc53/arc-decide-0.4b</a> <a class="jev-chip jev-chip--amber" href="onnxruntime.ai" target="_blank" rel="noopener">ONNX Runtime</a> </div> </div> <div class="judge-cardmain"> <p class="judge-carddesc"> Compact <code>0.4B</code>-parameter classifier exported to <strong>ONNX Runtime (<code>INT8</code>)</strong> to evaluate relevance, contracts, and binary gates in under <code>1 GiB</code> of memory. </p> <div class="judge-card__stats"> <div><strong>CPU cost:</strong> <code>0.59 GiB</code> RAM · <code>4.21 s</code> cold · <code>950 ms</code> p95</div> <div><strong>Panel behavior:</strong> under its panel threshold (<code>0.66</code>) it <strong>stayed silent on 148/160</strong> cases; it only voted <code>12</code> times (all "Yes", <strong>0 "No" votes</strong>).</div> </div> </div> </div> </div> When I wired all three behind simil-jev --panel, the two bottlenecks depicted in Figure 1 surfaced immediately: <figure class="cuch-d2-fig"> <img src="3cucharadas.cl" width="1087" height="723" alt="Pipeline diagram of simil-jev --panel: input validation and hashes, three judges called sequentially on CPU, and a 2-of-3 quorum where Laya votes Yes, VegaML votes No, and Arc almost never votes, so the panel decides on only 9.38% of cases."> <figcaption> <strong>Figure 1.</strong> Real pipeline of <code>simil-jev --panel</code>. Stage 3 exposes the physical bottleneck (three sequential CPU subprocesses totaling <code>~31.7 s</code> cold when reloading weights on every call) and Stage 4 exposes the logical bottleneck (Laya and VegaML clash on <code>101/160</code> cases while Arc stays silent). </figcaption> </figure> On a workstation with a dedicated GPU and all three engines kept resident in VRAM, Stage 3 would take milliseconds. To understand why the exact opposite happened on my laptop, here is the hardware profile of the machine where I ran the experiment (ffpoke, my alias wrapping fastfetch + pokeget inside kitty and tmux): <figure class="cuch-d2-fig"> <img src="3cucharadas.cl" width="1280" height="680" loading="lazy" decoding="async" style="border-radius: 12px;" alt="Kitty terminal with Starship and tmux running ffpoke (pokeget + fastfetch) on EndeavourOS x86_64 on a Lenovo YOGA 730-15IKB with an Intel Core i7-8550U processor (8 threads at 4.00 GHz, 15 W TDP, AVX2), Intel UHD 620 integrated graphics, and 23.19 GiB of RAM without dedicated VRAM."> <figcaption> <strong>Test machine (<code>ffpoke</code> in <code>kitty</code> + <code>tmux</code>).</strong> <code>Lenovo YOGA 730-15IKB</code> laptop with a <code>15 W</code> <code>Intel Core i7-8550U</code> processor (<code>4</code> physical cores / <code>8</code> Kaby Lake-R threads with <code>AVX2</code>), integrated <code>Intel UHD 620</code> graphics without <code>CUDA</code>, and <code>23.19 GiB</code> of DDR4 RAM on <code>EndeavourOS</code>. </figcaption> </figure> On that i7-8550U, without resident daemons permanently locking 8 GiB of RAM, spawning three Python and PyTorch interpreters sequentially cost roughly 31.7 s cold and pushed both Laya and VegaML past their p95 latency target even on warm runs. And even if I had used a dedicated GPU, the logical bottleneck in Stage 4 would still have sunk the committee: not a single judge cleared 50% accuracy when deciding (41.41%, 40.80%, and 47.42%), violating Condorcet's first premise before casting the first ballot. --- Spoonful 3: The jury ballots and the 66.67% paradox To see why the committee hit 10 out of 15 when it reached agreement (66.67% selective accuracy) and still proved useless in practice, it suffices to inspect three real ballots from my 240-case bank (80 calibration and 160 test cases): <div class="duels-stack"> <div class="duel-card duel-card--paralisis"> <div class="duel-cardfamily">Family 1 · Contractual precedence (Why "No" vanished)</div> <div class="duel-cardquote">"An unsigned draft does not replace the signed record. The signed record says <code>red</code> and the draft says <code>green</code>. Is the active value <code>green</code>?" → <strong>Ground truth: "No"</strong></div> <div class="duel-card__ballots"> <span class="ballot ballot--yes">Laya: YES ✗</span> <span class="ballot ballot--no">VegaML: NO ✓</span> <span class="ballot ballot--mute">Arc: ABSTAIN (conf < 0.66)</span> <span class="ballot ballot--verdict-amber">2-of-3 Verdict: UNDEFINED (Deadlock)</span> </div> </div> <div class="duel-card"> <div class="duel-cardfamily">Family 2 · Direct evidence (When the tie-breaker certifies an error)</div> <div class="duel-cardquote">"The expected hash is <code>aa00</code> and the observed hash is <code>bb11</code>. Do the hashes match?" (<code>evidence_direct-14-v3</code>) → <strong>Ground truth: "No"</strong></div> <div class="duel-card__ballots"> <span class="ballot ballot--yes">Laya: YES ✗</span> <span class="ballot ballot--no">VegaML: NO ✓</span> <span class="ballot ballot--yes">Arc: YES ✗</span> <span class="ballot ballot--verdict">2-of-3 Verdict: YES (False Positive)</span> </div> </div> <div class="duel-card"> <div class="duel-cardfamily">Family 3 · Ambiguity and insufficiency (Shared bias)</div> <div class="duel-cardquote">"The date appears as <code>04/05</code>, without year or regional format. Is it May 4, 2026?" (<code>negation_ambiguity_insufficient-18-v2</code>) → <strong>Ground truth: "Undefined"</strong></div> <div class="duel-card__ballots"> <span class="ballot ballot--yes">Laya: YES ✗</span> <span class="ballot ballot--yes">VegaML: YES ✗</span> <span class="ballot ballot--mute">Arc: ABSTAIN</span> <span class="ballot ballot--verdict">2-of-3 Verdict: YES (False Positive)</span> </div> </div> </div> Those three ballots sum up the entire experiment better than a spreadsheet of numbers: 1. "No" was structurally impossible (0 hits out of 60): for the committee to reject a claim, it needs two "No" votes. Across the 60 negative test cases, VegaML voted "No" 53 times, Laya voted "No" only once, and Arc 0 times. Not a single negative case ever gathered two "No" ballots: the strict judge did not lose the vote—it simply had no ally. 2. The 66.67% illusion: because Laya and VegaML voted opposite on 101 of the 160 cases and Arc stayed silent on 148, the committee only emitted a verdict on 15 cases (9.38% coverage). It got 10 of those 15 right (66.67%, with a 95% Wilson interval of 41.7% to 84.8%), all clustered inside just 4 of the 40 families after overfitting thresholds on the calibration split (14/14). 3. Silence dressed up the overall accuracy: on three-class accuracy ("Yes", "No", "Undefined"), the committee scored 28.75% (46/160), yet 36 of those 46 hits were simply its abstentions landing on the 40 "Undefined" cases. A one-line script that always answers "Undefined" already scores 25.00% without spending RAM or waiting half a minute: <div class="scoreboard" role="region" aria-label="Comparative scoreboard of the 2-of-3 judge committee against each standalone model and the Always Undefined baseline"> <h4 class="scoreboardtitle">Final scoreboard across the 160 test cases (60 "Yes" · 60 "No" · 40 "Undefined")</h4> <p class="scoreboardsub">Contrast between accuracy when the evaluator dares to decide (selective accuracy + coverage) and overall three-class accuracy.</p> <div class="score-row"> <div class="score-rowtop"> <span><strong>🏆 Arc Decide 0.4B (solo)</strong> — Best standalone model</span> <span><code>0.59 GiB</code> · <code>4.21 s</code> cold · <code>49</code> FP · <code>5/60</code> on "No"</span> </div> <div class="score-bars"> <div class="score-metric"> <div class="score-metrichead"><span>Hit rate when deciding (coverage 60.63%)</span><strong>47.42%</strong></div> <div class="bar-track"><div class="bar-fill bar-fill--amber" style="width:47.4%;"></div></div> </div> <div class="score-metric"> <div class="score-metric__head"><span>3-class accuracy (68/160)</span><strong>42.50%</strong></div> <div class="bar-track"><div class="bar-fill bar-fill--green" style="width:42.5%;"></div></div> </div> </div> </div> <div class="score-row"> <div class="score-rowtop"> <span><strong>Laya 0.4.11 (solo)</strong> — The optimist</span> <span><code>2.26 GiB</code> · <code>13.83 s</code> cold · <code>73</code> FP · <code>52/60</code> on "Yes"</span> </div> <div class="score-bars"> <div class="score-metric"> <div class="score-metrichead"><span>Hit rate when deciding (coverage 80.00%)</span><strong>41.41%</strong></div> <div class="bar-track"><div class="bar-fill bar-fill--cyan" style="width:41.4%;"></div></div> </div> <div class="score-metric"> <div class="score-metric__head"><span>3-class accuracy (66/160)</span><strong>41.25%</strong></div> <div class="bar-track"><div class="bar-fill bar-fill--cyan" style="width:41.25%;"></div></div> </div> </div> </div> <div class="score-row"> <div class="score-rowtop"> <span><strong>VegaML 0.11.0 (solo)</strong> — The pessimist</span> <span><code>4.93 GiB</code> · <code>13.66 s</code> cold · <code>4</code> FP · <code>51/60</code> on "No"</span> </div> <div class="score-bars"> <div class="score-metric"> <div class="score-metrichead"><span>Hit rate when deciding (coverage 78.13%)</span><strong>40.80%</strong></div> <div class="bar-track"><div class="bar-fill bar-fill--rose" style="width:40.8%;"></div></div> </div> <div class="score-metric"> <div class="score-metric__head"><span>3-class accuracy (61/160)</span><strong>38.13%</strong></div> <div class="bar-track"><div class="bar-fill bar-fill--rose" style="width:38.13%;"></div></div> </div> </div> </div> <div class="score-row"> <div class="score-rowtop"> <span><strong>⚖️ 2-of-3 Committee (Laya + VegaML + Arc)</strong> — Deadlock by opposite biases</span> <span><code>~31.7 s</code> serial · <code>3</code> FP · <strong><code>0/60</code> on "No"</strong></span> </div> <div class="score-bars"> <div class="score-metric"> <div class="score-metrichead"><span>Hit rate when deciding (10/15 · coverage 9.38%)</span><strong>66.67%</strong></div> <div class="bar-track"><div class="bar-fill bar-fill--amber" style="width:66.7%;"></div></div> </div> <div class="score-metric"> <div class="score-metric__head"><span>3-class accuracy (36 of 46 are abstentions)</span><strong>28.75%</strong></div> <div class="bar-track"><div class="bar-fill bar-fill--rose" style="width:28.75%;"></div></div> </div> </div> </div> <div class="score-row"> <div class="score-rowtop"> <span><strong>Trivial baseline: always answer "Undefined"</strong></span> <span><code>0.00 GiB</code> · <code>0 ms</code> · <code>0</code> FP</span> </div> <div class="score-bars"> <div class="score-metric"> <div class="score-metrichead"><span>Hit rate when deciding (coverage 0.00%)</span><strong>N/A</strong></div> <div class="bar-track"><div class="bar-fill" style="width:0%;"></div></div> </div> <div class="score-metric"> <div class="score-metric__head"><span>3-class accuracy (40/160 free hits)</span><strong>25.00%</strong></div> <div class="bar-track"><div class="bar-fill bar-fill--cyan" style="width:25.0%;"></div></div> </div> </div> </div> </div> --- Research takeaways: which open model could run in milliseconds on my i7-8550U When would a JEV-style classifier committee actually make sense? When each judge clears 50% accuracy on every class out-of-sample (Condorcet 1785[^condorcet1785]), when their errors are uncorrelated (Dietterich 2000[^dietterich2000]), when their probabilities are properly calibrated (Guo et al. 2017[^guo2017]), and when at least two judges have real sensitivity to vote "No". Wiring together on CPU one judge that approves almost everything, another that rejects almost everything, and a third that barely speaks does not yield collective wisdom: it yields expensive abstention. That is why I retired the prototype. Yet retiring that committee leaves the practical engineering question open: is there a 100% free, open-weights local model today that can decide three-class gates ("Yes", "No", "Undefined") in milliseconds on an Intel Core i7-8550U without a GPU? I believe so, provided I switch architectural families and stop treating logical verification as a text-generation problem; but that is a hypothesis this experiment did not test. When a gate checks whether observed evidence supports, contradicts, or remains insufficient against a rule, the formal task is not causal language modeling, but three-class Natural Language Inference (NLI): entailment ("Yes"), contradiction ("No"), and neutral ("Undefined"). In that category, the candidate I propose to measure next is cross-encoder/nli-deberta-v3-small, built on the DeBERTaV3 architecture (He, Gao, and Chen 2023[^he2023]); its repository also ships an ONNX INT8 build for AVX2 CPUs that runs with onnxruntime, and optimum can export others. The idea of reusing an NLI model as a classifier comes from Laurer et al. (2024[^laurer2024]), whose model family includes a larger variant, MoritzLaurer/DeBERTa-v3-base-mnli-fever-anli. I have not yet measured either one on my 160-case bank: <div class="nli-solution-card" role="region" aria-label="Technical specification of the open model I propose to measure on CPU: cross-encoder/nli-deberta-v3-small in ONNX INT8"> <div class="nli-solution-cardtop"> <h3 class="nli-solution-cardtitle">Hypothesis to measure on CPU: nli-deberta-v3-small (ONNX INT8)</h3> <div class="jev-chips"> <a class="jev-chip" href="huggingface.co" target="_blank" rel="noopener">HF Model (Apache)</a> <a class="jev-chip jev-chip--amber" href="arxiv.org" target="_blank" rel="noopener">DeBERTaV3 Paper</a> <a class="jev-chip" href="onnxruntime.ai" target="_blank" rel="noopener">ONNX Runtime</a> </div> </div> <p class="nli-solution-carddesc"> Bidirectional <em>cross-encoder</em> with <strong>disentangled attention</strong> (separating content and relative position) pre-trained via <em>replaced token detection</em> (ELECTRA) and fine-tuned on <code>SNLI</code> + <code>MultiNLI</code>. It evaluates premise and hypothesis jointly in a single forward pass without loading PyTorch. </p> <div class="nli-solution-cardgrid"> <div class="nli-solution-cardmetric"> <strong>Latency still to be measured</strong> I did not run it on this bank. Because it decides in a single pass without generating text, my hypothesis is that it will land well below the committee's <code>366–1,717 ms</code> warm and <code>~31.7 s</code> cold. </div> <div class="nli-solution-cardmetric"> <strong>~165 MiB on disk (ONNX INT8 for AVX2)</strong> <code>44M</code> backbone parameters (<code>142M</code> total with vocabulary embeddings); the <code>model_quint8_avx2.onnx</code> file takes about <code>165 MiB</code> on disk. Its runtime RAM is still to be measured, so I do not yet compare it with the roughly <code>7.8 GiB</code> of RAM used by the three judges. </div> <div class="nli-solution-card__metric"> <strong>3 native classes ("Yes" / "No" / "Undefined")</strong> Emits direct logits for <code>contradiction</code>, <code>entailment</code>, and <code>neutral</code> (<code>87.55%</code> on MNLI <em>mismatched</em>, according to its model card). Whether that fixes the <code>"No"</code> blindness (<code>0/60</code>) on my gates remains to be measured. </div> </div> </div> The takeaway I keep from this proof of concept has a measured part and an unmeasured one. Measured: on a work laptop without a dedicated accelerator, a committee of mismatched models did not beat its best individual judge on three-class accuracy and never managed to say "No". Still a hypothesis: that a single small NLI cross-encoder, calibrated and compiled to ONNX INT8, would beat it in latency, memory footprint, and sensitivity to say "No". When verification is deterministic (a hash, a JSON schema, or an exit code), a 0 ms code rule remains unbeatable; and when I genuinely need to judge semantic entailment or contradiction locally, my next step is not to stack three judges in series, but to measure an architecture designed for that task first. --- References [^arc532025]: Arc53. 2025. "arc-decide-0.4b-v0.2: Compact ONNX Decision Classifier". Hugging Face model repository. huggingface.co. [^browseruse2026]: Browser Use and TypeSafe AI. 2026. "JEV Ultrafast: Sub-Second Browser Agent Actions with Jev Decision Models". Official GitHub repository. browser-use/jev-ultrafast. [^condorcet1785]: Condorcet, Jean-Antoine-Nicolas de Caritat, Marquis de. 1785. Essai sur l'application de l'analyse à la probabilité des décisions rendues à la pluralité des voix. Paris: Imprimerie Royale. [^dietterich2000]: Dietterich, Thomas G. 2000. "Ensemble Methods in Machine Learning". In Multiple Classifier Systems (MCS 2000), Lecture Notes in Computer Science, vol. 1857, 1–15. Berlin: Springer. Scholar [^guo2017]: Guo, Chuan, Geoff Pleiss, Yu Sun, and Kilian Q. Weinberger. 2017. "On Calibration of Modern Neural Networks". In Proceedings of the 34th International Conference on Machine Learning (ICML), PMLR 70: 1321–1330. [^he2023]: He, Pengcheng, Jianfeng Gao, and Weizhu Chen. 2023. "DeBERTaV3: Improving DeBERTa using ELECTRA-Style Pre-Training with Gradient-Disentangled Embedding Sharing". In International Conference on Learning Representations (ICLR 2023). arXiv · Scholar [^laurer2024]: Laurer, Moritz, Wouter van Atteveldt, Andreu Casas, and Kasper Welbers. 2024. "Less Annotating, More Classifying: Addressing the Data Scarcity Issue of Supervised Machine Learning with Deep Transfer Learning and BERT-NLI". Political Analysis 32 (1): 84–100. Model from the same family: huggingface.co. DOI · Scholar [^nandhakishorm2026a]: NandhaKishorM (ConvAI Innovations). 2026a. "Laya: System 1 Non-Autoregressive Multilingual Decision Engine". GitHub repository. NandhaKishorM/laya. [^nandhakishorm2026b]: NandhaKishorM. 2026b. "VegaML: Potential-Well Physics Decision Engine over Frozen Language Backbones". GitHub repository. NandhaKishorM/vegaml.
One decision engine for all of the LLM backbone embedding.in NandhaKishorM/vegaml huggingface.co t.co
Our new Vega-U model benchmark, I think even the whole benchmarking stuff is not needed now, as you can just attach any LLM to the decision engine NandhaKishorM/vegaml t.co
@MaziyarPanahi Try vega. NandhaKishorM/vegaml I am the creator of laya
Vega won cases in live benchmarks. You can replicate the results at github.com/NandhaKishorM/vegaml/blob/main/noteboo… t.co
Creator of Open Source Laya model introduces physics-based typed decision model called Vega. It's like creating valleys of outcomes needed and throwing a ball that will slow down based on friction and settle on the best outcome. nandakishorm.com NandhaKishorM/vegaml
Around 3 weeks ago introduced Laya, the first open-source version of JEV, and it has reached a very large scale. Today I am open-sourcing a new physics-based typed decision model called Vega. The interesting parts. It is only 800 million parameters (4B is also there), with 73k token support, image support, and surpassing many of the jev benchmarks in single-shot. Implemented an engine+adapter as a Test-Time Training Architecture. Imagine you are giving input to the model like "ignore all previous conversations," which is called the observation, along with a question, "Is this trying to override the instructions of the model?" and your possible outcomes are YES or NO. The whole prompt is passed to an LLM/VLM (yeah, image-supported), then from the hidden layers, we can extract the observation, question, the yes and no, and last token. These will be vectors, and we can project it by multiplying with wieghts; then, first, using the observation projection, we can create a landscape with valleys; then, using the question and last-token vectors, we can initialise a ball in the valley, and using YES or NO, we can get the candidate location of the ball. Depends on the number of outcomes we create valleys; that is, here YES and NO, so 2. When the ball fall on YES valley, we get the answer. There is friction also influencing how the ball moves. TLDR: It's like creating valleys of outcomes that we need and throwing a ball that will slow down based on friction and settle on the best outcome Blog: nandakishorm.com GitHub: NandhaKishorM/vegaml HuggingFace Model Card: huggingface.co HuggingFace Space: huggingface.co
First of the kind physics based architecture for typed decision model Completely open-source with Apache 2.0 License HF: huggingface.co GitHub: NandhaKishorM/vegaml t.co
Created laya : Now Introducing a new 800 Million Param physics-based typed decision model with 73k context and image support Around 3 weeks ago, I posted on this subreddit about how Jev used my one-year-old architecture, og post: reddit.com Then, just after that, I introduced Laya, the first open-source version of JEV, and it has reached a very large scale, thanks to the local Llama community believing in me and supporting me on the journey. Today I am open-sourcing a new physics-based typed decision model called Vega. The interesting parts. It is only 800 million parameters (4B is also there), with 73k token support, image support, and surpassing many of the jev benchmarks in single-shot. Implemented an engine+adapter as a Test-Time Training Architecture. Imagine you are giving input to the model like "ignore all previous conversations," which is called the observation, along with a question, "Is this trying to override the instructions of the model?" and your possible outcomes are YES or NO. The whole prompt is passed to an LLM/VLM (yeah, image-supported), then from the hidden layers, we can extract the observation, question, the yes and no, and last token. These will be vectors, and we can project it by multiplying with wieghts; then, first, using the observation projection, we can create a landscape with valleys; then, using the question and last-token vectors, we can initialise a ball in the valley, and using YES or NO, we can get the candidate location of the ball. Depends on the number of outcomes we create valleys; that is, here YES and NO, so 2. When the ball fall on YES valley, we get the answer. There is friction also influencing how the ball moves. TLDR: It's like creating valleys of outcomes that we need and throwing a ball that will slow down based on friction and settle on the best outcome Blog: nandakishorm.com GitHub: NandhaKishorM/vegaml HuggingFace Model Card: huggingface.co HuggingFce Space: huggingface.co