An investigator opening a case does not want a database. They want to know, by the end of the afternoon, whether this company is connected to that one, who controls it, whether anything about it has changed recently, and whether there is enough here to escalate. A search box over excellent data does not do that. It returns results, and the investigator then does the actual work by hand: opening tabs, copying names into a document, drawing a diagram on paper, and reconstructing at the end what they saw and when. Every data company selling into investigations, compliance and government analysis is competing on how much of that manual work the product removes, and the ones that win are not the ones with the largest catalogue.
This is written for the person building that product: the head of a government, investigations or compliance practice at a data company. What follows is what the workflow actually looks like when it is designed properly, the engineering underneath it, and the specific things that make the output defensible when a reviewer, a supervisor or a court asks how a conclusion was reached.
The shape of the work
Investigations differ by domain but the process is remarkably consistent. Understanding the shape is what separates a product built for investigators from a search interface with a nice theme.
A case starts from a trigger. An alert, a referral, a tip, a transaction that broke a rule, an application flagged in screening, or a name on a list. The trigger carries context that must survive into the case, because the first question anyone asks later is why this case was opened.
The investigator establishes identity. Which entity is this, actually. This is where most of the time goes and where most products help least. The subject arrives as a name and maybe an address, and turning that into a resolved entity with a registry identifier is the gate on everything after it.
They expand outward. Owners, officers, subsidiaries, affiliates, addresses, prior names, related parties, counterparties. This is graph traversal, and doing it by hand across several sources is the single largest consumer of an investigator's day.
They look for the signal. A sanctioned party two hops away. A shared address with a known shell. An officer who appears on three unrelated entities formed the same month. Adverse media on a parent. A change in ownership shortly before an application.
They capture evidence. What they saw, from which source, on what date, in a form that will still mean the same thing in two years.
They write a conclusion and dispose of the case. Escalate, close, monitor, refer. With a reason, recorded.
Something watches afterward. Cases closed today generate the alerts of next quarter when the underlying facts change.
Where an investigator's time goes when the workflow is not designed for it
Editorial weighting, illustrative rather than measured. The last row is deliberately low: the analysis is the job, and it is what the surrounding work crowds out.
The entity graph is the product
Everything above rests on one structure: a graph where nodes are entities and people and addresses and identifiers, and edges are relationships with types, dates and sources. Build that well and the rest of the product becomes assembly. Build it poorly and no amount of interface work rescues it.
Four design decisions determine whether the graph holds up.
Edges are typed and dated, never generic. A relationship between two entities is not a link. It is a specific claim: this person was a director of this company between these dates, according to this filing. A graph of untyped associations produces impressive pictures and unusable answers, because an investigator cannot tell a current owner from a former neighbour.
Every edge carries a source and an as-of date. Ownership changes. An edge without a date is a claim about no particular moment, and the question in an investigation is almost always what was true when something happened.
Assertions are separated from conclusions. Source records assert things. The graph you show is computed over those assertions with rules you can name. Storing only the computed answer means you cannot explain it, and cannot recompute it when a source is corrected.
Traversal has semantics, not just depth. "Two hops from a sanctioned entity" is meaningless unless you say which edge types count. Sharing a registered-agent address with a sanctioned party is not the same as being owned by one, and a product that treats them alike buries every real finding under noise. Path types should be first-class: ownership paths, control paths, shared-officer paths, shared-address paths, each searchable independently and each with its own weight in scoring.
The last point is where most link-analysis products fail in practice. They can show a path. They cannot tell an investigator whether the path means anything.
Two structural questions decide the cost of that graph before a line of interface code is written. The first is storage. A dedicated graph database gives natural traversal and pays for it in operational complexity and in weaker analytical querying; a relational or columnar store with well-designed adjacency tables and recursive queries handles bounded traversal well and struggles past a certain depth. The workable answer for most investigations products is a hybrid: the assertion store and computed entity tables in the analytical store, with an in-memory or purpose-shaped index serving interactive traversal, rebuilt from the store on a schedule so it is never the source of truth. That way a corrupted index is a rebuild rather than an incident.
The second is fan-out. Real corporate graphs are not evenly connected. A handful of nodes, typically registered-agent addresses, large holding entities and common officer names, have degrees in the tens or hundreds of thousands, and a naive two-hop expansion through one of them returns a result set nobody can use and a query nobody can afford. Handle it deliberately: cap expansion per node, rank neighbours by edge weight before expanding, treat high-degree nodes as barriers that require an explicit choice to cross, and surface the fact that a path passes through one so the investigator can judge it. This is not an optimization detail. It is the difference between a graph feature that works on real data and one that only works in a demonstration.
What makes a case file hold up when someone reviews it later
Editorial weighting, illustrative rather than measured. The last row is deliberately low: a reviewer is checking whether the record is sound, not whether it is attractive.
Alerting that people do not turn off
Screening and monitoring are where the product earns its subscription, and also where it most easily destroys its own credibility. An alerting system that produces mostly noise trains its users to dismiss everything, and once that habit forms the product's real hits are dismissed too.
Several design choices separate an alerting system people trust from one they route to a folder.
Alert on change, not on state. Re-screening a population and firing on everything currently matching produces the same alerts forever. Fire when something changed: a new match, a new relationship, a status change, an ownership change, a new adverse-media item above a relevance bar. This requires storing what was known at the last evaluation, which is another reason the fact store matters.
Deduplicate at the subject level. Five sources reporting one event should produce one alert with five sources attached, not five alerts. This is dull engineering and it is the difference between a usable queue and an unusable one.
Carry the disposition forward. When an investigator clears an alert as a false match, that decision must suppress the same alert on the same subject from the same cause until something material changes. An alert that returns after being cleared is the fastest way to lose a user, and it is a common defect because suppression is harder than firing.
Explain the alert in the alert. Which rule, which values, which sources, which threshold, and what changed since last time. An investigator who has to reconstruct why the system fired has been given work rather than help.
Let the customer tune, and record the tuning. Different institutions have different risk appetites, and a fixed sensitivity satisfies no one. Expose thresholds and rules as configuration, versioned, with a record of who changed what and when, because their auditors will ask and their answer will be your screen.
Evidence capture is the feature that decides renewals
Here is the distinction that matters most and gets the least attention in product planning. A tool that helps an investigator find something is useful. A tool whose output survives review is indispensable, because the investigator's work product is not the finding, it is the defensible record of the finding.
What that requires in the system, specifically.
- Snapshots, not links. When an investigator adds something to a case, store what it said at that moment. A live reference that renders today's value makes a two-year-old case file mean something different than it did when it was written.
- Provenance on every captured item. Source, source publication date, ingestion date, and the retrieval time. All four, because they answer different questions.
- Immutable notes with attribution. Once saved, a note is appended to rather than edited. An editable record is not evidence, and the correction history is often the interesting part.
- A complete access log. Who opened this case, who viewed the subject, who ran which query, when. This protects the institution and, more practically, is required in most environments where this work happens.
- Reproducible graph state. The ability to render the relationship graph as the investigator saw it on the date of the conclusion, not as it stands now. This is the hardest item on the list and the most valuable, and it is only possible if edges are dated and assertions are retained.
- Export that stands alone. A case package a reviewer can read without access to your system, containing the findings, the evidence with its provenance, the graph as of the decision date, the notes, and the disposition with its reason.
- Retention that matches the customer's rules. Financial institutions and government users have record retention obligations, and deletion behaviour that is convenient commercially can be a compliance problem for them.
Products that skip this list get evaluated as research tools and priced accordingly. Products that implement it become the system of record for a function, which is a completely different commercial position.
Where machine learning helps, and where it must not decide
There is real value from models in this workflow, and a clear line where the value stops.
Models help with the volume problems. Ranking alerts by likely materiality so the queue is worked in a sensible order. Classifying adverse-media articles by allegation type and relevance so an investigator reads five items rather than four hundred. Extracting entities and relationships from unstructured documents such as filings, registrations and news. Scoring candidate matches in entity resolution. Suggesting which relationship paths in a large graph are worth examining. Summarizing a long document with citations back into the source text.
Models must not make the disposition. The system may rank, filter, suggest and summarize; a person decides and the decision is recorded as theirs. This is partly a compliance position and mostly a product one: an automated adverse decision that a customer cannot explain becomes their problem in a way that will end the relationship.
Three engineering requirements follow if models are in the product at all. Every model-derived value is labelled as such in the interface, never mixed in with sourced facts. Every model output records its version and inputs so it can be reproduced. And any generated text carries citations to the specific source passages, with the interface making it easy to check them, because an unattributed summary is something an investigator has to verify by hand, which returns the work you were removing.
Packaging this for government and large-enterprise buyers
The same capability sells into two markets with different requirements. Building for the stricter one and configuring down is cheaper than the reverse.
| Requirement | Large enterprise buyer | Government buyer | Design implication |
|---|---|---|---|
| Where it runs | Vendor cloud is usually acceptable | Often must run inside the agency's boundary | Build a deployable form from the start, not as a later port |
| Identity | Federated to the corporate identity provider | Federated, with government credentials and agency-controlled roles | One federated design serves both; vendor accounts serve neither |
| Audit | Required for regulated functions | Required, with retention set by the agency | User-action logging as a core service, not a feature |
| Accessibility | Increasingly required in procurement | Required and tested with assistive technology | Fix graph, table and chart components once, centrally |
| Data handling | Contractual terms on use and retention | Handling rules for sensitive but unclassified information | Configurable retention, marking and export controls |
| Explainability | Model governance expected for regulated use | Every conclusion must be defensible to a reviewer | Provenance and reproducible state are product features |
The pattern is that the government column is a superset. A product built to satisfy it satisfies the enterprise column without additional work, which is the argument for treating federal requirements as product requirements rather than as a separate edition.
How we work inside a data company on this
Precision Federal is an engineering firm. We build data platforms, AI systems, graph and search infrastructure, APIs and full-stack applications, and we deliver them into production, including inside federal agencies where the explainability, audit and accessibility bar is highest. An investigations product sits exactly at that intersection.
What the first weeks look like. We sit with actual investigators, watch the work, and time it: where the minutes go, which steps are manual, what gets copied into which document, and what makes a case take two days instead of two hours. Then we produce an architecture: the graph model with typed and dated edges, the assertion store underneath it, the traversal semantics with named path types, the alerting design with change detection and disposition suppression, the evidence and case model, and the deployment topology for both a vendor-hosted and an in-environment installation. Four to six weeks, ending in a document your product and engineering leaders can build from.
Then we build. Typically the graph and assertion store first, then traversal and path scoring, then the case and evidence model with snapshots and immutable notes, then alerting with change detection, then the interface, with accessibility handled in the component library rather than screen by screen. We work inside your repositories, your standards and your review gates, and we write the tests, deployment automation and runbooks alongside the code.
What you keep. All of it. The code is yours, assigned in writing, in your repositories from the first commit. Your data and your customers' data stay in your environment and never train anything of ours. Your customer relationships are yours; we work behind your brand unless being named as your engineering partner helps in a federal setting. Our existing tooling is named, carved out, and licensed to you perpetually inside what we deliver.
Pricing takes one of two shapes. Fixed-price milestones with measurable acceptance criteria, which suits a bounded piece like the graph service, the evidence model or an in-environment deployment package. Or a committed team at a monthly rate when the build is sustained and priorities move. We will tell you which fits before you ask.
The first step is one email with a one-page brief: what data you hold, who the investigators are, what a case looks like today, whether you need an in-environment deployment, and the date that matters. We return a scoped, priced statement of work.
Failure modes we see repeatedly
Shipping a graph visualization as the product. A picture with dozens of nodes and untyped edges impresses in a demonstration and is abandoned in week three. Typed, dated edges and named path types are what make a graph useful.
Alerting on state rather than change. The same alerts every cycle, cleared by rote, until a real one is cleared by rote too.
Letting cleared alerts return. Suppression is harder than firing and is skipped for that reason. It is also the single defect users complain about most.
Storing links instead of snapshots. A case file whose evidence changes meaning over time cannot be reviewed, which removes the product's whole claim to being a system of record.
Mixing model output with sourced fact. Once an investigator finds one inferred value presented as a fact, they verify everything by hand, and the product's value goes to zero while the licence is still being paid.
Treating in-environment deployment as a later port. The requirement arrives from the buyers you most want, and retrofitting it is a rebuild rather than a package.
Bottom line
An investigations product is not a search interface over good data. It is a graph with typed and dated edges, traversal that knows the difference between ownership and a shared address, alerting that fires on change and remembers what was already cleared, and an evidence model that captures what the investigator saw rather than a link to what it says now. Models earn their place by ranking, filtering, extracting and summarizing with citations, and they must never make the disposition. Build the whole thing to the standard a government reviewer expects and the large-enterprise requirements are already met. Do that, and the product stops being a research tool people try and becomes the system of record for a function, which is a different price and a different renewal conversation.
Frequently asked questions
An entity graph with typed and dated edges rather than generic links, traversal semantics that distinguish ownership from a shared address, alerting that fires on change and suppresses what was already cleared, and an evidence model that snapshots what the investigator saw with full provenance. Plus immutable attributed notes, a complete access log, the ability to reproduce the graph as of a decision date, and a case export a reviewer can read without access to the system.
Because they show paths without saying whether a path means anything. Two entities connected through a shared registered-agent address are not in the same position as two connected by ownership, and a product that treats all edges alike buries real findings in noise. The fix is to type and date every edge, make path types first-class so ownership, control, shared-officer and shared-address paths can be searched separately, and weight them differently in scoring.
Alert on change rather than on state, which requires storing what was known at the last evaluation. Deduplicate at the subject level so several sources reporting one event produce one alert with several sources attached. Carry dispositions forward so a cleared false match stays cleared until something material changes. Explain each alert inside the alert, naming the rule, values, sources and what changed. And let customers tune thresholds as versioned configuration with a record of who changed what.
For volume problems: ranking alerts by likely materiality, classifying adverse media by allegation type and relevance, extracting entities and relationships from unstructured documents, scoring candidate entity matches, suggesting which graph paths merit attention, and summarizing long documents with citations. Never for the disposition itself. Label every model-derived value in the interface, record model version and inputs so outputs are reproducible, and cite specific source passages in any generated text.
Mostly the deployment and the evidentiary bar rather than the features. It often has to run inside the agency's own boundary rather than in your cloud, sign-in must be federated with government credentials and agency-controlled roles, user-action audit logging is required with agency-set retention, accessibility is tested with real assistive technology, and handling rules apply to sensitive information. The government requirements are effectively a superset of the enterprise ones, so building to them satisfies both.