Jev and the Art of Truth Maintenance

The advent of the large language model seems to have put computer science in a pretty awkward spot. It's hard to miss when you read some of the old, canonical textbooks and papers and try to square them with your actual day job as a software engineer.

Take a personal favorite: Abelson and Sussman's Structure and Interpretation of Computer Programs. It's a book about building programs and managing their complexity. It's very good. You should read it.

There's also an excellent series of twenty video lectures, in which Abelson and Sussman teach the MIT course behind the book, recorded in 1986 for Hewlett-Packard employees. You can watch the whole thing on YouTube. But it's hard to watch them now and not feel that things have gotten more than a little screwy.

Abelson opens the first lecture by pointing out that “computer science” is a terrible name: it isn't really a science, and it isn't really about computers. Geometry has a similar problem. The name means measuring the earth, but its lasting contribution wasn't surveying land; it was developing a way to talk precisely about what is true.

His hope is that computer science will be understood in much the same way. The computers are the tools. The lasting contribution is learning to formalize our intuitions about process: developing a precise language for describing how to do things.

There's something funny about arriving here, then. At what some consider the end – or maybe the crowning achievement? – of our discipline: we write a loose description of what we want in English, hand it to an ambiguously sentient, opaque blob of proprietary math, and let it work out the process as it goes.

And yet, it's proving unreasonably effective. There are plenty of systems that you could and should build this way – just hand a model as much information as you can and give it tools to do something with it. Something like this:

You may recognize this as a somewhat uncharitable, grossly simplified (but not entirely inaccurate) picture of your agent du jour, whether that's OpenClaw, Muse, Grok Bot, Dot, or Instinct.

It is a testament to just how flexible and powerful this technology is that this is even possible, never mind entirely viable, or even optimal for some products.

The devil in the DETAILS.md

My thesis is that there are, however, certain products and businesses which can't operate in this way, no matter how good the models get.

Let's start with cost. Having something resembling intelligence orchestrate an entire workflow can get expensive, particularly at scale. If you're flush with VC cash – or one of the big labs – you may be able to get away with this for a while.

For the rest of us with high-volume, low-margin workflows, the cost per decision can make the economics untenable. Now, admittedly, that may change as models (presumably) get cheaper and more capable.

Switching to a new, faster, smarter, or cheaper model comes with its own problems, though. Each model has its own quirks, idiosyncrasies, and habits. Across a large, complicated instruction set, it's hard to ensure – or even measure – that performance hasn't regressed.

Then there's the broader problem of non-determinism. As things stand, you can give a model the same instructions and the same inputs twice, and get two different answers.

That's not necessarily a problem in itself, but some workflows really benefit from more predictable behavior. At sufficiently large scale, even a tiny risk of an unexpected, catastrophic failure becomes difficult to discount.

Quite apart from how likely that actually is to happen, there's the question of trust: even if you're very confident, what about your customers? Or regulators?

Highly regulated domains may also require more control over decisions, and evidence that those controls work.

Suppose you're using a model to evaluate loan applications. By law, you can't base lending decisions on factors like race, religion, or sex. Financial records, employment history, and other perfectly legitimate inputs may reveal – or hint at – those characteristics anyway. How do you establish that your agent's decision hasn't been influenced by any of them?

Reading the agent's chain of thought doesn't quite settle this. That's not to say it's even necessarily available; model providers may opt to deliberately withhold raw reasoning traces. Even when the underlying trace is available, it isn't necessarily a faithful account of how the model reached its answer.

Could we get the model to just tell us why it made a particular decision, then? Naturally, we could. A plausible justification for a given answer after the fact isn't, however, exactly the same thing as tracing how that decision was actually made.

Smaller judgments, explicit rules

We've been habituated into thinking about two very distinct and very distinctly useful properties of LLMs as being intrinsically linked: 1. their ability to semantically parse unstructured data, and 2. their ability to reason about it. Sometimes that's not a useful distinction; other times it really is.

That distinction is becoming especially relevant, now that we have generalized intelligence which comes in a different shape than something which primarily consumes and produces text.

Enter decision models – or System One models, whatever your preferred nomenclature – like Jev.

Although this product category didn't exist a couple of weeks ago, it's opened up a bunch of product niches which weren't necessarily economical or practical until recently.

Instead of generating a passage of text, Jev evaluates supplied context against typed questions: choose an option, assign a score, or estimate whether a statement is true. It returns structured answers and probabilities for code to consume directly.

That means you can't, say, have Jev automate your correspondence with your mother.⁠¹×Or, well, not easily, at least. You could always make it generate text by choosing the next character, over and over again. It can, however, help you work out what she wants.

Say she sends you this:

The printer's broken again. I wish you'd come around and fix it.

We can configure Jev to return something like this:

{
  "answers": {
    "what_mom_wants": {
      "type": "choice",
      "choice": "visit",
      "probabilities": {
        "phone_call": 0.07,
        "technical_support": 0.28,
        "visit": 0.62,
        "unclear": 0.03
      }
    }
  }
}

This is a structured blob containing the question's name, the type of answer, and the chosen option – in this case, visit. We also get a probability for each of the options we supplied, alongside the chosen answer. Our code can read those values directly and decide what to do with them.

A couple of other things to note here:

• We get an answer in 70–500ms.
• It's around 100× cheaper than Anthropic's Sonnet.

You may or may not find this terribly exciting (Jev's launch and utility have been somewhat controversial). But even if you do, you may be slightly nonplussed as to how to actually use this at scale for some of the more complicated reasoning we've come to use LLMs for.

TypeSafe, the makers of Jev, recommend asking narrow questions, then combining their answers with logic in your code.

OK, but how?

How do we compose the multi-step reasoning that an LLMs would have given us "for free"? How do we keep track of – and deal with – apparent contradictions in our evidence? Finally, when we assemble our answer, how do we relate that conclusion to the judgments – and ideally the sources – that produced it?

To my great satisfaction, it turns out that a pretty comprehensive answer came from Abelson and Sussman's lab.

In 1979, Jon Doyle, one of Sussman's students, proposed a kind of bookkeeping system to track why a program believes what it believes: the truth maintenance system. It works alongside a symbolic reasoning system, recording a justification for each belief – the other beliefs and assumptions that support it.

That means whenever we learn something new about the world – even something that contradicts the stuff we already believed – we can work out surgically which beliefs still have support and which need to be withdrawn.

Johan de Kleer would expand on this idea in 1986. His system keeps several possible, parallel versions of the world in play at once – a sort of quantum superposition. It tracks which conclusions hold under which combinations of assumptions. This allows us to explore incompatible possibilities without having to commit to one view of the world, so we're able to find the one that best fits our observed reality.

A really simple version of that might look something like this. Assume we need to figure out if you're related to a presumed ancestor. Let's start with some simple rules:

Notice how different this is from handing the same question to an LLM. Nothing here is inferred afresh each time: the same facts and the same rules give the same answer, every time, even when irrelevant facts change – and we have our answer, with a full chain of reasons available for inspection.

As useful as this may seem, truth maintenance systems, rule engines, and similar systems have, up to this point, had relatively niche applications.

Historically, that was because they were plagued by the so-called knowledge acquisition bottleneck: getting knowledge out of people's heads and documents and into explicit facts and rules takes a lot of work. However useful these systems may have been, building and maintaining a sufficiently complicated knowledge base was oftentimes simply impractical.

I think LLMs and Jev may mean that the math on that has changed.

It's a bag. Full of facts

As far as I'm concerned, this is the really interesting bit: far from making this technology obsolete, a combination of LLMs and System One models may, at last, make it easier than ever to apply these techniques to real business problems.

In that hope, Factbag is an experiment in making it easy for humans and agents alike to define robust chains of reasoning.

It is intended to be something like a reusable, inspectable chain of thought for System One models like Jev. We can have a domain expert and an LLM cooperate to lay out the rules once, leaving something we can evaluate quickly and consistently.

I think there may be something interesting to investigate here. Even when it wouldn't be practical or appropriate to use an agent directly, they will have second-order effects which make new (and yes, old) kinds of apparently unrelated software and experiences more viable than ever.

Part of being a software engineer in this time is making peace with how our profession has changed.

For my part, I find it comforting that the vision that initially drew me to computer science – the one Abelson set out, of formalizing our intuitions about process and developing precise languages for describing how to do things – still seems to apply.

In fact, it feels like now, finally, we can really get started.