How Kepler Built Verifiable AI for Financial Services

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.

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.

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:

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.

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.

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:

1. Resolve the model-selected reference through the numerical data system.
2. Extract and persist the value with its provenance.
3. Check the value independently through the deterministic verification process.
4. Remove values that cannot be verified rather than passing them to the user.
5. 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.

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:

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.

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.

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.

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.

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.

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.