A staging area for thirty years of court records
A government agency runs court processes around property: land disputes, assignments, what happens to a parcel when the owner dies. The system of record is an Oracle database that has been accumulating cases for over 30 years. The paper originals sit in an underground archive chosen because the humidity stays low. The ETL around the database is old enough and manual enough that a change can take 5 to 10 years to work its way through the process.
The agency is modernizing. The program is 17 projects; this is the first one. The team is the agency, an AI vendor doing document enrichment, Microsoft, and Infino. Everything runs inside the agency’s own Azure environment, not ours.
Staging area, not system of record
The target system of record is Microsoft Dataverse. The question was what sits between the old Oracle database and the new one, because the documents cannot move over as-is. They need to be enriched first: fields extracted, cases classified, records linked, and every enrichment checked by a person before it counts, because these are court records and a wrong field changes a case.
The original design used Fivetran for that middle hop. Infino replaced it, which sounds odd until you look at what the middle hop has to do. A pipeline moves data; it cannot answer questions about data that is halfway through. Enrichment is a retrieval workload: the vendor’s models and the human reviewers both need to look up prior cases and find every other document that mentions the same parcel or person, often against records whose enrichment is half done. So the staging area is a search index. Documents land in Infino, get enriched and verified there, and the confirmed records flow on to Dataverse.
Infino is deliberately not the source of truth here. Oracle is, until Dataverse is. The index is the workbench between the two, and the enrichment step needs a workbench it can query in the middle of a migration.
"Who are the relatives?"
The second use case comes from the records themselves. Property cases encode family relationships inside nested documents, the way title documents do: an owner, heirs, spouses, relationships implied by context rather than declared in a column. Case workers need to ask "who are the relatives of this person?" and get an answer across the whole corpus.
That is not an exact-match query. Names vary across decades of filings, and the relationship is often in the surrounding text, so the plan leans on semantic search over the nested documents, with the family graph inferred from what retrieval surfaces. It is the same shape of problem as the canonical people index: get the candidate set right first and keep one person from splitting into two, with a case worker confirming each link.