Thursday 1st October 2026

De-LLM'ing your decision based workflow.

Calls to LLMs are pretty common in software systems these days. Write a reply to an email, classify a customer's complaint, decide what to do with this refund request, etc. All typical use cases, and all fine until you notice that half of them are not really "generate some text" problems, which is sort of a big part of LLM's.

Take a fairly bog standard event-driven architecture for document processing: document lands in an S3 bucket, OCR engine pulls out the text, a Lambda runs the Textract call to get the text of the document and business logic (including a call to an LLM to classify the document) with the result being shoved onto a queue for whatever downstream processing that document type needs. In that setup you are asking an LLM to do something it is reasonably good at (reasoning), but it is not especially structured when dealing with this kind of request. You end up with a lot of prompting, custom instructions, a response that takes a while to come back, and a bill that gets ugly at high volume.

If you already know a document can only be an invoice, a purchase order, or a contract then wouldn't it be easier to use something specifically designed to classify the thing in front of you into one of those categories?

Well, Jev launched recently. It's a "System One Model" (yeah, me neither) and they describe it as essentially a "smart if statement", which I think is a useful way of thinking about it. More plainly, Jev is a specialised probabilistic decision model for cases where the possible outputs are known in advance.

Imagine I'm building that system I mentioned above: business documents come in and need classifying as invoices, purchase orders, contracts or correspondence.

S3 → Lambda with Textract and LLM calls → SQS → subsequent processing.

I could write rules:

if "invoice number" in text.lower():
    document_type = "invoice"

That works until an invoice uses "Invoice Ref", or a purchase order happens to mention an invoice number somewhere in the small print. Or, I could send the extracted text to an LLM and calls to ask it to classify the document. But calls to LLM's for this sort of stuff can get expensive at scale.

What I actually want to write, and get the answer back for as quickly and cheaply as possible is:

if this_looks_like_an_invoice:
    process_invoice()

If we put the cost aside for a second, an LLM can answer that question, but it feels slightly strange to send the document to a model designed to generate text, ask it to generate an answer, then parse that answer back into something my software understands (hello yet another json template for an LLM!).

Jev takes a different approach by letting me define the possible decisions:

invoice
purchase_order
contract
correspondence
other

And Jev returns probabilities for each.

invoice           0.97
purchase_order    0.01
contract          0.01
other             0.01

My normal, boring, if-statement code then decides what happens:

if invoice_probability > 0.90:
    process_invoice()
else:
    do_other_thing()

The AI isn't running the workflow here, which is the point of it because it doesn't need to. It's handling the fuzzy bit that is difficult to express in code, and I'm thankful for that, but then I still own the logical branching, the thresholds, and the "what do we do when we're not sure?" paths AND get the answers back at incredible speed. Up to 75x faster than an LLM!

The other interesting part is cost. TypeSafe currently advertises Jev at $0.042 per million input tokens. An example on their site has it 238x cheaper than Claude. This is crazy. And before you say it, yes, you still need to give Jev context and specific instructions, of course, but it also cannot hallucinate like an LLM can due to the defined outputs.

I don't write much about AI stuff really, I prefer to write about IAC and python stuff, but Jev is cool.