Minervian AI Is Not an LLM Wrapper
“LLM wrapper” means a thin layer of prompt engineering over a third-party large language model (LLM): the LLM does the work, including the reasoning and research, while the product supplies only the prompt and the interface. Two questions follow from that: can a wrapper deliver institutional-grade cash flow modeling, and why pay for a wrapper on top of ChatGPT or Claude when you could use either directly?
Minervian AI is built on a deterministic calculation engine instead, because that is what commercial real estate underwriting actually requires: the leasing commissions on a commercial lease, which can only be calculated accurately once its entire monthly cash flow is projected; recoveries, which can only be computed once a grossed-up budget is set and the actual annual budget is projected across the full investment horizon; and interest expense, which can only be capitalized once monthly funding, financing fees, and rates are projected across the life of the deal.
None of that is what LLMs, or a thin wrapper around one, were built for. They excel at qualitative reasoning — synthesizing market insight and underwriting output into an opinion. What they do not do is project a monthly cash flow. And without that monthly cash flow, an underwriting misses the nuances of a real deal: the special incentive an anchor tenant has to be given, the guarantee fee that dilutes levered IRR, the reassessed tax that cuts into exit NOI.
Minervian AI is built for exactly this problem. The engine handles what an acquisitions team builds every day: the monthly cash flow, the lease rolls, the recoveries, the capex schedule, the debt modeling, the waterfall, the edge cases. There is no neural network inside it — just deterministic math that returns the same output every time.
Is AI involved at all? Yes, and this is where it outperforms legacy software: no more manually extracting data from a rent roll, no more combing an 80-page OM for the OpEx assumptions, no more entering values field by field into a UI. The AI is built to pull all of that for you and feed it into the engine in minutes, if not seconds. It proposes the assumptions your documents omit, updates the model when you describe a change in a sentence, and flags what is still missing for a complete underwriting.
The short version: generic LLMs, and wrappers built on them, reason their way to a number — a back-of-the-napkin estimate, not an actual calculation. Minervian AI is built on the calculation engine commercial real estate requires: monthly cash flow, lease projection, financing, waterfall. The AI extracts data and maps it into the engine, but the engine delivers the output — no hallucination, no invented line items, no improvised formulas.
Minervian AI vs. Wrappers
| Item | Minervian AI | Wrappers |
|---|---|---|
| Reading a rent roll, OM, PDF, Excel, or screenshot | Yes — reads and extracts from all of these directly. | Also yes — extraction is not the differentiator; what happens to the data afterward is. |
| Mapping extracted terms onto structured input fields | A predefined data schema means inputs never get mixed up — a multifamily unit rent, for example, can never be mistakenly written as an office rent PSF. | No data schema to properly store or reuse what was extracted, so structure has to be reconstructed on every run. |
| Deliverables | A granular monthly cash flow down to the waterfall, plus a deal summary with everything an IC memo needs — budget, sources & uses, profit & returns, acquisition, financing, leasing and sale assumptions, milestones, waterfall. | May produce a summary, but not a granular cash flow model. |
| Consistent calculations | Because the calculation engine is a fixed, persistent system, outputs stay consistent for the same inputs. | If a wrapper relies only on an LLM’s chain of reasoning, there is no persistent engine underneath it, so outputs drift over time for identical inputs. |
| Where the arithmetic happens | A fixed engine — dozens of TypeScript modules across lease projection, financing, and the waterfall — with no LLM call inside any of them. | Inside the LLM’s response. |
| Proposing the assumptions your documents omit | Reviews the data schema comprehensively and identifies missing key inputs before an underwriting can be completed — e.g., exit cap rate, interest rate. | May ask for additional information, but retention of prior inputs drifts over time, and what gets flagged is not comprehensive. |
| Flagging gaps, contradictions, and odd-looking returns | The data schema lets it flag contradictions directly — e.g., an OM stating two different cap rates. When an output looks off, like a negative IRR, it prompts a review of the relevant sections to find and fix the bad input or typo. | May offer an opinion that a number looks too high or too low, but never questions its own math. |
| Editing the model from a sentence | Surgical — only the affected inputs update, the same way you would edit select cells in Excel. | The new instruction is appended to an ever-longer, unstructured conversation, with no structured place to store the inputs accurately. |
| Re-compute | Because the calculation engine is persistent and deterministic, a recompute takes well under a second, and outputs recalculate accurately for granular changes — e.g., increasing rent growth by 0.25%. | Requires sending the entire conversation and context back to the LLM provider for a full re-generation. Can take minutes, and the new output is regenerated with back-of-the-napkin reasoning, not a robust calculation. |
| Explaining how any section calculates | The AI Advisor not only takes instructions to modify inputs — it also explains how each section works, removing the need for a certification course or a call to customer service. | May explain its back-of-the-napkin math, but there is no persistent engine running those calculations, and no way to verify the result. |
| Lease-by-lease monthly projection | Deterministic engine built for every form of commercial lease: rent bumps by % or $, customizable free rent, a full suite of recovery methods per tenant (gross over base year, net, fixed, custom), leasing commissions calculated on the full lease value, renewal probability, and second-generation lease cash-flow projection. | Guesswork, not customizable lease by lease. |
| Financing modeling | Supports most loan types — land, construction, bridge, mezzanine, permanent — in a multi-tranche structure, with granular monthly calculation for funding by category, interest, amortization, and fees, priced off a SOFR curve. | Estimates only. |
| Equity waterfall tiers and distributions | Deterministic engine, configurable for any waterfall structure: IRR hurdles, preferred return, catch-up, and promote tiers. | Guesswork. |
| Returns — levered and unlevered IRR, equity multiple, DSCR, yield on cost | Deterministic engine, computed on the full monthly projection. | Estimates only. |
| Model dependency | Supports any LLM for extraction and input steps. Even if every LLM provider were down at once, the core calculation engine still runs — inputs would just need to be entered manually. | Complete dependency on one LLM; outputs vary with that model’s quality, reasoning style, and even available compute. |
| Auditability | The entire monthly cash flow exports to Excel for verification. Tricky sections — loss to lease, recoveries, commissions — trace back to intermediate schedules for full inspection. | A number in a paragraph, with no schedule behind it. |
| Iterative calculations (interest, recoveries) | Circular dependencies — a construction loan sized against total project cost, which depends on the loan — resolve by iterating to a 0.1% tolerance. | Resolved by asking the model to try again. |
| Hallucination — can it invent a line item? | No. The engine has fixed formulas and defined input fields, so the AI cannot add a line to make a deal work. | Yes — nothing structurally prevents it. |
| Cost behavior | Tokens pay for reading documents and proposing inputs. The engine itself runs for free, no matter how large the underlying model gets. | Token spend scales with model size and conversation length, because every prompt rebuilds the structure from scratch. |
| Regression testing | 96 test files in the web application alone, covering the waterfall engine, exports, and model logic. | Prompt changes ship untested. |
Which half does what
Every task in an underwriting falls on one side of this line. Nothing sits on both.
| Task | Handled by | Why |
|---|---|---|
| Lease-by-lease monthly projection | Deterministic engine | Fixed formulas, applied identically to every deal |
| Expense recoveries grossed up per tenant | Deterministic engine | Runs off the full operating budget, not a flat percentage |
| Multi-tranche debt — interest, amortization, refinancing, fees | Deterministic engine | Ten fee types flow through sources and uses and levered cash flow |
| Equity waterfall tiers and distributions | Deterministic engine | A separate, independently tested engine of its own |
| Returns — levered and unlevered IRR, equity multiple, DSCR, yield on cost | Deterministic engine | Same inputs, same numbers, every run |
| Reading a rent roll, OM, PDF, Excel, or screenshot | Language model | Extraction is a language task — what LLMs are genuinely excellent at |
| Mapping extracted terms onto structured input fields | Language model | Fields are defined in advance; the model fills them, it does not invent them |
| Proposing the assumptions your documents omit | Language model (Auto-Complete) | Most OMs supply only 30–60% of what a complete underwriting needs |
| Flagging gaps, contradictions, and odd-looking returns | Language model (validation) | Judgment about whether a number looks wrong is a reasoning task |
| Editing the model | Both | A single quick change — go to Exit, update the cap rate — is often faster by hand. A change that spans many inputs, like “change rent growth to 2% across every building,” is faster to describe to the AI, which applies it in one batch. |
| Explaining how any section calculates | Language model (AI Advisor) | Describing the engine, not replacing it |
What the engine actually is
The engine is the core product of Minervian AI, not a formula library bolted on at the end. It is written in TypeScript, a strongly-typed evolution of JavaScript, and one orchestrator calls into each of the following for every deal:
- Dozens of modules across four engines. Lease projection (rent schedules, recoveries, renewals, leasing commissions), investment cash flow — financing, costs, timeline, returns, the largest of the four — the equity waterfall, and the multifamily cohort engine, all called in turn by one orchestrator file running to roughly 1,700 lines. No model call inside any of them.
- Lease cash flow projection. Every commercial lease is projected individually — a rent schedule resolved step by step (percentage or PSF increases, each evaluated relative to the prior step), flat or tiered leasing commissions, free-rent windows, and renewal terms — with new-lease and renewal scenarios probability-weighted into one blended row rather than averaged as a single tenant.
- Recoveries calculations. Each building carries its own grossed-up occupancy target, and operating expenses are grown year over year before being allocated back to tenants under whatever recovery structure — gross, net, fixed, expense-stop — that lease specifies.
- MF cohort cash flow projection. A separate engine — with its own contract and golden-file tests that treat any output drift as a breaking change — projects multifamily units by cohort: turnover pace, renovation downtime modeled as a queue, concession amortization over the free-rent period, and market rent growth, each tracked month by month instead of averaged across the building.
- Revenue, operating expenses, and NOI. The monthly NOI waterfall — revenue, vacancy, credit loss, opex — is computed in exactly one place and reused everywhere it is shown, replacing what used to be three separate implementations that quietly disagreed with each other, including on whether credit loss applies before or after vacancy.
- Leasing costs (TI/LC). Leasing commissions can be structured as a flat percentage of lease value or as a New-York-style tiered schedule that steps down by lease year — either way, free rent and recoveries can be included in or excluded from the commission base — and tenant improvement and landlord’s-work costs are resolved per space alongside them.
- Soft and hard cost projection. The soft cost template provides 12 standard categories, with the ability to add custom ones of your own. Hard cost modeling was built to support ground-up construction, value-add renovation, deferred capex, or simply maintenance on a stabilized deal — any number of line items, projected straight-lined or as an S-curve, with CM fee and contingency resolved against the full cost stack.
- Financing modeling. Each loan’s rate is decomposed into benchmark, spread, and whether a rate cap is binding, priced off an embedded SOFR forward curve sourced from CME’s own published curve; fees are expressed as a percentage of the cost they sit on, so a fee naturally follows the spend curve instead of landing as one lump sum.
- A convergence loop for circular dependencies. A construction loan sized as a percentage of total project cost depends on its own carry costs — interest and origination fees — which depend on the loan amount. The engine iterates until the total resolved loan amount changes by less than 0.1% between passes, rather than asking a model to guess the fixed point.
- A separate waterfall engine. A proprietary engine that supports any form of waterfall — IRR hurdles, preferred equity, profit-sharing with catch-up, special or deferred bonuses — built for any number of investors, classes, or tiers of contributions and distributions.
- A regression suite that runs on every change. 46 test files exercise this engine directly — lease projection, financing, and the waterfall — out of 96 across the web application as a whole. Prompts are not a substitute for tests.
The engine is also where the institutional conventions live — probability-weighted renewal and new-lease scenarios, recoveries grossed up per tenant off a full operating budget, TI and leasing commissions resolved per lease and per renewal, general vacancy and credit loss as explicit inputs. Those are not things you can prompt into existence consistently. They are things you implement once and test.
Why this is an architecture choice, not a feature
The tempting alternative to this product is an LLM wrapper, which is much easier to build: give a strong LLM the documents, ask for a deal summary, and render whatever comes back. It demos well. It fails on the second run, in four specific ways that no amount of prompt engineering closes.
- Drift. Re-deriving the model structure on every prompt means the structure changes. Recovery structures get simplified to avoid complexity, vacancy gets treated inconsistently across the projection, reversion stops using stabilized NOI. Even more counter-intuitively, one small change request can destabilize everything sent back to the LLM just as a draft is getting close to acceptable, and the new output can come back worse, not better. Minervian AI calculates the result with a deterministic engine instead — think spreadsheet formulas, not a chatbot. Increase the cap rate by 0.25%, and the exit value and returns move accordingly, but nothing else does: no drifting interest expense, no fluctuating NOI, no CM fee that quietly changes.
- No audit trail. A figure produced inside a paragraph has no schedule behind it. You cannot foot it, and you cannot tell an investment committee where it came from.
- Token cost that scales the wrong way. Because an LLM has to recompute the deal from scratch each time, token spend tracks the size of the model and the length of the conversation, not the size of the change — adjusting one lease should not cost what building the entire deal did. On Minervian AI, a user can clear the whole conversation, ask the AI for one change — “change opex inflation to 2.5% across all buildings” — and it applies just that, efficiently.
- Vendor coupling. If the arithmetic lives inside one provider’s LLM, that provider’s next model release becomes a change to your numbers, and their deprecation schedule becomes your migration.
Building the engine is the slower path. Minervian AI embraces this path because it is the only one that produces a model somebody will sign their name to.
Is Minervian AI just a wrapper around ChatGPT or Claude?
No. A wrapper passes your question to a third-party LLM and returns what comes back — the LLM does the work, the product supplies the prompt and the interface. Minervian AI splits the problem in half. An LLM handles the language half: reading documents, mapping terms onto structured fields, proposing missing assumptions, and editing the model from your chat. The core identity and IP of the platform, however, is a purpose-built deterministic engine — written in TypeScript, a strongly-typed evolution of JavaScript — that handles the arithmetic half: dozens of modules across lease projection, financing, and the waterfall, built specifically for the real-world complexity of commercial leases, property cash flow, financing terms, and waterfall structures. This engine relies on no LLM.
Does the AI perform the calculations?
No, and that is deliberate. Asking a language model to compute a levered monthly cash flow across a multi-tranche stack is asking it to do mental, back-of-the-napkin math on a problem where being approximately right is not acceptable for an investment committee memo. Instead, the AI extracts terms and maps them onto defined input fields, and a proprietary prebuilt engine runs the same formulas on every deal. Two runs of the same inputs return the same numbers, and each figure traces back to an input you can inspect and change.
Why does determinism matter in underwriting?
Because a model that returns different numbers on different runs cannot be defended. An investment committee asks why the IRR moved; the answer has to be "because this assumption changed," not "because the LLM sampled differently." Reproducibility is the floor that makes everything above it auditable: if a figure moves, an input moved, and you can find which one. It is also what makes a saved version worth comparing against — deals are versioned here, and the comparison is only meaningful if the engine is stable.
What happens when the underlying LLM changes or gets deprecated?
Your numbers do not move. The platform was built to support any LLM, precisely to avoid third-party dependency. Swapping the LLM can change how well a document is read or how good a proposed assumption is, but it cannot change the predefined input schema, or what the engine computes from a given set of inputs. We built and own that engine.
How is this different from underwriting with ChatGPT directly?
A general-purpose LLM reads a rent roll well, because extraction is a language task. What it cannot do reliably is rebuild a commercial-grade underwriting model on every prompt: recoveries grossed up per tenant off a full operating budget, multi-tranche levered cash flow, and a promote waterfall with accruing preferred return. Because an LLM re-derives the structure each time, outputs drift between runs, there is no schedule behind any figure, and token spend scales with the size of the model rather than the size of the work. Prompting from scratch typically takes 30–60 minutes and returns different numbers each time; a first draft here takes 5–10 minutes and returns the same numbers each time.
How is this different from an AI spreadsheet add-in?
An add-in puts a language model next to a template you own and maintain. That works until the deal needs something the template does not have — a fourth tranche of financing, a partial discharge, a different waterfall structure, a second asset class in the same deal — at which point you are editing formulas under time pressure. Excel does not handle commercial leases well either. A grossed-up budget, recoveries, and commissions that can only be calculated accurately once a 15-year lease is fully projected are exactly why firms turn to Argus. Minervian AI is built for that level of complexity, at a fraction of the cost, with a far more natural workflow — talk to it, instead of spending your days entering assumptions field by field. The modeling logic here is the product, maintained and regression-tested rather than living in a workbook. The platform does export to Excel, but that is not where the model lives.
How can I check that a number is right, without reading source code?
Three ways. Reproducibility is the first: identical inputs return identical numbers, so a figure that moves means an input moved. Second, the intermediate schedules are outputs in their own right rather than hidden inside a result — the grossed-up operating expense budget behind every recovery, cash flow by tenant and by cohort, and a per-tier waterfall schedule showing opening balance, accrual, and what each tier was paid, which foots line by line. Third, every figure traces back to an input you can change, and the AI Advisor will explain how any section calculates on request.
Does "not a wrapper" mean less AI?
The AI is pointed at the work it is actually good at, so more of it is useful. Auto-Complete runs in loops, identifies missing inputs, and proposes assumptions across the whole model. Validation flags contradictions before they compound. The model can be rebuilt by conversation instead of form-filling. None of that would be possible if the AI were also busy trying to compute a debt schedule. Minervian AI does not try to sell you a deal summary that sounds fluent and coherent while papering over wrong assumptions. What it does, extensively, is flag missing information, inconsistent assumptions, and unreasonable outputs until the underwriting is robust. Flags and warnings are not pretty, but they make the final product defensible in front of an investment committee.
For the complete platform overview — every asset class, deal type, and mechanic — see the CRE underwriting software page, or read why an LLM alone can’t underwrite a deal.