This Shit is Hard: Getting AI to prove where a number came from

Vinoo Ganesh and Sara Kromwijk work at Kepler, a model-agnostic verifiable AI platform that separates what models do well, language and reasoning, from what deterministic tools do well, retrieval and computation.

Chainguard’s "This Shit is Hard" series showcases the difficult engineering work that goes into building software people can rely on. This includes work we’ve done ourselves and by teams solving hard problems adjacent to ours. Today, Kepler explains the challenges of building AI that financial analysts can trust, and why it means writing more software around the model, not waiting for a smarter one. Turns out, this shit is hard.

At its core, Kepler is a deterministic harness for AI. We separate what LLMs are genuinely good at (the nondeterministic work) from what code, math, and other deterministic tools are good at. The platform has one major invariant: provenance and traceability, in service of accuracy. Every number is clickable and provably accurate, traceable back to its source, whether that’s a document, a formula, or the computation that produced it. Our first focus area is finance, where we’ve built a platform that has indexed 26M+ SEC filings, earnings transcripts from 14K+ companies, and 40M+ first-party IR documents across 27 markets. Beyond that, though, Kepler is extendable to any industry where trust in outputs is critical.

The fun of the company is the balance between an almost-black-magic problem — getting LLMs to behave — and a very old-school one: How do you verify an unreliable system? While tackling these, we also end up facing a more familiar problem — garbage in results in garbage out. LLMs do not change that.

Every problem has a simple answer that is wrong

You’ve seen the headlines. A law firm using an LLM that cites cases that don't exist. In finance, the equivalent is a number that appears with no source at all, or worse, is totally made up. These are serious people working on serious problems, who were running checks with AI. The checks didn’t work.

There’s a double-entry bookkeeping aspect to verification: It is very, very easy to trick yourself into believing you’re correct. The first simple answer is to pull the numbers and confirm they do, in fact, exist. The second is to have another LLM check the first one. But both of these have flaws. To start with, are the numbers even in context? How much time am I wasting doing this? And of course, the second model has the exact same information as the first and is probabilistic in its own right. Why would it find something different?

Provenance through the execution chain is a deeper version of this. There’s a lot of enthusiasm for multi-agent systems, but an agent making decisions based on a tool call or another agent’s output has to carry state and source information through every one of those computations. If you get that wrong, a model that extracted its information perfectly still produces a result you can’t stand behind. This is like the Swiss cheese model from security: You can’t let the holes line up, and you can’t skip verification in one place, because that’s the one that bites you.

Some things we just don’t let the model do

Much of our answer is architectural. Deterministic subsystems handle pre-extraction, and the LLM’s role is to evaluate the accuracy of their output. If our code says A and the model confirms it, that’s a fundamentally different check than the model saying A and us reconstructing afterward whether A was right.

On top of that, we use parallel construction. We can’t check everything directly, but we often know internally that a set of components should sum to a particular figure. Those checks aren’t correlated with the errors the model makes, and you can stack them until the odds move a long way. 

A handful of our customers have made a hobby of checking whether each new model finally fixes these problems, which would put us out of a job. We’re weirdly into it. One analyst told me a frontier model had one-shotted a full discounted cash flow forecast. He was blown away. I asked if he used it. He said, “Well, no, most of it was wrong.” You can’t make a nondeterministic system deterministic by making it smarter, which is what the deterministic layer is for. Everyone is betting on hyper-intelligence. It turns out you need more than that to produce work product; you need a system you can trust.

Another thing that works better than it should is forcing the model to do the work rather than asking it to try hard. Don’t let it not work. If the moment demands reasoning, it will reason. And if it can get away with skipping it, it will. It’s a lot like humans in that way. Lazy can be fast.

We don’t claim to be an oracle

People ask what happens when the truth is ambiguous. When sources disagree, the thing an analyst wants to hear is that the sources disagree. It isn’t our job to interpret it for them, and we definitely want to avoid just picking one blindly as the source of truth.

Reading the same facts differently from others is how you beat your competition in financial markets, and in any domain; it’s what makes you different. Those differing reads are compatible with what we do, because the platform grounds your read in the sources rather than replacing it with ours.

Truth can also be subjective. Research processes are proprietary; if I trust one analyst over another, that has to be reflected in my process. Each company, each team, and each user has a style, so you have to stitch them together. Building those memories and rules is the moat, because the trade-offs are subtle. Recalling a previous session is a distraction if that session was a throwaway, and invaluable if it tells you that last week you tried something similar and got stuck here.

Staying stable while the models move

Models change on a dime, and we don’t control when. We run an evaluation framework that combines deterministic rules with LLM-judged ones for genuinely fuzzy cases, and its job is to catch answers that are quietly getting worse. It’s also what lets us spread across providers. If one is down, we’re fine, because we know for a fact that the others give the same performance and the same guarantees.

As a demonstration of how far the deterministic layer can take you, we’ve run the platform using a small open model on a laptop. It isn’t a smart model and wouldn’t hold up on high-level reasoning, but on the workhorse questions, it worked without making mistakes. The evals give us that confidence; the determinism bet reduces variance even between model families.

What teams often get wrong

A common misconception is that there will magically be a model that solves every problem. Everyone is AGI-obsessed, and even we believed some version of it early on. It has become viscerally clear that the right answer was switching between deterministic and nondeterministic systems. However powerful your model is, why run one plus one through a multibillion-parameter model instead of one CPU cycle? The industry is catching up. Open models keep arriving, intelligence is commoditizing, and the model is not where value accrues anymore.

Another misconception was ingestion, which is severely underestimated for the same reason: assuming the LLM would just handle it. Even with an infinite budget, if you push data in without doing anything to it, it simply won’t work. So we transform unstructured data into semi-structured data before it ever reaches the model. Otherwise, the thing seizes up. Only with a fully integrated system that combines these two components can you start to produce a work product you can trust.

What’s still hard

Search and navigation remain difficult industry-wide. The ideal system is an infinite number of humans reading every document, integrating it all, and making the right call, which is impossible even at infinite cost. So you build tricks: structural traversal, full-text search, and RAG, which can search on meaning (which is genuinely cool). Ask for the parts about buying cars, and it works. But ask for every place a public cloud provider is linked to some other thing, and you can’t even express the query. Ontology is our bet on where this goes. We have prototypes, but they need to be fully built out. The guarantee we actually want is very hard to give.

And entropy isn’t going anywhere. As long as an LLM is on the critical path, there’s randomness. You could have a hundred billion evals and still not reach 100% accuracy. You can get close to perfect; you cannot get to perfect. Building on probability machines will be a moving target for as long as these models are in the loop, which means the work isn’t making the model smarter. It’s building enough rigorous, unglamorous, deterministic software around it that you can stand behind every number it shows you. That’s what we’re working on at Kepler.