Mortgage Intelligence Platform
The intelligence layer underneath every application.
The platform turns mortgage documents and data into a source-linked mortgage representation, connects that representation to governed policy and deterministic tools, and supports reasoning across the lifecycle.
Architecture
Applications on one intelligence layer, on one mortgage context, on source evidence.
Read from the top: five applications consume one intelligence layer. The layer is six pillars. The pillars work on a canonical, source-linked representation of the mortgage, and every fact in that representation traces to source evidence. Only QC is available for evaluation; the other applications carry their status on the diagram and on their pages.
The principle
Use models for judgment where judgment belongs. Use deterministic systems where truth can be computed.
It would be simpler to say the model reads and the rules decide. That is accurate for quality control today, and too narrow for what the platform is built to do. The division that survives the next several product generations is by kind of work, not by component.
The product does not persist or expose hidden model reasoning. It exposes a structured decision trace: evidence, policy, calculation, tool outputs, assumptions, missing data and disposition.
Six pillars
What the layer is made of
Data
A normalized, source-linked representation of mortgage facts and lifecycle context.
Knowledge
Effective-dated policy, program requirements, rules, exceptions and overlays.
Reasoning
Domain intelligence connecting facts across documents, policy and lifecycle context.
Tools
Deterministic calculations, validation engines and workflow operations where correctness should not depend on generated prose.
Evidence
Traceability from material conclusions back to source data, documents, rules, calculations and reviewer actions.
Evaluation
Mortgage-specific testing of correctness, applicability, evidence and professional work products.
Perception and data
Reading is a capability anyone can buy. The representation is not.
A vision-language model classifies the documents, locates fields and handles the variation of real-world files. That runs on managed infrastructure rather than a model of our own, because document reading improves across the whole industry every quarter and is not where a mortgage platform should spend its differentiation.
What the platform builds from that reading is the part that cannot be bought: a canonical mortgage record in which borrower, property, income, asset and liability facts from many documents become one structured representation, with the source of every value kept, the conflicts between sources carried forward rather than resolved silently, and derived values shown with the formula that produced them.
The honest present: today a general-purpose vision-language model from an established provider reads the documents, and a versioned, deterministic rule engine produces the findings, with a person resolving the exception. Customer documents are not training data. How data is handled.
Knowledge
Effective-dated policy, encoded and versioned
Not a checklist held in someone's head. Each control is a stored rule, bound to a loan program, with a semantic version, the person who published it and a lifecycle status. A finding is bound to the version that produced it.
Mortgage policy changes. Selling guides are updated, program requirements shift, compliance interpretations move. A review performed in March was performed under March's rules, and by September those rules may read differently. If a system cannot say which version produced a finding, every historical review silently re-anchors to today's rule set.
The knowledge layer encodes the GSE selling guides, FHA, VA and USDA program requirements, and the federal compliance frameworks including TRID, ATR/QM, HOEPA, HMDA, RESPA and Regulation B, as rules selected by loan program. The control set as it applies to quality control.
Reasoning
The part above reading, and what it has to get better at
Recognizing an income figure is the reading layer. Explaining why qualifying income differs between two programs is the domain layer. This is the specific list of what mortgage reasoning has to do, and each row marked work in progress is exactly that.
Today is the first row plus a versioned rule engine and a human reviewer. We will publish evaluations on representative, unseen mortgage cases as they exist: expert-reviewed accuracy, exception handling and the usefulness of the explanation.
Tools and rules
Deterministic where truth can be computed
Calculations run as code, with the formula and inputs shown. Hard requirements run as rules that contain no model, so the rule applied, its logic and its version do not vary between runs.
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 debt-to-income calculation is entirely deterministic, and entirely wrong. The rule did not change. The conclusion did.
What is genuinely fixed is narrower: given the same inputs and the same rule version, the same result follows. 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 the system produces validation findings while a reviewer reaches the disposition.
Evidence and human workflow
Anyone can produce a finding. The question is whether it survives being questioned.
Six months after a file is cleared, someone asks why. A finding that cannot answer that question is an opinion with a timestamp.
Every value carries the source document it was read from, and every finding the numbered rule version. Which rules ran, which were skipped and against which loan program is recorded per run, so a disputed answer is traceable to a specific value on a specific page. The reviewer's disposition is captured with the deciding reviewer recorded. That is a design position, not a gap, and it is not on a roadmap to be removed.
Unresolved judgment and exceptions are escalated to a named person rather than silently invented. Queues, assignment, escalation and service levels around that reviewer are on the roadmap, and the QC page says where they stand.
Evaluation
Every release measured on mortgage work
Domain-specific tests of correctness, applicability, evidence and professional work products, on representative mortgage cases. Generic AI benchmarks are not the measure.
Results are published with the method, the document set and a comparison anyone can reproduce, or they are not published. The evaluation harness itself stays internal. Our research approach.
Modular by design
API-first, which makes the pieces separable
Relevant if you want part of this rather than all of it, or want to put it behind your own front door.
The application layer consumes the same core services used by the platform itself. Extraction and synthesis, the versioned rule engine, and the evidence and lineage layer are distinct services rather than one indivisible product. That separation is designed to support integration and modular deployment over time.
Availability of individual services is scoped per engagement and should not be inferred from the architecture alone. 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. Neither is a shelf product today, and we would scope either as an engagement rather than a purchase.
We will take a finding apart.
A working session against your form mix and rule set, on a synthetic file or de-identified files of your own.