Walkthrough
One loan file,
from delivery to a signed-off report.
What a reviewer actually does, in the order they do it. Four findings, deliberately chosen: a real exception, a legitimate difference that must not become a defect, an extraction error the system catches on itself, and a formatting failure that belongs to someone else.
What you are looking at. These are reconstructions of the working application, not screenshots, and the loan is synthetic. The states, rule families, severities and flow are the ones the product uses. The rule logic behind them is not published. If you want the real screens, that is what a working session is for, and it takes an hour.
The file arrives whole, not page by page
A loan package is delivered into a processing session. One PDF or many, in whatever order the file was assembled. Nothing is built on your side for this: delivery is how an evaluation starts, and connectors are on the roadmap rather than in place.
The package is split into documents, and each is named
Segmentation identifies where one document ends and the next begins, then classifies each against the supported form set. Pages that cannot be classified are surfaced rather than silently dropped, because an unread page is exactly where a missed defect hides.
Values are read, with confidence kept alongside them
Fields are extracted with a confidence score retained per value. Low-confidence reads are marked for correction before anything downstream runs. This is the layer a general-purpose model does well, and it is the layer where the errors that matter get introduced.
A person fixes what the system is unsure about
Reviewers inspect and correct uncertain values first. Judgement stays where the system is least confident, and it stays before the rules run rather than after, so a misread does not propagate into a finding that then has to be argued about.
Documents become one loan record, with conflicts visible
Borrower, property, income, asset and liability data are consolidated into a single structured record. Where two documents disagree, the conflict is carried forward as a conflict rather than resolved silently by whichever document was read last. Derived values show the formula that produced them.
Rules run, and four outcomes are recorded, not two
Rule sets are selected by loan programme. Every rule returns one of four states, and the distinction between the last three is the point:
Data required means the rule could not be evaluated because a field it needs is empty. Not applicable means the rule did not apply to this loan. Neither is a pass. A system that reports only pass and fail turns both of these into silence, and silence reads as clean.
Four results, and why each is a different kind of thing
The list below is what a reviewer opens. Note that only one of these is a defect.
A named person decides, and that is recorded
The reviewer accepts, corrects or escalates each finding, and the loan-level disposition is captured with the deciding reviewer against it. E3 produces findings; a person decides. That is a design position rather than a gap, and it is not on a roadmap to be removed.
Queues, assignment and escalation are still being built. Today a reviewer works the list; the workflow around it is coming.
The record that has to survive being questioned
A quality control report is produced with export. Each finding carries the rule that produced it, its version, and the source document each value came from. Rules that did not run are in the report as rules that did not run.
Values used $8,940/mo derived from paystub 03/2026 · $8,875/mo derived from W-2 2025 · $9,200/mo stated on URLA 1003 · $9,200/mo used to qualify on 1008.
Source documents each value traced to the document it was read from.
Threshold 5%. Observed spread 3.7%.
Disposition Accepted by reviewer, 2026-09-08. Basis: underwriter used the stated figure with a written calculation on file. Reviewer recorded against the loan.
That last block is the part an examiner asks for eighteen months later. It is a by-product of doing the review, not a document assembled afterwards to satisfy them.
What this does not show
The limits of a walkthrough
A curated example proves a system can do a thing. It does not establish how often it does it correctly, and we would rather say so than let a tidy example imply an accuracy claim.
We do not publish an extraction accuracy percentage, because we have not measured one against a stated document set we could defend. What we can do is run your own de-identified files and let you check the findings against outcomes you already know. On three to five files that establishes whether it is worth going further. It does not establish portfolio accuracy, and nobody should tell you otherwise.
See this on a real file.
An hour, on a synthetic file or de-identified files of your own. You see the actual screens, not reconstructions.