AI Engineer World's Fair 2026
How Kepler Built Verifiable AI for Financial Services
Read the talk
Building Financial AI That Can Prove Where Its Numbers Came From
Kepler separates model reasoning from numerical execution, using provenance, deterministic tools and replayable derivations to produce financial work that can be checked.
From a talk by Vinoo Ganesh
Before you start: Basic familiarity with financial statements and programming is helpful; the article explains the provenance and execution concepts as they arise.
When producing the work stops being the hard part
How can AI produce financial work that someone can actually trust? For Vinoo Ganesh, CEO and co-founder of Kepler, the question follows a career in environments where numerical accuracy matters: leading Palantir’s compute platform and US government engagements, building and selling an alternative-data startup, and serving as head of business engineering at Citadel. He presents this architecture as a distillation of Anthropic’s Kepler case study, which he describes as an unusually exclusive company case study. His broader prediction is that AI will increasingly produce professional work product, whether Kepler or someone else supplies the infrastructure.
Generating more tokens is already making it easier to produce code, marketing copy and discounted cash flow models, or DCFs. Checking that output has not become equally easy. AI turns a writing problem into a reading problem: the supply of plausible work grows faster than the capacity to verify it. Evaluations can measure a probabilistic model’s behavior, but they do not turn each future response into a deterministic guarantee. That distinction leaves room for useful evaluations—Kepler’s companion case study describes them alongside deterministic execution—without treating an evaluation score as proof of an individual number.
In investment research, the shift also changes where an advantage can come from. A firm such as Citadel could historically hire hundreds of analysts to find and interpret information. When models give everyone access to the same material, including sources such as Tegus, information consumption alone becomes less differentiated. The remaining bottleneck is trusting what the model produces from that information.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Financial work needs a verification layer
Other consequential workflows already separate producing something from accepting it. Software has CI/CD, unit tests, integration tests and code review. A pharmacist can catch an implausible prescription, such as one specifying 10,000 milligrams. Aviation pairs a pilot with a copilot; emergency response pairs primary and secondary EMTs. Ganesh’s finance counterpart is an overworked vice president: a review layer exists, but its capacity does not scale with generated work.
Ganesh characterizes part of Bloomberg and FactSet’s value as shifting responsibility onto a shared, vetted source. Much underlying information is available in SEC filings, but centralized collection gives firms confidence that they are using the same accepted data—even if it contains an error. In the workflow he describes, however, those tools are read-only: an analyst consumes the information and still has to produce the model or memo. Reliable inputs do not automatically produce reliable work.
That gap has human and institutional costs. Ganesh points to analysts working until four in the morning and links extreme investment-banking hours to deaths. He also invokes the SEC and OCC to explain why a confident answer is insufficient in this setting: firms need to justify decisions through identifiable information and processes, with controls against misuse such as insider trading. The engineering requirement is an inspectable path from evidence to decision, rather than confidence in the final prose.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A citation locates evidence; verification checks the value
Moving beyond search means producing a fairness opinion, a DCF, an investment memo, or a retrospective comparison of old confidential information memoranda—CIMs—with the internal rates of return actually achieved. These are work products whose conclusions depend on selecting, transforming and reconciling information. A list of search results is only an input.
Claude and ChatGPT can attach source lists to answers, but a source list does not establish source quality. Ganesh illustrates this with a hypothetical Substack post predicting Palantir at $3,000 a share. A citation would faithfully identify that post without making its prediction sound. Seeking Alpha articles, blogs and Reddit posts may be useful data points; their presence in an answer does not make them vetted evidence.
The distinction becomes concrete when extracting revenue from a 10-K:
| Layer | Question it answers |
|---|---|
| Citation | Where did this information come from? |
| Numerical verification | Does this extracted value match the source? |
Ganesh describes citation as an after-the-fact audit and verification as a deterministic, repeatable check. For revenue, the immediate objective is to establish that the value taken from the filing is the value actually present there. That verifies fidelity to the source; it does not by itself establish that the company’s reporting or an investment conclusion is correct.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Verify the process, not agreement on the investment
Verification lives in the path used to produce an answer. Two investors can inspect identical information and take opposite positions. Ganesh uses two technology, media and telecommunications desks at Citadel as an example: one can be long a stock while another is short, even when both use the same verification mechanisms. A verified process need not force a shared investment judgment.
Instead, the process has to respect the organization’s sources, transformations and rules. Which sources are trusted? Which transformations are permitted? How are those choices codified? These are the organization’s nouns and verbs: the entities it reasons about and the operations it accepts. Merely saying that a number came from a 10-K leaves those questions unanswered.
The architectural boundary follows from that requirement. A model may reason about which EBITDA adjustments are appropriate, but Ganesh does not assign it responsibility for performing the arithmetic. He compares the model to a portfolio manager: reasoning operates within a surrounding system of deterministic tools, grounding and risk thresholds. The model’s intelligence needs a deterministic substrate.
Kepler organizes that substrate around three tenets: atomic provenance, scope determinism and derivation chains. The practical target is familiar: an analyst reads a PDF 10-K, 10-Q, 8-K or earnings-call transcript on one screen and copies numbers into Excel on another. Eliminating that transfer requires preserving both the values and the evidence needed to trust them.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Atomic provenance: let the model select a reference
Kepler first trained a model that was good at extracting information. Ganesh reports 94% accuracy; the companion case study scopes that figure to specialized recall tasks, including financial-label taxonomy mapping, rather than end-to-end financial accuracy. He says it outperformed foundation models, but the relevant question is whether anyone would trade on the remaining errors. The published account does not supply a public benchmark dataset or denominator. Better fine-tuning still leaves a probabilistic failure path.
Atomic provenance changes what the model is allowed to emit. The model writes a reference to a number, not the number itself. It cannot write or manipulate the numerical value. Databases and other deterministic systems handle reading, writing and preserving that value; the model identifies where it should come from and hands off to those systems.
The resulting procedure is:
- Resolve the model-selected reference through the numerical data system.
- Extract and persist the value with its provenance.
- Check the value independently through the deterministic verification process.
- Remove values that cannot be verified rather than passing them to the user.
- Repeat the verification cycle against the provenance ledger.
Ganesh says this cycle runs at least a couple of times. Its assurance comes from a canonical extraction-and-persistence process, not from having OpenAI, Anthropic and xAI models grade one another’s answers. He explicitly connects the word atomic to database atomicity: the numerical value and its validated handling belong to one controlled process.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Scope determinism: plan the calculation, execute it in code
As reasoning models become more available, the scarce capability shifts toward controlling what they do. Ganesh points to downloadable GLM-5.2 and compares it with Opus 4.8. The official model card provides task-specific comparisons, rather than universal equivalence. His architectural point does not depend on which model leads: using a multibillion-parameter model to add one and one is an expensive way to perform an operation ordinary computation already handles.
The model decides what to compute; external tools perform the computation. For a question such as a company’s net margin last quarter, the model identifies the needed information and plans the operation. Deterministic code extracts values from PDFs or parses XBRL, then persists those values outside the model. The numerical answer comes from that execution path. The slide makes the handoff explicit: model reasoning and planning feed code that retrieves verified inputs, performs division and returns a net margin.
A small Python example makes the boundary concrete. Suppose the data layer already holds verified, same-period values for revenue and net income. The model’s plan contains only an operation and references; the executor owns lookup and arithmetic. Here, the teaching values are 1,000 and 269, in the same units:
python
from decimal import Decimal
verified_values = {
"filing:q1:revenue": Decimal("1000"),
"filing:q1:net_income": Decimal("269"),
}
plan = {
"operation": "net_margin",
"numerator_ref": "filing:q1:net_income",
"denominator_ref": "filing:q1:revenue",
}
def execute(plan, verified_values):
if plan["operation"] != "net_margin":
raise ValueError("Unsupported operation")
income = verified_values[plan["numerator_ref"]]
revenue = verified_values[plan["denominator_ref"]]
if revenue == 0:
raise ValueError("Net margin is undefined for zero revenue")
return income / revenue * Decimal("100")
margin = execute(plan, verified_values)
print(f"{margin:.1f}%")
The calculation yields 26.9%. An unknown reference fails lookup instead of becoming a model-supplied value. This illustrates the calculation boundary; establishing that the input records match a filing remains the provenance layer’s responsibility. Ganesh also attributes lower cost to keeping extraction and arithmetic out of model generation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Derivation chains preserve how a number was made
Some requested numbers are directly reported; others must be derived. Gross-margin percentages can appear in filings, but a requested ratio, EBITDA adjustment or firm-specific definition may not. The challenge then moves from locating a value to reconstructing the calculation that produces it. Firms may calculate enterprise value differently or disagree about whether an item is recurring. Those choices must become explicit inputs to the process.
Derivation chains record which inputs and transformations produced a number, then connect those numbers to the resulting work product. They play the role of an analyst’s chain of reasoning and calculations on the way to a risk/reward assessment or trading decision. Ganesh describes the chain as replayable and rewindable: an inspector can work backward from an outcome or replay the operations that produced it.
Together, the three tenets establish a boundary around permitted outputs. The system knows which data points it can produce and which it cannot; extracting a number from prose or a raw table is not left to the model itself. Ganesh says Kepler can consolidate financial statements in seconds, with every number tied to its source. No workload size or reproducible timing protocol accompanies that claim.
He contrasts this with contractor-based workflows he associates with CapIQ and Daloopa. The intended output is a usable financial model, including a DCF in the customer’s preferred format. The claimed safeguard extends beyond cell values to structure: the model should not invent a row that the work product is not permitted to contain. Traceable numbers, controlled computations and constrained structure are what turn retrieved information into financial work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The same separation applies beyond numbers
Finance makes the architecture easy to see because it cares so visibly about numbers. Other domains have different objects that need equally careful preservation:
- Legal work: Ganesh imagines systems such as Harvey or Legora preprocessing case entities and storing them deterministically, so generated legal work refers to actual cases rather than invented citations.
- Drug discovery: He proposes preserving compounds and formulations from NIH papers so that generation does not omit an essential compound.
In each case, the model reasons over entities whose identities are maintained outside its generated text.
His adoption analogy is e-commerce before SSL: a large potential market was not enough without infrastructure that made transactions feel safe. Retrieval-augmented generation has helped codify workflows, but retrieval alone does not provide deterministic checks on the work produced. Ganesh characterizes Claude for Science as RAG-based; the architectural opportunity he identifies is the still-missing verification infrastructure across many disciplines, rather than simply another interface for consuming documents.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From token consumption to useful work
Ganesh points to a conference club awarding gold cards to people who have consumed more than a billion tokens. Rewarding that consumption, he observes, amounts to rewarding employees for spending money with another vendor. He expects attention to move from maximizing tokens toward optimizing the cost of useful results.
The precedent is data infrastructure. Recalling discussions around Snowflake and Databricks roughly four years earlier, he describes a familiar sequence: companies invest heavily, then ask what return they received, then optimize spending toward pipelines people actually use. AI is likely to face the same pressure. Delegating arithmetic to ordinary computation serves both correctness and economics: reserve model calls for work that benefits from model reasoning.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The next step is a firm’s own investment process
Cheap, heavily subsidized generation leaves the reading problem unresolved. Checking an isolated data point is also insufficient if the surrounding system cannot track its provenance or explain how it reflects the firm’s investment philosophy. Ganesh describes citations as having carried the industry only partway toward verifiable work. The work product itself should carry the proof: the evidence and transformations needed to inspect how it was made.
Software provides a model for that institutional memory. Tests, pull requests, commits and code reviews preserve more than the latest source code; they record decisions and checks. Ganesh sees attempts to reconstruct company-specific ontologies from that history and wants an equivalent record in finance. Such an ontology would describe the firm’s entities, relationships and accepted investment operations, not just its collection of documents.
Ganesh treats the numerical foundations as solved and identifies personalization as the remaining mile. His hope for a 2027 follow-up is to discuss verifiable ontologies that stand in for a firm’s investment process, rather than how many tokens it takes to answer a question. He closes the prepared talk by inviting people to join him and Susanna at Kepler and stating an intention to expand beyond finance.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What enters the ledger—and what customers want back
An audience question makes the provenance ledger more concrete: where does a recorded number actually come from? Ganesh identifies three origins:
- Filings: information extracted from external financial documents.
- Calculations: derived values, such as ratios, produced through mathematical operations.
- Internal information: documents and other firm-specific inputs used together with external data.
Whenever the model directs another component to perform an I/O operation, that operation becomes part of the provenance chain. The ledger therefore covers the movement and production of information, not just a final citation attached to an answer.
The final substantive question asks what customers are most excited about. Ganesh distinguishes the industry’s aspiration for an AI portfolio manager from what portfolio managers themselves want: an AI analyst. They want repetitive, painful work completed quickly—reviewing earnings-call material or opening historical 8-Ks and 10-Ks across a browser full of tabs to assemble the first version of a financial model.
The immediate value is getting analyst time back. Ganesh says some analysts doing this work earn $600,000–$700,000 a year. The customer goal is to stop spending that expertise on transcription and assembly, while retaining a work product whose numbers and construction can be inspected.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Anthropic’s account of Kepler’s reasoning pipeline, deterministic execution and evaluation practices.
Kepler’s overview of its architecture, financial workflows and source-traceable outputs.
Official model weights, license, benchmark results and instructions for running GLM-5.2.
Updates since the talk
An August 2026 update describing Claude Science’s tools, auditable artifacts and researcher support programs.
Read the complete timestamped transcript
- 0:00
[on-hold music] Hey everyone. Thank you for being here. My name is Vinoo Ganesh, and I'm the CEO and co-founder of Kepler.
- 0:18
Today, I'm gonna talk to you about how we built verifiable AI for financial services.
- 0:24
First, a little about me. Uh, my career has been working in fairly, uh, difficult places to work in terms of numerical accuracy and verifiability. Began my career at Palantir, where I led the compute platform as well as a lot of our USG engagements.
- 0:38
Built and sold a, uh, alt data startup. Um, then was head of business engineering at Citadel. I have some Citadel colleagues here in the audience as well. Uh, I've advised a bunch of startups and, um, been lucky that all of them reached pretty positive outcomes.
- 0:52
Uh, so this whole talk is a distilled version of a case study Anthropic did on Kepler. If you scan that QR code, uh, we're the only company they've ever done a case study of, which is kind of cool.
- 1:02
Um, and so this is a distilled version of that. That has a lot more information about how we were able to do what we do, why, uh, it's been pretty impactful in financial services, and really where we go from here.
- 1:15
So my only goal with this whole talk is to convince you that AI is gonna start doing some very powerful things in terms of producing work product. So everything that I tell you is inevitable.
- 1:28
Whether it's Kepler or whether it's anyone else, we are already on this journey and this trajectory. Um, so we all better be ready.
- 1:36
So I first wanna observe every talk that we've seen in the financial services space so far has been about producing more. Like, how do I token max? How do I get AI to do more?
- 1:47
Very little of it is about how to actually make AI trustworthy or produce trustworthy products. And what's interesting is even terms like trust and verifiability have actually been largely abused.
- 1:59
Evals are not verifiable. You cannot take a non-deterministic LLM and eval your way to something deterministic. These are probability machines. And the kind of underlying reason for this is that AI has made a writing problem a reading problem.
- 2:15
We can produce insane amounts of content, whether that's code, whether it's marketing, whether it's, like, a DCF in record time, but we can't easily verify this. And that's because for years, the hardest part about this whole process was actually producing the work.
- 2:33
Edge and alpha came from people like Citadel being able to hire hundreds of analysts who could scour the internet and understand where any source of alpha could exist. So it really came from this idea of being able to consume content.
- 2:48
The problem is when a model reads everything, you have the most real version of alpha decay that you possibly can. There is no edge if everyone can look at Tegas and get all the same information.
- 2:59
So the hard part now is trusting what actually got produced by the model.
- 3:04
And this is kind of funny. This is not necessarily a finance problem. Every system that exists has some form of this. Software, we run CI/CD. We do unit tests.
- 3:16
We do integration tests. We have code reviews. When a doctor writes a prescription, a pharmacist fills that prescription. So if it says ten thousand milligrams of a medication, someone catches that.
- 3:28
We have a pilot and a co-pilot. We have an EMT that's a primary EMT and a secondary. In finance, we have maybe an overworked VP as a verification layer, but that concept doesn't really exist.
- 3:40
And now I'm gonna say something even more aggressive. Uh, the reason that people buy products like Bloomberg and FactSet is to displace culpability. When you buy a tool like that, you know that information is free.
- 3:52
It exists in SEC filings. But you believe that because a bunch of contractors or folks overseas vetted this data and stuck it in a central instance, at least if it's wrong, everyone on Wall Street has the same incorrect information.
- 4:06
And that's interesting in certain ways. It's also kind of a scary proposition. And that's because every one of these tools is read-only. You as an analyst look at Bloomberg, you look at FactSet, you consume information, and you produce the work product.
- 4:21
And that's where the biggest gap and biggest wall to real meaningful adoption across Wall Street has actually been. And so why does this actually matter? We can't use AI properly in this ecosystem.
- 4:34
There is a reason that analysts are still working till four AM, and there's a reason folks in investment banks are actually dying because of the hours they're putting in.
- 4:42
Because AI can produce a very confident answer, but when it comes to producing any kind of meaningful work product, we're totally lacking. Not only that, we have the SEC, we have the OCC, we have a number of these regulatory agencies who exist to make sure that you are not insider trading or you're not producing a trading decision
- 5:02
that can't be justified or backed by some set of primitives or some set of information that you can reliably say, "I made this decision because of these sources of information."
- 5:13
And so in this ecosystem, the biggest challenge is: how do I get AI to jump from producing the search technologies that it's doing right now to producing work product?
- 5:26
That can mean a fairness opinion. It can mean a DCF. It can mean an investment memo. It can mean looking at every SIM that your firm had five years ago and figuring out why your IRR number wasn't what it should have been or anything else.
- 5:39
And so the whole industry has solved this by citing things. When you search the internet with Claude or ChatGPT, it gives you a list of sources it pulled information from.
- 5:50
What's ironic is you can't easily curate those sources. So if you find my random Substack that says Palantir is gonna be three thousand dollars a share and you trade off of that, please go do that because it'll be very helpful for me.
- 6:02
But, uh, that's not a real vetted source. Seeking Alpha and some of these blogs or Reddit posts, they're data points, but they're not real vetted sources. So showing where you got the information from is only half the battle.
- 6:16
And that's where we- we're limited right now. The citation is effectively an after-the-fact audit. Now, a verification is a deterministic, repeatable, numerically verifiable mechanism that we can use to produce validity that a number is right.
- 6:33
That was a lot of buzzwords. A verification just means I can prove deterministically this number is right. So when I extract a revenue number from a 10-K, I can deterministically prove that that is the correct number from that 10-K.
- 6:47
So these are two sides of kind of the same game. One is showing where you got the sources from, and one is verifying that the information that you pulled out is actually correct.
- 6:57
This becomes challenging. It becomes challenging because verification is not a outcome. It lives in the path or the set of steps that are required for you to produce information that is v- valid for your individual firm.
- 7:15
Finance is one of the rare industries where two people can be-- have the same information and one can be long a stock and one can be short that stock with the exact same data.
- 7:24
And so, the idea of verification is not actually ground truth. It is verifying that you got an output that respects the nouns and verbs or the rules of your organization.
- 7:35
If a desk at Citadel-- like, a TMT desk at Citadel believes that a particular stock is going to go up and to the right, another TMT desk at Citadel may have the exact opposite belief, and they may have the same verification mechanisms that produce vastly different outcomes.
- 7:50
And so, this really comes down to something simple. What are the sources that we trust? What are the transformations that we apply on those sources to produce information that we care about?
- 8:00
And how do we make sure that's codified in a way that makes logical sense? And so, the whole point of this is simple.
- 8:07
This came from a ten K is not the val- the validation as a whole. Your job now is to figure out, as an individual, how do I use AI in a verifiable way?
- 8:18
And here's the honest answer: you don't. AI is great at doing non-deterministic tasks. It can solve problems in a way that's novel. It can figure out exactly how to do EBITDA adjustments, but it can't be the one responsible for doing the mathematical adjustments because it's a probability machine.
- 8:37
It is great at next token prediction. So, the second contention of this whole talk is that you cannot use AI to produce verifiable work product in finance without augmenting it with a deterministic substrate, which effectively means if you're a portfolio manager at Citadel, you have access to a number of deterministic tools that you use to make your
- 8:59
trading decisions. We need to model AI like that PM. It needs to exist in grounding. It needs to exist with a certain risk threshold and verifiability. So, here's how we did it.
- 9:12
Here's what Anthropic was excited about. We have three tenets that we use to ensure that numerical accuracy is a tenet of the Kepler platform, and that allows us to produce pretty powerful, pretty verifiably reliable information.
- 9:26
The first is atomic provenance, and I'll talk through all of these. The second is scope determinism, and the third is derivation chains, uh, which we'll all talk about. But the core premise is this: there are certain things humans should never do.
- 9:41
And I will tell you right now, I don't believe a human should sit there and look at a PDF ten K, ten Q, eight K or earnings call transcript and, on one screen, take that number and put it into an Excel model on the other screen.
- 9:54
Humans were not built for that. That's not-- Like, there's a reason we don't have databases just written in our heads. And so, let's break this down for how you can actually use AI to produce work product.
- 10:06
Let's talk about provenance. Provenance as a whole just means writing down exactly where you got the information. Now, uh, have a lot of respect for everyone else who got here on stage, but we did a mo-- we trained a model that was really good at extracting information.
- 10:20
It outperformed foundation models. It was ninety-four percent. Great. It's in the article. Who here would trade off of something that's ninety-four percent accurate?
- 10:29
Right. So fine-tuning your way on a probabilistic solution still is-- it's really cool and, like, TechCrunch will be really excited about it, but, like, no one else really cares about it.
- 10:39
And that's because a wrong number is still wrong if you're in that unfortunate six percent. So, with atomic provenance, what we do is the model writes effectively a reference to the number.
- 10:51
It cannot write the number or manipulate the number in any way. It doesn't even understand what that number is. We have tools that are really good at understanding numbers.
- 10:59
They're databases. They are systems that can codify information and read them and write them with appropriate fidelity. So that's the first piece of how we do things. Any time a model makes a decision, it makes the decision to figure out exactly where it got the number from and hand off to something that can write that number.
- 11:19
We then run it through a deterministic check, where any kind of a wrong number, if we can't verify it independently, we strip it out. That number will never make it to someone if it doesn't follow the deterministic check, the Provenance ledger, and most importantly, uh, the whole cycle kind of repeating at least a couple of times.
- 11:39
So this is not me saying, "Have ten models, and each indivi-- like, have OpenAI check Chat-- check, uh, Anthropic, and have Anthropic check xAI." These are not probabilistic systems evaluating each other's work.
- 11:50
There's a core canonical process of extracting a number, persisting it, and making sure that process actually occurred properly.
- 11:58
And this is when I say atomic, traditional atomicity in, like, database land. Second, scope determinism. This is-- This was a super controversial idea, like, a year ago, and VCs were like, "This is crazy."
- 12:10
Now, this half of this talk has been-- this session has been about this. Um, the model is really good at reasoning and planning. Intelligence is commoditized. GLM five two shows it.
- 12:19
You can download it off of Hugging Face right now. You have something as powerful as Opus four eight. Now, what- The model cannot do is math. And why would it?
- 12:29
Why would I run one plus one through a multi-billion parameter model instead of one CPU cycle? Unless you're companies that are giving bonuses on people token maxing, which is another hilarious thing.
- 12:40
Um, and so what the model does is the model decides what to compute. It never does the computation itself. And so from the Kepler platform perspective, what we do is we split the deterministic pieces of the model, which are none, from the non-deterministic pieces of the model, which are all of them, and we give the model the
- 12:59
right tooling and technology to calculate the deterministic pieces. Now let's get really concrete. A model can read something like, "Okay, I need to understand what net margin is. I know the right pieces of information to go to to get that data, but I can't be the entity that's actually running the code behind the scenes to pull that
- 13:17
number out of a PDF or parsing the XBRL behind the scenes to pull that information out." That is code. Now, the deterministic pieces of the platform pull that information out and persist it outside of anything the model understands.
- 13:30
And with those two together, we can actually produce a numerically accurate answer to the question of, like, what was the net-- what was the net margin of this stock or this company last quarter?
- 13:43
This also is a lot cheaper because, again, I don't need the model to do a bunch of stuff it shouldn't be doing.
- 13:49
Now, the last piece here is how do we actually do reconciliation? When someone asks about a ratio, like a gross margin or anything else, that doesn't exist in a filing, therefore, I can't just go look up what the gross margin is or what the set of EBITDA adjustments were.
- 14:06
The other thing that's really complicated is everyone calculates these ratios and these multiples differently. Everyone does enterprise value calculations differently. Things that are considered recurring or non-recurring may be unique.
- 14:18
So not only do we have to codify that in the processes that are run, but we need some kind of a chain of events to figure out what went into producing an individual number and what went into producing an outcome.
- 14:29
This is not any different than the chain of events that an analyst does on a desk at a hedge fund to make a risk reward or a trading decision.
- 14:37
It's just done by the model in a way that can be replayed and rewound.
- 14:41
And so that leads us to something fairly simple here. Uh, we have a system that knows which data points it's allowed to produce, meaning from structured filings, from numerical data, from any other ecosystem, it knows what it's allowed to produce, and it knows what it's never allowed to produce.
- 14:59
So if it's pulling things out of pros, raw tables, or anything else, it doesn't do that extraction. What this allows us to do is this allows us to do things like consolidate financial statements in seconds with every number tied back to its individual source.
- 15:16
Which means, not picking on any companies, but the CapIQs, the DLUPAs that are all using contractors for this, we don't need to do that anymore. We can actually create a financial model in a numerically accurate way that allows you to build work product.
- 15:31
We can build a DCF in the format that you actually want in knowledge the model will not hallucinate that a row exists that shouldn't exist.
- 15:38
Now, the really crazy thing and why I say this is inevitable, is everything that I'm telling you generally-- generalizes past finance. We're picking numbers here because finance cares about numbers.
- 15:50
But you can imagine a world where every court case, if you're a Harvey or a Legora, runs through the same process. A preprocessing step that understands that we can extract entities like case A versus case B and store that deterministically so we don't hallucinate citations.
- 16:07
Or every drug discovery formulation that exists in NIH white papers such that we never miss a compound or anything else. And so the kind of, uh, interesting dimension that we're entering is we're an ecosystem right now where we're almost like pre-SSL in the e-commerce ecosystem, where, like, what's the TAM of e-commerce?
- 16:30
Like, trillions. But how many people were comfortable putting their credit card number on the internet before there was security? Zero. So we're in the last step. AI can now produce verifiable work product across a number of industries, meaning the RAG platforms of the past are really, really helpful and really cool in codifying workflows, but there's a reason
- 16:50
that the foundational labs are going after every one of these. There's a reason that Claude for Science is not a deterministic system, but still a RAG-based system. And so the piece that should be really exciting about this whole thing is there is a piece of this that no one has built yet in a variety of disciplines, in
- 17:10
a variety of industries. We're really good at consuming tokens. In fact, there's a club here for people that consumed a billion-plus tokens. They're walking around with gold cards. It's kind of funny actually. [chuckles]
- 17:21
Um, but, like, that's kind of hilarious, right? Like, in what time in history has an employee been rewarded for your company to pay another vendor for how much money you're spending?
- 17:31
And so token maxing, I think, is now being thought of as not the right approach here to actually solve your problems. So the natural thing will become a rush to the bottom, which is an optimization problem, which we've seen over and over again.
- 17:46
If you rewind time, I actually sat on this stage four years ago, maybe not this particular room, talking about, uh, like, Snowflake Summit and Databricks Summit, where the idea was all of a sudden people want an ROI on top of-- like, to understand the ROI of their Snowflake investment or their Databricks investment.
- 18:04
And we started doing cost optimization. We started figuring out how to make sure every dollar of capital we put into Snowflake and into Databricks went to actually producing a pipeline that people were using.
- 18:15
That same trend is about to start, and we're figuring out right now how do we use the right tool for the right job, and sometimes you don't need a multi-billion parameter model when one CPU cycle will just work.
- 18:27
So kind of wrapping this up, AI has made producing work completely, I'd say nearly free, but, like, thank you VCs, heavily subsidized. The reading problem is still very open, and you verifying a data point is not enough anymore.
- 18:44
The system has to be able to trap, trap-- or track its own provenance and actually ensure that the numbers that you're pulling represent your own unique company philosophies. Citations got us, like, fifty percent of the way there, but the next half of the verifiability and provability is going to be how we start using this in real, like,
- 19:05
valuable, verifiable work. And the interesting thing here is the work product itself is the proof. In code, we have, you know, unit tests. We have every single pull request and every commit and every code review on that pull request stored in perpetuity.
- 19:21
There are companies here trying to mine that information to create a representation of your on- your ontology right now on a company-specific basis. We need that same ecosystem in finance.
- 19:32
So let's just say this. All these problems are solved at this point. The last remaining mile is gonna be that personalization. So the second version of this in 2027 is hopefully one of us will be on stage talking about how we are now able to build verifiable ontologies that actually proxy our investment processes instead of saying, "How
- 19:51
do I not spend a trillion tokens to solve this individual problem?" Um, so we're also, uh, me and Susanna, we're both from Kepler. Um, we're growing pretty quickly. Obligatory, come join us if these problems are interesting to you.
- 20:05
Uh, and yeah, I think we're starting in finance now. We'll be in a lot of different dimensions pretty quickly. Um, so thank you so much and happy to answer any questions. [audience applauding]
- 20:19
Yeah, go ahead.
- 20:20
I have a question about provenance. So you mentioned there's a provenance ledger where that piece of number comes from. Like, how can it-
- 20:27
Yeah. So the question is about provenance and from the provenance ledger, where does the number actually come from? Um, at its core, the number comes from three different things.
- 20:34
It comes from extracted information from the filings. It comes from either a mathematical calculation that we do as a derivative production, so, like, a ratio or something else, or it comes from your internal documents or other internal pieces of information that operate in conjunction with that external data to produce that individual data point.
- 20:52
So any time the model effectively is responsible for telling some entity to do an IO operation, that's part of the provenance chain.
- 21:02
Yeah.
- 21:02
Can you talk a little bit about, um, what your customers are most excited about in your product?
- 21:10
Yeah. So the question is, um, what are our customers most excited about? It's funny. Uh, everyone wants AI. Like, the dream is the AI portfolio manager. The portfolio managers don't want the AI portfolio manager. [chuckles]
- 21:22
Like, they want the AI analyst. And so the thing they're most excited about is a way of rapidly producing, rapidly doing kind of the repeatable, painful tasks that their analysts are doing.
- 21:33
Things like, a analyst actually sits there and listens to an earnings call transcript. If we didn't have to have an analyst do that, it would be amazing. Or an analyst sits there with, like, fifteen tabs, and they're opening every 8-K and 10-K over the last, you know, whatever years to create the V zero of a financial model.
- 21:51
So they're most excited about getting their analyst time back, which is the honest answer.
- 21:56
And these are expensive analysts. Like, these-- Some of these folks make six, 700K a year to do this.
- 22:05
Cool. I'm happy to answer any more questions outside as-- actually, yeah, outside as well. I don't know if we're at time. Yeah. The [REDACTED:gender] in the back. [upbeat music]