Most model write-ups show you the answer. Very few show you how the thing decided, which is the part I actually need when a script makes a call I disagree with.
I have been collecting notes on two runtimes that put the decision in the output: Jev (TypeSafe System One) and Laya, an open decision model you can run on your own machine. The short version of both lives at jev001.org, and the parts I keep coming back to are below.
The output is a decision, not a paragraph
A typed decision has a shape: the options considered, the rule that picked one, and the confidence attached to it. That shape is what makes the result testable. If the rule is wrong you can point at it; if the confidence is low you can route the case to a person instead of guessing.
The overview page walks through the structure with small examples, and the API notes show what the calls look like when you wire it into a script.
Running it locally changes the workflow
Once the model sits on your laptop, the loop gets much shorter. You stop writing a prompt, sending it somewhere, and waiting; you run the decision, read the fields, and adjust. The local setup guide covers the runtimes I tried, including the CoreML and MLX builds for Apple silicon.
Two things I would tell anyone starting out:
- Start with a decision you already make by hand and can check. A pricing table, a sorting rule, a triage list. You will know immediately when the model is wrong.
- Keep the confidence threshold visible in your code. A number in a config file beats a number buried in a prompt.
Where it fits in a normal codebase
The honest answer: it replaces a pile of if-statements, not the whole application. The use-case notes are the least glamorous part of the site and the most useful - routing, tagging, and ranking jobs where a rule written in prose has been doing the work badly.
If you already keep a decision log, a typed model is a natural extension of it. Same habit, executable.
Top comments (1)
We kept our entity resolution confidence threshold in a prompt for about a year - it got quietly overridden by a downstream instruction and we only caught it because obvious duplicates started slipping through the merge step. After that we moved it to a pipeline config param and added a startup log that prints it on every run; it's been more useful than we expected for debugging. Curious if Laya stores thresholds as proper parameters or still inside the instruction text.