Live data from Hacker News

How Kepler built verifiable AI for financial services with Claude

claude.com

21–30 of 30 posts

Re: How Kepler built verifiable AI for financial services with Claude

#23
post #18

Anthropic published a profile on what we're building at Kepler. Sharing because the architectural argument (LLM for intent, deterministic code for retrieval and computation, every number traceable to source) is the part I'd actually want HN to push on. Happy to answer questions in the thread.

I'm on a very similar train. You cannot dump all the data into an LLM (for many reasons) and we also already have clearly defined rules that an LLM doesn't have to figure out. So keep organizing data (LLM powered, of course), so that you can query data as usual (multi modal, so not just graphs, but also time series, relational, etc). Feed that to deterministic computations. Let an LLM reason about the outcomes. Give…

The last part we're very excited by too: using orchestration logs and failure traces to surface gaps in the ontology and propose extensions. Early days, but that's where the architecture compounds, the system gets more complete every time it's used.

Re: How Kepler built verifiable AI for financial services with Claude

#24

Earlier quoted context omitted.

Oh. I may have misread indeed. Ao its like, still LLM bullshit, but with really strongly worded .md instruction files begging them to please be correct?

No. The point of the verification layer is that you don't have to beg the LLM to please be correct.

[dead]

Re: How Kepler built verifiable AI for financial services with Claude

#26

> Indexed 26M+ SEC filings But the https://kepler.ai website says 10M+

Good catch! The site was stale, updated it to reflect the 26M+

This interaction was a delightful example of life in 2026 - the disparity between what AI can do, and what and how we use AI. (Which I like to term for myself "Phenomenal cosmic powers!... Itty bitty living space.")

Re: How Kepler built verifiable AI for financial services with Claude

#27

> Indexed 26M+ SEC filings But the https://kepler.ai website says 10M+

Good catch! The site was stale, updated it to reflect the 26M+

Not to be picky but the careers page is saying Live in production. 10M+ SEC filings

https://jobs.ashbyhq.com/kepler-ai

I just wanted to learn more about the company but reside in California and open roles are in New York

Re: How Kepler built verifiable AI for financial services with Claude

#28
Reassuring to see this approach coming out consistently. I’ve been doing the same for high volume data pipelines, extracting the deterministic actions from markdown instructions and leaving the LLM to do the analysis/act as the fluid coupling between deterministic parts.

Over time you can refine this to be more and more codified, handle edge cases with agents/LLMs then turn them into first class deterministic branches too.

This pattern seems to be emerging everywhere, the chain of thought and intent capture to improve it seems to be the next big thing

Re: How Kepler built verifiable AI for financial services with Claude

#29
Shameless self-plug: https://github.com/deepclause/deepclause-sdk/

The idea is to take markdown instructions and "compile" them into a Prolog-based DSL that orchestrates both deterministic and LLM-based components. The (meta-)interpreter of the DSL automatically tracks the entire execution process, so that the final ouput becomes observable and more explainable. Still at an early stage, but I am having lots of fun with it and would love to explore possible use cases.

Re: How Kepler built verifiable AI for financial services with Claude

#30

> The duo’s answer was to build deterministic infrastructure that serves as a trust and verification layer for AI. On the one hand, very encouraging to see plain old deterministic infra w/o using slop machines. On the other hand, this is a recognition that LLMs are just additional friction in the system that we would better off without in the first place!

You're misunderstanding something about the problem space they're describing. The deterministic infra is for an underlying "execution layer"; the LLMs are providing utility by figuring out how to express English language queries in terms of the primitives of that verifiable layer. That way, you can describe your results deterministically even though the process of arriving at them was not necessarily deterministic.

How do you know that the llm is correctly translating the english queries to the verifiable primitives? It seems like it’s just pushing the problem to another layer?
Post reply on HN