E3

Platform

The model proposes.
The rules dispose.

E3 does not ask a language model to decide whether a loan file is sound. Reading is a perception task. Deciding is not.

01

Intake

Loan file received and queued.

02

Classification

Documents identified and segmented.

03

Extraction

Values located, kept with page and source.

04

Synthesis

Reconciled across the file; conflicts recorded.

05

Validation

Versioned rules run. Skips recorded too.

06

Review

Exception opened, routed to a named person.

07

Evidence

Finding kept with the rule version that made it.


The division

Reading is a perception task. Deciding is not.

A vision-language model reads the documents — classifying them, locating fields, handling the variation of real-world files. E3 runs this on managed infrastructure rather than a model of its own, because document reading improves across the whole industry every quarter and is not where a mortgage platform should spend its differentiation.

That is a statement about reading, not about mortgage intelligence, and the two are often conflated. Buying the reading layer is the right call precisely because the difficult part sits above it: knowing which qualifying-income method a programme requires, when a difference between two documents is legitimate rather than a defect, which document should be present and is not, and how to state an unresolved exception so a reviewer can act. None of that is perception. It is domain reasoning, it is where the domain model we are building is aimed, and it is not something a general provider improves for us each quarter.

Every finding is then produced by a deterministic rule engine enforcing published policy: the GSE selling guides, FHA, VA and USDA programme requirements, and the federal compliance frameworks including TRID, ATR/QM, HOEPA, HMDA, RESPA and Regulation B.


Governance

When your investor asks how you knew the AI got it right

Fannie Mae's LL-2026-04 took effect on 6 August 2026. Freddie Mac's Bulletin 2025-16 has been live since 3 March 2026. Both require a documented AI/ML governance programme — and both extend that obligation to your vendors.

What is the AI doing, and why

Each stage is named and bounded. A model reads; it does not decide. The disposition comes from a stored rule, so the purpose of the AI is answerable in one sentence rather than described.

What safeguards are in place

The rule layer contains no model, so the rule applied and its version are fixed. That is a real safeguard and a bounded one — it does not make extraction error harmless.

How do you know it got it right

Every value carries the document, page and position it was read from, and every finding the numbered rule version. Given the same inputs and version, the same result follows — so a disputed answer is traceable to a specific value on a specific page.

Can you evidence it for a vendor

The obligation now extends to vendor and subcontractor AI, held to the same standard. E3 produces the artefact rather than a description of one — the record exists as a by-product of the review, not as a document written afterwards.

FIGURE Anatomy of a finding Four sources, four periods, one comparison — and why the difference needs a person. RULE INC-014 v2.3.0 · QUALIFYING INCOME MUST RECONCILE WITHIN 5% ACROSS SOURCESSOURCEAS STATEDMONTHLYHOW DERIVEDPaystub 03/2026p.1 · YTD box$26,820 YTD over 3.0 months$8,940 / moYTD ÷ months elapsedW-2 2025p.1 · box 1$106,500 for 12 months$8,875 / moannual ÷ 12URLA 1003p.2 · 1c$9,200 stated monthly$9,200 / moas stated by borrower1008 Summaryp.1 · field 21$9,200 used to qualify$9,200 / mounderwriter’s figureSpread between lowest and highest monthly figure: 3.7% — inside the 5% threshold.Not a defect. Flagged for review because the 1008 uses the stated figure, not the derived one.The reviewer decides: accept the underwriter’s basis, or request a written income calculation. E3 records which,by whom, and when. The finding is an exception to investigate — the disposition belongs to the reviewer. Illustrative, from a synthetic file. Threshold and rule identifier are examples.
A numeric check that passes, an evidence question that still needs a person, and everything kept with both.

The limit of that claim

A wrong reading produces a wrong finding

It would be convenient to say that because the rules are deterministic, model error cannot affect the outcome. That is not true, and an experienced reviewer will see through it immediately.

If extraction reads monthly income as $12,000 when the paystub says $7,000, the DTI calculation is entirely deterministic — and entirely wrong. The rule did not change. The conclusion did. Extraction error is not harmless; it is the main way a system like this fails.

What is genuinely fixed is narrower: the rule applied, its logic and its version do not vary between runs. Given the same inputs and the same rule version, the same result follows. Reproducing a result therefore means preserving the inputs, the version and the configuration — re-running extraction on a document may not reproduce the inputs.

So the design goal is not infallibility. It is that a misread is visible and correctable before it becomes a decision — which is why every value is shown with the page it came from, and why E3 produces validation findings while a reviewer reaches the disposition.

A general-purpose model that cannot name the rule version it applied cannot answer the third question at all. That is the difference between a system that is defensible and one that merely performs well.

E3 produces evidence; the lender holds the obligation. Nothing here implies approval, certification or endorsement by Fannie Mae or Freddie Mac.

Bring a file. We will take a finding apart.

A working session on your own documents, against your own form mix and rule set.