Why the qualifying income is code, and never a model’s answer
One model reads the documents. Code computes the income. Where that line sits, and why every figure can be checked in the time it takes to read it.
A qualifying income is a number a lender will be asked to stand behind. An underwriter can ask where it came from, and so can an investor, a quality control review or an auditor a year later. So the figure cannot be a guess, however good the guess.
Proxara splits the work in two. One model reads the documents. Code computes the income. The line between the two is the most important decision in the product, and this is why it sits where it does.
What the model does
The model reads each page into facts: the regular pay on a paystub, the pay frequency, the year-to-date total, the wages on a W-2. Each fact keeps the printed words it came from and their place on the page. Before a fact is used, code checks the quote against the page’s own text. A value that cannot be found where the model says it was printed is not used; the page asks about it instead, with the crop beside the question.
That is the whole of the model’s job. It never decides which figure counts, which rule applies or how much a borrower qualifies for.
What code does
The income engine is deterministic. For each income type it applies the agency rule for that type and that product: base pay from paystubs and W-2s, with the year-to-date and prior-year tests; overtime, bonus and commission, with the history, averaging and trend the guides require; self-employment from personal and business returns, with the add-backs the guides list; non-taxable income, grossed up at the rate the product allows.
The same facts under the same rule version give the same answer, every time. A rule change never rewrites an old result; it produces a new one, and the old one stays as it was.
Every figure is a tree
A qualifying income is not one number. It is a tree: the sources, the amounts by period, the averaging and the trend, any gross-up or add-back, and the monthly figure at the top. Every node carries its inputs, its arithmetic, the rule it ran under and the page its inputs came from.
On an example loan, Loan 2031, the tree is short: base pay of 6,000.00, paid semi-monthly, twenty-four pay periods in a year, spread over twelve months. The paystub’s first page supplies the figure and the W-2 agrees with it. A commission earner’s tree is longer, with two years of history, the trend between them and the treatment the trend calls for, and it is read the same way.
Why the model does not compute it
A model that computes will usually be right. Usually is the problem. A reviewer who finds one wrong figure has to check every figure, and then nobody has saved any time. A figure that carries its arithmetic, its rule and its page can be checked in the time it takes to read it, and it is the same figure tomorrow.
It also means the product is tested the way a lender would test a person: against expected values worked out by hand from the guide before the engine runs. The engine is corrected to those values, never the other way round.
Where a person comes in
Where a document is unclear, the product asks one question and shows the crop. The answer is recorded with who gave it and when, and the original reading stays in the history. Where two documents disagree, both stay on the result: the disagreement is often the reason the file would have failed.
The model reads. Code decides. The AUS judges. The income is the first place that sentence has to hold, and everything after it rests on it.
