Data Intelligence & Validation
A title file is built on dense legal documents — mortgages, judgments, commitments. This domain is the machinery that turns that unstructured text into structured business data the whole organization can act on: read from the source, reconciled against the systems of record, and approved by a person before it is trusted. It isn't one screen or one feature — it is a single transformation pipeline that runs from a raw document to a value someone can stake a transaction on.
Why this capability exists
Before a file could move forward, someone opened the underlying legal documents, read the values that mattered, gathered the same figures from separate systems of record, and checked them against each other by hand. The trust was real — but it was manual, repetitive, and fragile in a process where a single wrong value is expensive.
This domain industrialises that trust without removing the judgment. The system reads, compares and flags; a person still decides and approves. What changed is that the whole journey now happens in one place, on the file, instead of across a reader's memory and several other tools.
Information Transformation Flow
The domain is best understood not as a set of screens but as a single transformation. A raw legal document enters at one end; a trusted, structured business record comes out the other. Every product decision in this domain exists to serve one of these stages — extraction, validation, and sync are steps, not the story.
Document
A mortgage, judgment or commitment, previewed on the file.
Extract
The value is read from the document — OCR and selection, not re-typing.
Validate
Checked against the systems of record; differences are flagged.
Enrich
Mapped to a data point, category and requirement so it means something.
Sync
Kept in step with its sources instead of drifting after one import.
Trusted data
A person approves; the value becomes the file's record of truth.
The Business Problem
Reading a file was never the slow part — verifying it was. Values had to be lifted out of legal documents and reconciled against other systems before anyone could rely on them, and that cross-checking was done by people, one value at a time. It capped throughput, invited transcription errors, and made accuracy depend on individual diligence rather than on the product. The domain had to move that verification into the system.
Users & Responsibilities
Reader · validates
Reads the file's values against the source, resolves what doesn't reconcile, and records the decision. Goal: verify quickly and confidently.
Manager · approves
Owns the final sign-off. Goal: approve knowing every exception was surfaced and handled.
The whole design rests on one boundary: the system does what machines are good at, and a person does what only a person can be accountable for. Drawing that line explicitly is what makes the automation trustworthy rather than threatening.
| The system does | The person owns |
|---|---|
| Reads values from the source document | Decides what the value should be |
| Compares against the systems of record | Approves the result |
| Detects and flags differences and gaps | Resolves the exceptions |
| Surfaces each value with its source and state | Takes responsibility for the record |
Product Decisions
Automate the comparison — never the approval.
WhyIn an accuracy-critical process, removing the human trades a slow, visible risk for a silent one.
RejectedFull end-to-end automation — a single wrong value is expensive, and no one would be accountable for it.
Surface every value with its source and its state.
WhyA reviewer has to be able to verify a number against its evidence — not take the system on faith.
RejectedShow only the final value — the reviewer could trust it but never check it.
A checklist is the spine of validation.
WhyEvery validation step needs an explicit, legible state — done, pending, blocked — on the file.
RejectedA single ‘validated’ flag — it hid which steps were done, pending or still blocked.
Keep the data in sync — don't import it once.
WhyA one-time import drifts from the systems of record the moment they change.
RejectedA one-off import — the file's data would silently fall out of date.
Design Evolution
The structure moved from data and document living apart toward a single surface where a value is verified against its source without leaving the file. Schematic here — the reasoning, not pixels.
Final Product Experience
Not a gallery — the two screens that carry the transformation. One reads a value out of a legal document into a structured field; the other holds the explicit state of every value being validated. Together they are the pipeline made real.
Save to Select — from the source document into a field
ProblemA value on the file had to be re-read from a document in a separate viewer and re-typed elsewhere — the classic place errors enter.
In the screenThe document viewer (with OCR and annotation) sits beside a field-selection panel: highlight a value in the source, map it to a data point and category, and save it into the file's structured data.
Every requirement, with an explicit state
ProblemThe state of validation — what was checked, what was pending, what was blocked — lived across tools and in people's memory.
In the screenWorkflow status and a live checklist give each requirement a first-class state (Done, In progress, Required, On hold), with notes and hand-offs kept on the file.
Operational Impact
Data Intelligence turned cross-checking into review — making operational data trustworthy without removing the judgment that has to stand behind it. It is the domain that demonstrates data-intensive system design, and it is what lets the workspace and the management layers act on data they can rely on.