system-one

How we reviewed this: we ran its own tests, typecheck and lint in Docker, then drove the same decision through two providers and fed the validator seven malformed provider responses. We made no Jev calls and used no API key.

What it does

system-one is the boundary rather than the model. You write choice, noul and score against a SystemOne client, and the provider — TypeSafe’s Jev, a local Reflex, any /v1/systemone endpoint, or a class of your own — is a constructor argument. Two packages: the core runtime and a Pi integration with a skill.

We tested the claim directly. The same three-question decision, unchanged, ran through HttpSystemOneProvider against a stand-in and through an in-process provider that answered from a literal, and the results came back in the same shape with the same keys. The wire body is the documented one, and three questions went in a single request.

Fail-closed, tested

The README promises that “malformed provider responses are rejected instead of being silently normalized into something plausible”. That is a claim you can put a fixture against, so we did.

what the provider returned	result
a noul answer where a choice was asked	rejected — wrong answer type for team
a choice naming an option that was never offered	rejected — unknown choice for team
a noul of 1.7	rejected — invalid noul for browserSpecific
a probability of −0.2	rejected — invalid probability for team.frontend
a score of 9 on a two-level rubric	rejected — score 9 outside valid rubric range 0..1
no answer at all for one question	rejected — missing answer for browserSpecific
a score answer with no legend	rejected — legend must be an object map

Every one throws SystemOneProtocolError and names the question. This is the part of the library worth having: it is the difference between an agent branching on a number and an agent branching on a number that means something.

One case got through when we tested: a choice returning {frontend: 0.6, backend: 0.6} was accepted, because each probability was range-checked and the distribution was not checked to sum to 1. We reported it, and it was fixed in four days (#12). We re-ran the probe against d58104b on 2026-10-04: a choice summing to 1.2 is now rejected (probabilities sum to 1.2, expected 1), so is a score summing to 0.7 — the maintainer found Score had the same gap — and so is a choice whose probabilities carry a key that was never offered. A distribution that is off by rounding (1.0000004) still passes, which is the right tolerance.

Two rough edges

The Develop section says npm install, npm test, npm run typecheck. Run those three and you get three failing test files and a failing typecheck, because pi-system-one’s tests import the core’s built dist/. CI knows: it runs npm run build --workspace system-one-core first. With that step both packages pass — 161 tests in the Pi integration and, at d58104b, 60 in the core — typecheck clean and Biome clean. The red suite was ours, not the project’s.

Both package.json files declare MIT and npm shows MIT, but the repository has no LICENSE file — a two-minute fix that matters for anyone whose legal review reads repositories rather than manifests.

Verdict

A week old, 66 stars, and it has picked the right small job: be the seam between an application and whichever System One implementation it ends up on, and refuse to paper over a bad answer. The validation table above is why you would use it rather than calling the endpoint yourself.

The probability-sum gap we found is closed at d58104b; pin to that or later. For the connector-shaped version of the same portability idea, see System One Connector; for running the models it abstracts over, ollaya.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Oct 4, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.