Estate Case Management at a US Government Agency

The Problem

A federal records program adjudicates the estates of deceased beneficiaries — reconstructing family trees, validating successor claims, tracking parcel interests, and reconciling death notifications against an active persons database. The work is high-stakes, evidentiary, and reviewed. Every decision has to be defensible from the source record, every search has to be auditable, and every automated step has to leave a human in the loop where it matters.

The data is messy in the way real government data is messy. Case records arrive as XLSX exports with sections for Summary, Decedent Identity, Birth and Death Info, Marriage, Divorce, Children, Parents, Siblings, Grandparents, Collateral Relatives, Wills, Beneficiaries, Real Property, Personal Property, Adoption, and Claims. Names vary across documents. Community affiliations are inconsistently spelled. Obituaries and death notices live on the public web. Parcels carry fractional interests that thread back through generations of relationships.

Staff need four workflows running over the same backing data: family-tree reconstruction with conflict detection, death-notice discovery and matching, fuzzy people search across cases, and parcel lookup with ownership chains. Before Infino, each workflow was a separate tool with a separate data model and a separate audit trail.

The Architecture That Worked

Six datasets on one engine. Three standard, three semantic. The.semdatasets auto-embed designated text fields on ingest — agents query them with semantic search alongside structured filters in a single request, with no separate embedding service, vector store, or auth context.

Dataset                  Type       Content                                        Records
estate-cases             standard   One doc per case (summary, status, region)    ~10,000
persons.sem              semantic   One doc per person + relationship_summary     ~50,000+
family-relationships     standard   One doc per edge (parent, child, spouse, ...) ~80,000+
death-records.sem        semantic   One doc per decedent + notification text      ~10,000
parcels                  standard   One doc per parcel with ownership             ~15,000+
case-documents.sem       semantic   Wills, death certs, adoption decrees          ~20,000+

Ingestion runs through the same engine as query. XLSX uploads land in Data Sources via QuickImport, bulk NDJSON arrives through the_bulkAPI, and the semantic datasets generate embeddings transparently during write. There is no second system to keep in sync, no CSV handoff, and no separate credentials for an embedding provider.

Four Workflows, One Backend

1 · Family Tree Reconstruction

A staff member opens a case and the search agent issues a query that joinsfamily-relationshipsagainstpersons.semandcase-documents.semin a single request. The questions the agent answers look like:

"Show me the family tree for the decedent in case TC-001."
"Who are the surviving successors of the decedent in TC-014?"
"Find cases where siblings are listed as both living and
 deceased across different records."
"Which cases are missing a surviving spouse but have a
 marriage record with no divorce?"

The analysis agent takes the next step: build the complete kinship map for a case, run Python over the result to detect contradictions across source documents, and emit a markdown report with the supporting evidence inline. Cross-case comparisons — "compare successor structures across all cases in a given region" — are the same shape of query against the same datasets. Semantic search onpersons.semsurfaces probable relatives based on therelationship_summarytext, not just exact name matches.

2 · Death Notification Discovery

Deaths get discovered earlier when public sources are watched and matched against the persons database. The analysis agent orchestrates the multi-step workflow as one plan: web search for obituaries that may correspond to people on file, semantic match againstpersons.sem, confidence scoring in Python, ranked output back to the reviewer.

"Search the web for recent obituaries in the regions we
 cover, then match the results against our persons
 database."

The same pipeline runs as a scheduled transform — "every day, find death records from the last 7 days and match them against the persons database by name similarity" — that materializes results into adeath-matchestarget dataset. A monitor sits next to it: "alert me weekly if there are more than 5 new death records without attached death certificates." Transforms and monitors are stored queries — reviewed once, executed on a schedule, and recorded in the same audit log as every interactive query.

Forecasting and trend analysis run in the same surface. "Analyze death notification trends by region and cause of death over the past 20 years and forecast expected notifications for next year" is a single analysis session that combines SQL aggregation, a forecast cell, and a chart.

3 · People Search Across Cases

People search is the workflow that most exposed the limits of the previous tooling. Names vary, enrollment numbers occasionally collide, and the same individual appears in multiple cases as decedent, successor, or witness. The search agent covers the manual path:

"Find all people with surname 'Bear' in our records."
"Search for anyone with enrollment number ENR-261074."
"Find people born between 1960 and 1980 who appear in
 more than one case."
"Find potential duplicate people — same date of birth with
 similar names across different cases."

The analysis agent covers the automated path. For a given case, it pulls the decedent record, runs semantic search overpersons.semfor likely relatives, scores candidates in Python on name similarity, community affiliation, and shared case history, and returns a ranked list with justifications attached to each match. Web enrichment is a one-line addition to the same session — pull supplementary public records and merge them into the candidate record before the reviewer sees it.

4 · Parcel Search

Parcels in this dataset carry fractional ownership, status classifications, and jurisdictional context that thread through generations of family relationships. The queries reflect that:

"Show all parcels in jurisdiction R-14."
"Find all parcels associated with the decedent in TC-008."
"List parcels where a single owner holds more than 50%."
"Find cases with more than 3 restricted-status parcels."

The deeper question — "for case TC-002, find all parcels, identify all current and historical owners from our persons database, and map the ownership chain through family relationships" — runs as a single analysis plan that joinsparcels,persons.sem, andfamily-relationships, then runs Python to assemble the chain into a defensible report. A scheduled transform reruns the cross-reference weekly for any new trust-land cases.

Humans in the Loop, Agents in the Engine

The agents do retrieval, matching, scoring, and report assembly. Decisions stay with people. Every consequential step — confirming a match, accepting a family-tree reconstruction, attaching a parcel to a case — is a reviewable action recorded against the case file. The audit log captures the requesting user, the requesting agent, the datasets accessed, the rows returned, the decision made, and the timestamp. The log is itself a queryable dataset. "What did the matching agent access on Tuesday for case TC-005, and which suggestions did the reviewer accept?" is a SQL question, not a ticket to the platform team.

Behavioral feedback flows back into ranking. When reviewers consistently accept or reject certain match shapes, the scoring is iterated against captured decisions instead of against an offline benchmark.

Smart Dashboards and Discover

Each workflow has a generated dashboard. Selectingestate-cases,family-relationships, andpersons.semin the Smart Dashboard generator produces a Family Tree Overview without hand-built panels. Any agent result can be pinned to a dashboard with a click. The Discover panel is the faceted-search counterpart — filter by region, time range, relationship type, parcel jurisdiction — for the moments when a structured filter is faster than a sentence.

What Changed

Before: four workflows, four data stores, four audit surfaces, and a brittle ETL fabric stitching them together. Family-tree reconstruction lived in one tool, parcel ownership in another, death-notification monitoring in a third, and people search spread across spreadsheets. Cross-workflow questions — the ones that matter most — required a person to hold the joins in their head.

After: one backend. Six datasets behind one engine that executes against semantic and structured data in a single request and records every action against the case. Agents handle the retrieval and assembly work. Reviewers spend their time on the decisions only humans should make. The audit log is queryable, the scheduled transforms run as stored queries, and the next workflow added to the program is a role declaration and a dataset — not a six-month integration project.

Questions? Get in touch.