The model proposes.
The rules dispose.

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.

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 document it came from, and why E3 produces validation findings while a reviewer reaches the disposition.

E3 is built API-first. The application you would use is a client of the same interface everything else runs on, rather than a monolith with an interface bolted to the side. That is an architectural statement, not an integration offer: customer-facing origination connectors and batch ingestion are on the roadmap, and capabilities says where they sit.

What it does mean commercially is that the pieces are separable. Extraction and synthesis, the versioned rule engine, and the evidence and lineage layer are distinct services rather than one indivisible product. So modules can be contracted or licensed individually rather than taken as a whole platform. A firm that already has a reviewer workflow and wants the rule engine and evidence record behind it is a conversation we can have; so is a partner wanting to deliver quality control to their own clients under their own brand.

Neither of those is a shelf product today. Multi-client administration, client-specific rule sets and co-branded delivery are further out than the core platform, and we would scope any of it as an engagement rather than a purchase. If that is the shape of what you need, say so early: it changes the conversation more than it changes the technology.