The model is allowed to have opinions. It is not allowed to do arithmetic.
That single rule is the difference between a number you can defend and a number you have to trust. Everything below follows from it.
You hand a language model an offering memorandum and ask it for a cap rate. It gives you one. It looks right. It is formatted beautifully. Ask again tomorrow and you may get a different one, and neither answer can tell you which line it came from.
The failure is not that models are bad. It is that arithmetic is not a language task. A model predicting the next token is doing something structurally different from computing a debt service coverage ratio, and the output looks identical either way. Math-first means the calculation never leaves code, so the part that has to be right cannot drift.
Ask these of any tool, including mine.
If the number came out of the model, it was predicted. If it came out of code, it was computed. Ask which, and expect the answer to be specific. A tool that cannot tell you where its math runs is telling you something.
Run one deal through, then run the identical file again. If the figures move, you do not have an underwriting tool, you have a drafting assistant. Determinism is not a nice property here. It is the requirement.
A lender does not want your verdict, they want the chain that produced it: which figure was adjusted, to what, and why. If the reasoning cannot leave the tool in a form you can hand to someone, it was never defensible.
The first version did what everyone does. It handed the documents to a model and asked for the analysis. It was fast, it read well, and on the deals where I already knew the answer I could see it drifting. Not wildly, just enough that I would not have staked my own money on it, which made it worthless for the only job that mattered.
So I tore out the calculation layer and rebuilt it. Now the model does the one thing it is genuinely better at than code, which is reading a badly scanned rent roll and working out that the column labelled "occ." means occupancy. Then it stops. Every figure after that point is computed, and the figures do not move between runs.
The second build is slower to develop and far less impressive to demo. It is the only one I would put my name on.
Underwriting is not pure arithmetic. Someone has to decide whether a seller's management fee of zero is credible, whether stated occupancy is supported, whether a tax bill is about to be reassessed. Those are judgment calls and a model can make them well. What it cannot do is make them silently.
RVP Underwriter is the engine as a self-serve product, free to start. Drop in the documents you already have and put it through all three tests. Run the same file twice. Look for where the arithmetic happens. Try to export the reasoning.
This is what gets installed when I install your standard, running your thresholds instead of the defaults. More about who builds it.
Sugarpine