What Is Financial Reasoning Infrastructure?

Every layer in the modern finance stack has infrastructure underneath it.

Your transactions live in Rillet or NetSuite — an ERP that records, types, and reconciles every dollar. Your data lives in Snowflake or BigQuery — a warehouse that structures, versions, and queries it. Your reports live in Hex or Metabase — a BI layer that reads from the warehouse and renders what happened.

But your financial model — the forecast, the three-statement, the scenario analysis, the operating plan your board reviews — lives in a spreadsheet.

Not infrastructure. A grid.

That grid has no type system. Anonymous cells hold revenue assumptions, headcount counts, and percentage growth rates side by side, indistinguishable from one another. The dependency graph — the chain of "this number flows into this number" — is implicit in formula references no one can read at a glance. There is no audit trail. When your CFO opens the model next quarter, they cannot ask: "what did this assume on March 15th, and who changed it?"

Financial Reasoning Infrastructure (FRI) is the name for the layer that fills this gap. It is the computation layer for financial models — the substrate that makes them typed, auditable, and re-derivable.

What "infrastructure" means here

In software, infrastructure is the layer underneath everything else. Postgres is infrastructure. You write SQL; you do not think about how bytes are stored on disk. Stripe is infrastructure. You call the API; you do not write your own payment processor. dbt is infrastructure. You define transforms; you do not manage the warehouse execution.

Infrastructure has three properties that matter:

1. It is a stable substrate — other things are built on top of it, reliably
2. It abstracts the implementation — you use it without caring about how it works internally
3. It produces a verifiable output — you can check that the infrastructure did what it said

FRI applies all three to financial modeling:

1. Your financial model is built on a typed IR — a stable representation that outlasts any single spreadsheet
2. You define assumptions and formulas; the engine handles the compilation, dependency resolution, and export
3. Every compile produces a signed receipt — a tamper-evident record that the computation happened exactly as specified, re-derivable by anyone with your model file

This is infrastructure in the same sense that Postgres is infrastructure. The abstraction just happens to be financial, not relational.

What makes reasoning "financial" specifically

Financial reasoning is not generic quantitative reasoning. It has specific properties that distinguish it from other computation:

It involves assumptions with uncertainty ranges, not known inputs. A financial model does not compute from facts. It computes from beliefs — about growth rates, churn, margins, market size. The model is only as good as the assumptions, and the assumptions are always wrong in some direction.

It compounds across time. Revenue in month 6 depends on decisions made in month 1. A churn rate of 2% versus 1.5% seems small in isolation; across 24 months it completely changes the trajectory. The model must be able to trace these dependencies — not just compute point estimates.

It must be auditable. Someone will check your work. A CFO checking the board deck. An investor reviewing your assumptions in diligence. An auditor looking at the operating model. The question they will ask is not just "what does this say?" but "how did you get here?"

It is decision-oriented. The model exists to answer "should we do X?" — not just to report what happened. A good financial model is a reasoning tool, not a reporting tool.

These properties — uncertain assumptions, temporal compounding, audit requirement, decision orientation — define what financial reasoning infrastructure needs to provide:

1. Typed assumptions — named drivers with explicit units, not anonymous cells
2. An explicit dependency graph — the computation order is declared, not inferred from formula chains
3. Deterministic compilation — the same inputs produce the same outputs, every time, exactly
4. Computation provenance — a signed, re-derivable record of what was computed

Computation provenance: the core concept

The term that captures what FRI uniquely enables is computation provenance.

Computation provenance is the signed, re-derivable record of how a financial conclusion was reached. Not just the conclusion. Not just the inputs. The full chain: inputs → assumptions → dependency graph → compiled outputs → signed receipt.

The signed receipt is the atom of computation provenance. Flatland generates one on every compile. It is:

• Tamper-evident — signed with HMAC; any modification to the model invalidates the receipt
• Re-derivable — anyone holding your model file can recompile and get the same receipt, independently verifying the computation
• Client-owned — Flatland does not hold the receipt or the model; they live on your machine

This is what "architecturally verifiable" means. Not a compliance certificate. An architectural guarantee: the computation is a pure function, the receipt is the proof, and the proof is yours.

An investor reviewing your assumptions sees not just the output — they can re-run the model and verify that the output follows from the assumptions, deterministically. That is a different quality of financial reasoning.

Same inputs, same compiled outputs, every time. That determinism is what makes the receipt re-derivable — the embed above is the provenance pattern, running.

What FRI replaces — and what it does not

FRI replaces specific things:

Excel as the system of record for financial reasoning. Not Excel as a tool — Excel has many legitimate uses. But Excel as the place where the authoritative version of your financial model lives, with no type system, no dependency graph, no audit trail, and no way for an AI agent to read it programmatically. That role moves to a typed compiled model.

ChatGPT-generated financial models. An LLM can produce a model that looks right. It cannot produce a model where the same inputs deterministically generate the same outputs. It cannot produce a signed receipt. It starts from scratch each session. The output is unstructured text pretending to be a model.

Python scripts stitched together per engagement. Finance Engineers often build Python scripts for modeling work. These are better than Excel in some ways — version controllable, reproducible — but they are not composable, not typed in the financial sense (a number is a float, not a Revenue driver), and not callable by AI agents without custom wrappers.

FRI does not replace:

• Your ERP (Rillet, NetSuite) — FRI sits above the GL layer, consuming actuals from it
• Your BI tool (Hex, Metabase) — FRI is the computation layer, not the reporting layer
• Your AI coding tool (Claude Code, Cursor) — FRI is what they call, not what they replace

The Finance Engineer's stack with FRI is additive, not a replacement:

GL / ERP:           Rillet, NetSuite    -> records what happened
AI automation:      Claude Code + MCP   -> automates process
Reporting / BI:     Hex, Metabase       -> reports what happened
Financial models:   Flatland (FRI)      -> reasons about what will happen

How to use FRI

For Finance Engineers: your AI agent calls the Flatland MCP server. You describe the business — drivers, formulas, assertions. The agent builds the typed model. The engine compiles it. The receipt is generated and handed to you. You own the model (a file at ~/.flatland/models/). The server retains nothing.

First compile takes 8 minutes from zero. Install Flatland

For Founders: the Workshop shows what a compiled model looks like before you install anything. Load a preset — a three-statement model, an LBO, an operating plan. Drag a lever. See the cascade. Open the Workshop

For Platforms: the HTTP API and MCP interface are callable from any agent, any language, any orchestration layer. Read the API docs

The category is forming now

Financial Reasoning Infrastructure is a new term because it names something that only became possible in production-grade form in 2025–2026. The pieces that enable it converged:

• Typed model IRs that can be versioned, compiled, and diffed
• MCP that gives AI agents a standard way to call tools, including financial computation engines
• Cryptographic receipts that make computation provenance mathematically verifiable, not just auditable in the informal sense

The analogies that will make this obvious in retrospect:

"Analytics engineering" was not a job title in 2015. By 2020, it was a career track. dbt named the function; the practitioners arrived.

"DevOps" was not a role in 2010. By 2016, every infrastructure team had one. The convergence of code and operations needed a name.

"Finance Engineer" is in its 2013 moment. The practitioners exist — Controllers, VPs of Finance, Heads of FP&A — who are already using Claude Code to automate finance processes, already connecting AI agents to ERPs via MCP, already thinking about the model layer as code rather than spreadsheets. They don't have a category name yet.

FRI is the infrastructure layer that makes the Finance Engineer's work a real discipline rather than a collection of clever scripts. And like every infrastructure category, it will feel obvious — inevitable — once it has a name.

This is the name.

Flatland is Financial Reasoning Infrastructure. If you're building the model layer for a company that takes financial reasoning seriously, start here. See it as a live model: the three-statement preset, or read what a Finance Engineer is.