Deterministic AI for real estate underwriting: Where does the math actually happen?

The useful debate is not simply whether a language model can do the math. Mathematical capability is not the same as being a trusted calculation engine for real estate underwriting. For investors and lenders, the more important question is where the math actually happens, who controls the methodology, and whether the result can be verified, reproduced and defended.

An LLM can’t be trusted to do real estate underwriting on its own; ask the same complex calculation question ten times and you’ll get different answers across runs. Anthropic ships Claude for Excel and flags it as not recommended for audit-critical calculations without verification. Even the companies building frontier models are emphasizing the need for verification. For high-stakes numbers, the LLM itself should not be the calculation engine.

Separating interpretation from calculation

Drawing that line is what we mean by “deterministic AI”. Not “the model usually gives the same answer.” Not “we turned the temperature down.” Here, deterministic means that teams externalize the calculation method from the language model and encode it in controlled, versioned, tested and auditable logic. The AI can help decide which documents to read, which issues to flag, and what to interpret. But the number itself should come from a governed calculation path that can be inspected, reproduced, and defended.

Anyone who has dropped a rent roll into a chatbot and gotten a tidy table of numbers back might object that the models clearly can do the math. Look closer at what actually happened. The model may not have computed those numbers the way it writes a sentence. It likely used a tool. Maybe it wrote and ran code. Maybe it called a spreadsheet formula, a database query, a calculator, a financial-modeling function, or a connected workflow.

Tool use can make the arithmetic right, but it does not automatically make the methodology governed. Properly locked, versioned, tested code can run the same way every time. Ephemeral code or tool calls generated mid-workflow do not deserve that trust automatically. What matters is whether the tool, formula, assumptions, inputs, and methodology were approved before the number reached the page.

Reading and interpretation can start with the AI model, which earns its keep by handling messy documents, inconsistent formats, extraction, classification, anomaly detection, and first-pass judgment.

But calculation, and any material number a lender or investment committee will rely on, belongs on the deterministic side. It calls for locked methodology, controlled formulas, governed inputs, and a traceable path straight back to the underlying document, data record, or approved assumption.

Think of it as the difference between a person and a calculator. Pointing a pure LLM at the math is a bit like having a sharp analyst working without a calculator: when the numbers get complicated enough to require a calculation engine, it’s possible for a human expert to be confidently wrong. Wall the AI off and run everything through fixed code and you have a calculator with no operator. It is consistent and inspectable, but on its own, it can’t read the messy lease, doesn’t know which number to compute, and has no judgment about what the deal actually needs. The tool you want is the analyst holding the calculator. The whole question is which work goes to the hand and which goes to the machine.

Where the work should happen

So the question worth asking about any of these tools is “where did you draw the line, and can you defend it?” Think of it as real estate financial model governance, but expanded to encompass the AI age, which focuses on how the LLM works with external tools, and whether it’s overreaching.

A simple way to think about the line is this:

AI is strongest where judgment, interpretation, and messy context matter. Deterministic systems are required where the output must be consistent, auditable, and defensible.

What do ask to understand where to draw the line

One question pressure-tests the deterministic side of that line, the part that matters most when money is involved: given the same inputs and methodology, does it compute the same way every time?

Consider a cap rate. Everyone agrees it’s net operating income over purchase price. But which NOI? Forward twelve months, trailing twelve, or trailing three months of income annualized against trailing-twelve expenses? At what growth rate? Adjusted for the tax and insurance reset after a sale? Management fees in or out? The math is a trivial Python script. The methodology is where the number actually gets made, and there are a dozen defensible ways to get there. That is why “the math was right” is not enough. The arithmetic can be perfect while the underwriting answer is wrong, because the system selected the wrong methodology for the specific deal.

Most real estate shops have a standard for those choices. That is how last week’s deal and this week’s deal stay comparable. The problem is that the standard lives in an investment committee memo, a senior person’s head, an old template, or a half-documented underwriting policy, while the live model gets copied, modified, patched, and handed from analyst to analyst. Over time, the model can drift from the standard even though everyone assumes they’re following the standard. An LLM or agentic workflow can drift too; as context degrades across a session, it may quietly use a different method than it used an hour ago. Even if a model or tool-checker confirms the math is technically correct, it may not catch the more important failure: the system abandoned the approved path to get there.

This is a common real-world failure. Plenty of firms have a methodology and still run patched-together Frankenmodels with formulas copied from one deal to the next, one-off tabs added for unusual situations, hidden overrides, broken links, stale assumptions, and legacy logic that only one person really understands. The firm may still have a standard, but the working model has slowly become its own undocumented version of that standard. Without governance, AI simply modernizes the same failure mode.

Vibe coding and agentic engineering do not automatically fix this. The messy Excel file of the 2010s can become the vibe-coded Franken-pipeline of today. It might be faster and more automated, but it can be harder to inspect. At least with Excel, many firms had a few power users who knew where the bodies were buried. In an agent-built pipeline, the same drift can happen behind code, tools, prompts, and generated workflows that no one fully owns.

The fix centers on putting the calculation on the deterministic side of the line, in a locked engine that doesn’t change underfoot. If the answer to “where does the math happen” is simply “inside the language model itself,” the line is in the wrong place.

Better models will reduce some errors, but they will not eliminate the need for deterministic checks. One important direction at the frontier is moving that way: pairing model reasoning with verifiers, proof checkers, tools, tests, and external systems that can confirm the answer rather than merely trust the model’s reasoning. You can see the same pattern in Google DeepMind’s proof-checked math-olympiad work, Jason Wei’s verifier’s rule, and the broader shift toward systems where important outputs can be checked, reproduced, and defended. Verification and auditability are not temporary crutches. They are becoming part of the architecture around frontier models.

Deterministic AI should be table stakes. Accountability is still the hard part.

A locked calculation engine should be the baseline, whether a firm is building its own AI tools or buying from a vendor. But the harder question is accountability: who owns the number, who approved the method, who reviewed the exceptions, and who can explain the result when a lender, investor, auditor, or IC member asks? A model can generate the number. It cannot stand behind it.

What is harder to get is accountability. AI can produce more output than any analyst could reasonably review line by line, which makes it tempting to treat volume and polish as substitutes for accuracy, defensibility, and fit. They are not. When a lending or investment decision on a $20 million shopping center rests on an AI-assisted report, someone has to own the path from source document to final number: the extraction, the assumptions, the formula, the methodology, the review, and the exceptions.

Whether a firm is building these systems internally or evaluating a vendor, the discipline is the same: draw the line intentionally, and be able to defend it. Lean on the LLM for what it’s genuinely good at, without letting model reasoning become the calculation engine. Keep the deterministic core locked and auditable, without walling off the reading and insight that make AI worth using. Real governance isn’t rigidity, and it isn’t “let the AI figure it out.” It’s the discipline of holding a line drawn deliberately. Every shop looks at deals a little differently, and a good platform lets each keep its own methods while making every one of them consistent and auditable. The lesson never changes: flexibility without governance is how you get the Frankenmodel, and governance without flexibility is a tool nobody will use.

Ask where the math happens. Then ask who’s standing behind the number, and where the line was drawn. The first question reveals whether the tool has a governed architecture or just an impressive interface. The rest is the whole game.