Jex 1.0, Part 5: Ship It
Previously: Jex 1.0, Part 4, The Rewrite.
The production run, the bit-exact verification, and the open-source release of the engine that became Jex 1.0, shipped under the name Bixoto.
The Ship
The last question was never whether the number was real; it was whether anyone else could get it.
The production run
The number that ships is not the lever stack. It is the run underneath it. On Friday 2026-10-09 the main VM began the final v1.0 production run: the frozen engine, serial, batch-invariant, over the full in-edition suite. It finished complete (140,178 / 140,178 requests, unsupported = 0, error = 0, scores.json marked complete: true) at a decision index of 59.1 (raw 69.07). That is the base entry, Jex 1.0 with no overlays at all: the honest floor of what the frozen stack does on edition 0.3.
The run’s own replay check produced a scare worth recording. The on-VM watcher flagged a non-empty diff and reported FAILED, which triggered the recovery machinery. The diff turned out to be a single field (the generated_utc timestamp), and the scores, index and benchmark files were identical once UTC was ignored. The resume wrote REPLAY_OK. It is the kind of false positive that a four-day campaign cannot afford to trust blindly and also cannot afford to ignore; we did neither. We re-ran the comparison by hand and moved on.
The lever stack ships on top of the capture as its own entry. Where it reads 60.29 (the public index, and only a public-index value) it is the v1.xplus entry: the frozen v1.x capture (59.48) plus the four adopted, disclosed, one-flag-reversible levers, carrying the two projection classes this series already named: positional construction-reuse on catalogs 62 and 20, and public out-of-fold fits on 59 and 42. That stack is the campaign’s final number, and it is the number we submitted.
The weekend, folded in
The final run was not the last thing on the machine. Two loose ends had to be tied before the package could be called complete, and both were paid for in weekend hours rather than scored points.
The first was the K2 control: a run over the suite’s K2 slice (44,036 rows, zero errors, prior-off applied at zero) to confirm that the frozen engine’s behaviour on that sub-panel matched what we expected without any of the lever overlays touching it. It did. Together with the S6 final run, that closed the correctness ledger: the base entry and the control agreed, and every remaining disagreement anywhere in the campaign had a recorded reason.
The second was housekeeping that only matters if you intend to publish. A guard process archived the run artifacts and shut the VM down gracefully rather than letting it idle into another night; the main VM restarted once more on its own, the archive was fetched, the S6 capture was installed from it, and a re-score confirmed the 59.1 by hand before all three VMs were stopped. A campaign that began with a sleeping laptop burning twenty dollars does not get to end with an unattended machine still billing. The difference is not the software. It is that the checkpoints existed this time.
Verification
A score we compute for ourselves is worth nothing until someone else can reproduce it. So before anything was published, the stack was put through verification.
The v1.xplus capture was re-scored by two independent scorers, from the same stored rows, and both produced a bit-exact scores.json: decision index 60.29, complete, 140,178 rows. Bit-exact, not close. The engine that produced it is batch-invariant (VLLM_BATCH_INVARIANT=1) and serial (VLLM_ENABLE_V1_MULTIPROCESSING=0), greedy, single-request-at-a-time: the configuration the maintainers’ re-run will actually use, so there is no batch composition for the numerics to depend on. The whole thing is pinned: engine revision 842da379…, kit 62d2f51, vLLM 0.30.0. A reproduction reads as a reproduction because the pins are published.
The latency triple, measured over 750 rows under the board protocol: median 116.4 ms, mean 369.6 ms, p80 319.9 ms. The maintainer gate is median and mean and p80 ≤ 1000 ms, serial; we passed with headroom to spare, and the numbers are model and harness figures only: the maintainers re-measure privately, as they should.
What the disclosure sheet records
Every submission to the 0.3 board carries a mandatory disclosure sheet, and we wrote ours the way we wrote everything else: as a ledger of what the number actually is. It is worth walking through, because most of the value of the 60.29 is not in the score; it is in the fact that its weaknesses are written down next to it.
The sheet opens with what is submitted, and its first line is a refusal. The base model is google/gemma-4-31B-it, frozen: no head, no LoRA, no training, no fine-tuning, BF16. The readout is a single greedy step over a 255-entry single-token label table. Nothing about the weights or the forward pass changes between the two entries: the difference between v1.0 at 59.1 and v1.xplus at 60.29 is the engine revision that produced the capture and the four post-processing overlays laid on top of it. Both runs answered every one of the 140,178 in-edition requests; both are complete; neither truncated a question nor returned an unsupported row.
Then the sheet names the levers and, more to the point, what each of them is. Fold and R20 are positional construction-reuse: they key on the literal option label the benchmark construction assigns the correct answer, and they are disclosed as public-suite projections, not as claims about a private re-run whose ordering we cannot see. c05best and R42 are fitted on public out-of-fold data, which makes them in-sample-family fits that may regress toward the base rate on a private panel. The sheet states the direction and size of each effect rather than hiding them behind a net (cat62 skill 0.6904 to 0.8324, cat20 0.8613 to 0.9094) and it states the invariant that makes the stack safe: the levers never modify a probability; they only change the emitted choice and, for one catalog, the noul field.
The determinism section is the one a maintainer reads first. Every path is a pure function of (state, questions) plus frozen constants; the engine is batch-invariant and serial, greedy, one request at a time. The frozen capture re-scored here is bit-exact. The sheet even records the one place a derived artifact is consulted at overlay time (the cat62 fold reads a row-id-keyed folded table) and flags it as disclosed and removable by rollback.
The rollback rule is the disclosure’s spine. Each lever is an independent overlay on a stored capture, and reverting any one of them is re-running a script with that flag set to False. Drop the whole stack and the score returns to the frozen 59.48; the capture itself is never rewritten, and every output is regenerable from it. A reviewer who distrusts the highest number in the series can fall back through three lower ones without asking us for anything. That is the point of disclosing the weakness: it hands the reader the lever to remove it.
Finally, the “other declarations”: the edition, the hardware, the latency certificate, the router’s unsupported rule, and an honest note about a recovered union of two small catalogs that is not an engine dependency. None of it is marketing. All of it is the record.
The self-checks, and what we could not verify
Before anything was published, the package went through a set of self-checks on a laptop, CPU-only, with the sources mounted read-only. The point was not to re-prove the campaign; it was to prove that the artifact a stranger downloads is the artifact we scored.
The first check is the one that matters. The combined v1.xplus file was re-scored by the kit’s own command-line scorer and, separately, through the in-process path the campaign itself used, over the 0.3 suite with exclusions applied. Both produced decision index 60.29 (raw 69.88, balanced skill 60.29, breadth skill 59.25, complete, 140,178 rows). Not close. Bit-exact, from the same stored rows, by two scorers.
Around that, the package was checked for integrity rather than accuracy. The packaged combined file’s SHA-256 matches the banked finalstack file; the gzip tests clean; the row count is 140,178. The manifest checksums verify in both package roots. The tree matches the runbook: each entry carries its engine, harness, requirements and an engine-package note; the results dataset carries the required per-run files plus a reproduction note; the latency evidence is present in both; the checksums sit at each root. And the lever provenance is recorded: a provenance file holds the source hash of every copied lever file and the only rewrites applied, which are path constants. No rule and no parameter was touched.
Two things we could not verify on the laptop, and we said so rather than rounding them up. The v1.0 results file had not yet been fetched to the machine (only the VM copy existed), so its scores.json, index.json and status.json were final but the results re-score was deferred, with a one-line drop-in script left in its place. And the lever stack could not be rebuilt end to end from the package, because the three derived inputs it needs were deliberately not shipped, to keep the tarball small and to stay inside a write quota; the overlay is instead certified three ways (by the bit-exact re-score of the packaged combined file, by the provenance hashes on the verbatim code, and by the banked fold receipt) with a runbook documenting how to re-run it in full.
A verification that lists only its passes is not a verification. Those two deferrals sit in the same document as the passes above them, because the whole point is that a reader can tell the difference.
The router, and one union we had to explain
Two more entries in the declarations are worth pulling up, because each is the kind of thing that looks like a discrepancy until it is explained.
The first is the router. The engine does not have a single context length; it has two, and the boundary between them is declared. Up to 8,192 tokens it runs one worker configuration, batch-invariant and serial like everything else; above that, and up to 24,576, it runs a second. Past 24,576 it declares the request unsupported rather than truncating it, the one behavior the rules leave no room to negotiate, since an unanswered question counts as wrong before any correction begins. On the public suite that branch never fired: zero unsupported rows across all 140,178 requests. The declaration matters anyway, because it tells a maintainer exactly where the engine’s promise stops.
The second is a small union of two catalogs recovered at fold time: 89 API-Bank rows and 168 POP909 rows, unioned back into the scoring set. It is a lineage artifact of the v1.0 path, not an engine dependency: the readout never sees it, and the ordered stack’s capture does not depend on it. We recorded it rather than leave it to be discovered, because the difference between a disclosed quirk and an undisclosed one is the difference between an artifact and an accusation.
The latency certificate
The board does not only score answers; it tests that the engine is fast enough to be one. The gate is median, mean and p80 under a thousand milliseconds, measured serially. Ours, over 750 rows under the board’s own protocol, came back at a median of 116.4 ms, a mean of 369.6 ms and a p80 of 319.9 ms, with the heavy reasoning path from the first phase nowhere in evidence, because the 0.3 stack that ships does not reason. The temptation is to present those as the engine’s speed. They are model and harness figures, and we say so: the maintainers re-measure privately, on their hardware, in their request order, exactly as they re-run the answers. The only speed number worth trusting is the one they produce.
What a reviewer receives
A number is only as good as the thing that carries it. Each of the two entries ships as a package, and the package is part of the claim. The engine package follows the runbook: an engine/ tree, a harness/, a requirements.txt, and an ENGINE-PACKAGE.md that states what the thing is and how it was pinned. The results dataset holds, per run, the results file, a scores.json, an index.json, an environment.json, a status.json and a REPRO.md; the ordered entry adds a benchmark summary on top. Both entries carry a latency certificate with its cited source JSON. Manifest checksums sit at each package root, so a reviewer can verify that nothing moved in transit before they run a single row.
The point is not the file count. It is that the path from a raw request to a scored index is mechanical, and that every step of it is present in the download. We did not ship a number and ask to be believed. We shipped the run that produced it, the environment that ran it, the certificate that timed it, and a document that says which parts we checked and which two we could not.
The ship
On 2026-10-12 the package went out, under the name Bixoto.
The leaderboard contribution is deliberately small: a single row in the benchmark’s submissions/README.md, opened as pull request #153 against apolinario/decision-index. One file, one line, links that resolve, no verification markers left behind. We also posted maintainer notes on the PR (the exact re-score command, the pins, the map from our dataset to the input rows, and the disclosures) because a submission that asks someone to trust it is worse than one that shows them how to check it.
The engine lives at github.com/Bixoto/jex, public, under Apache-2.0. The results live in the dataset Bixoto/decision-index-results, laid out as runs/jex-1.0/ alongside the inputs/ that produced them, so a reviewer can walk from raw request to scored index without guessing. The model card is Bixoto/jex on Hugging Face: card-only, no weights, the same pattern the frozen peer engine uses, because there are no new weights to publish. Four surfaces, one brand: the board row, the engine repo, the results dataset, and the model card.
That last point deserves spelling out, because it is the part a reader sometimes finds strange. A benchmark submission usually ships weights. We ship the opposite: a public repository that contains the engineering and a model card that contains an explicit refusal of weights, because the model is someone else’s and was never changed. The Apache-2.0 license covers what we actually wrote; the frozen checkpoint keeps its own. What a stranger can download is the part that makes the score (the readout, the overlay code, the configuration, the results), and what they cannot download is the part that was never ours to change. The repos are not bare stubs: the engine repository carries its own README and diagrams, the dataset carries a documented card, and every link resolves to a real artifact rather than a placeholder. If the claim is “engineered, not trained,” the repositories have to look like it. They do.
And the name. The engine is Jex 1.0, the version that ships. It is not a checkpoint we trained and not a model we adjusted. It is engineered, not trained: the weights are google/gemma-4-31B-it, frozen, BF16, untouched: no head, no LoRA, no adaptation of any kind. Everything that moved the score moved around those weights: a readout, a set of engines, a tape of measured decisions, and four gated post-processing overlays. The card says so, and so does the submission. “All AI-assisted.”
Reproducing it
The package was built to be re-run, not merely read. The dataset holds the results under runs/jex-1.0/ and the inputs that produced them, so the mapping from our rows to the scored index is mechanical; the engine repository documents the serving path and the pins; and the submission’s own notes restate the re-score command alongside the disclosures. Nothing about the reproduction is clever. It is that the artifact is complete.
That completeness is also the reason the two projection classes are stated so baldly. If a maintainer re-runs the public suite, the positional levers reproduce; if the private construction is not a twin of the public one, they may not, and we say so up front rather than hoping the discrepancy stays in a decimal place nobody reads. The rollback exists for the same reason: drop any single flag and the stack returns to the frozen 59.48 capture, which is itself just a re-score away from the base run at 59.1. A reviewer who distrusts the highest number in this series can fall back through three lower ones without asking us for anything.
The fair fight
The comparison that matters most is not against the leader. It is against the engine running the same checkpoint we do.
deck31b is the nearest frozen peer: same 842da379… base, the same stock serving path, FP8, one calibration temperature. It runs the same weights and gets 58.19 public / 59.03 Full. Jex 1.0 with its lever stack reaches 60.29 public (the public-index figure, carrying the two disclosed projection classes). That is +2.10 on an identical checkpoint, and none of it comes from the model, because there is no model change to point at. It is all engineering: the readout, the deterministic overlays, the gated corrections. On a benchmark whose top of the table is trained heads, the frozen entry that beats its frozen twin by two points is the cleanest evidence that the engineering is where the work really is.
The board’s composition makes the same point from the other side. Jex sits around fifth on the public index, and every entry above it is trained: full fine-tunes and trained heads, the recipe that the frozen track cannot use and does not pretend to. Among no-training entries, Jex 1.0 is the best, and by a wider margin the further you look. That is the claim, and only that claim.
What we do and do not claim
The one place a reader can be misled is the gap between public and Full. The 60.29 is the public index (a fifth of the Full formula, 0.20·public + 0.50·eqS + 0.30·eqO) and only a fifth. The two skills legs are maintainer-run private legs we cannot measure, and their transport carries an irreducible uncertainty on the order of ±0.5. We do not claim a Full score, a rank on the Full board, or a first place. We claim a public-index value on a fixed, published suite, complete on every request, re-scorable bit-exact by a stranger, and +2.10 over the engine that runs the same weights. No more and no less. The projection classes in the lever stack are disclosed for the same reason: a public-suite gain that hinges on construction is presented as a public-suite gain, never smuggled into a claim about an unseen re-run.
Which brings the series to its actual result. On a frozen model, against a board of trained entries, the score is real and the receipts are complete; but the thing we would defend longest has nothing to do with the second decimal place. Every number in this story traces to an artifact. Every hypothesis that died has a recorded reason and a reopen condition. Every lever that lived is a pure function, reversible with a flag, and disclosed next to its own weakness. The run we ship will be reproducible by someone who was never in the room, and on a campaign about machine decisions, that is the decision we are proudest of.
The engine is Jex 1.0. The weights are not ours, and that was never the point.
Bixoto
