The Data SITREP

Entity resolution answers "what is this record about." It doesn't answer "what's changed, what's missing, and who needs to know." Once documents are linked to a canonical entity, a new problem opens up. An entity's picture is built from many documents arriving on different schedules, and nobody was watching for what should have arrived but didn't, what changed since the last version, or what a change implied downstream.

Manually, this meant an analyst periodically re-checking each entity by hand, which doesn't scale past a small portfolio and catches problems well after they matter.

A monitoring layer on top of the entity graph. A point-in-time record of every tracked attribute, refreshed as new documents resolve to that entity.

• Tardiness detection flags when an expected document for a tracked entity hasn't arrived within its normal cadence.
• Duplicate detection identifies when two or more documents for the same entity exist at the same key point in time, month, quarter, year, and allows the user to designate a source of truth document, assisting with version control.
• Time-series view sees how the entity's attributes change over time, not a single flattened snapshot.
• Reference-data enrichment from external and client-provided datasets to allow validation, for example cross-referencing a client's bank or wire dataset against a resolved entity to flag unexplained changes.

These raised validations and the enrichment data are used by the review agent architecture.

The easy version of a document or data tracker is simply, here's the entity and here are its current values.

That's not what an analyst actually needs. They need to know what to act on, and they need to do it in a timely manner, and a snapshot alone doesn't tell you that. Two identical-looking snapshots a month apart could represent nothing changing, or something changing twice and reverting, and those are very different situations for a compliance team.

Therefore, this system is built around deltas, not snapshots. Every update is stored as a point in a time series, and the meaningful output is the comparison between points, not the point itself.

This is the same principle woven into my build DNA. The value isn't in reporting what is, it's the insight in surfacing what changed and what that implies.

With this product, clients had a system that flagged missing documents before it became a client escalation, not after.

The same pattern applies anywhere state matters more than a snapshot. Risk monitoring, compliance drift, SLA tracking. The bank or wire enrichment case is a small version of this. An unexplained change in client-provided reference data isn't just a discrepancy, it's a flagged anomaly on the same timeline as everything else. The system doesn't need to understand why a change matters. It needs to reliably surface that something changed, on a timeline, and route it to whoever's job it is to decide.