An investigator can be right about who owned a company and no longer have enough evidence to say when. Our experiment with OpenSanctions data made that difference visible: withdrawing one dated record weakened the ownership timeline, while another source kept the broader link supported.[1]
OpenSanctions brings together sanctions lists, watchlists and politically exposed person data, connecting records about people, companies and their relationships across sources.[2] Investigators can use that foundation to build an ownership case. When the evidence behind a case changes, they need to know which conclusions to revisit.
We tested that problem in 8DB, 8Braid's omnimodal database, using an archived OpenSanctions export and a fourteen-company ownership case. Withdrawing one dated registry record reduced the supported transition count to thirteen. An undated record derived from the US Office of Foreign Assets Control (OFAC) still supported the broader ownership link. Our research implementation kept those two answers separate.[1]
The contribution is a working connection between a source change and the particular conclusions it affects. For a team maintaining investigations, the potential payoff is less repeated reasoning: reopen the part that lost support and keep the surviving evidence visible. This experiment tests the mechanism; a customer evaluation must establish the time saved.
Start with what OpenSanctions already provides
OpenSanctions supplies consolidated entities, source-level statements and identifier mappings for reconciling records after deduplication. Its documentation explains provenance and reversible entity consolidation; its matching engine also provides explanations.[2] We used those foundations, including canonical IDs and referents, in this experiment.
It also publishes incremental change files. Its monitoring guidance describes preserving earlier decisions and separating changes that affect identity resolution from changes that affect relevance.[3] Those are existing integration capabilities that our work builds on.
Our experiment applies dependency tracking to a compound investigative conclusion: several dated ownership transitions form one pattern. It follows the support for that pattern through individual evidence withdrawals and restorations. It does not measure an improvement in entity-matching accuracy.
One record, two different conclusions
8DB experiment with OpenSanctions data · Five sequential changes
Same ownership link. Different evidence.
Either record can support the broad link. The dated transition needs the registry record.
companies with qualifying dated transitions
Ten-company research rule: met
Fourteen companies meet the dated transition rule. The selected ownership link has both dated and undated support.
Baseline before the five change events.
Inspect the selected company's source IDs
- Company
- NK-FHDAJQEfthBxzbGtmQkfyK
- Predecessor record (ends 19 July 2022)
- ru-e68824d0de3cb79fa39e13142ec8a01e0f5a7069
- Dated successor record
- ru-9e6b0d0ede8882add61f7c2a4baa9236c6b5cbca
- Undated alternative support
- ofac-8409e34bb9f71060876a5b8adc5bd1dd6da42932
The case joins a previous owner's recorded end date to a successor's start date for each company. Fourteen companies have a common successor, United Arctic Company, within a July 19–20, 2022 window.[1]
For one company, the registry successor record starts on July 20. A second, OFAC-derived record supports the same owner-to-company link without an ownership start date. These records can support different levels of detail. The dated transition requires the registry evidence; the broader link has an alternative support path.
We withdrew the dated successor record in a controlled test. The transition count fell from fourteen to thirteen, while the broader link remained supported. Withdrawing the remaining undated support then removed that link's support in the tested evidence set. Neither operation proves the ownership assertion false. It changes what this evidence set can establish.
The explorer shows the recorded states, including restoration. Each change can be checked against the exact source IDs in the evidence companion.
What the lattice contributed
The implementation records which source facts each conclusion depends on. Some conclusions have alternative support: either of two records may sustain a broad ownership link. Others need several premises together: a dated transition needs the predecessor's end, the successor's start and the same company identity. A multi-company pattern adds a count and a time-window rule.
We used 8DB's native lattice operations to track dependencies and identify affected cases. A separate temporal check evaluated the ownership pattern: at least ten distinct companies moving to a common recorded owner within thirty days. That is our research selection rule, not a sanctions threshold.
This separation matters. A surviving path through the dependency graph can establish that a broad link retains support. It cannot, by itself, establish that all the dates required by the ownership pattern still exist.
Across five controlled withdrawal and restoration updates, the incremental dependency results matched full rebuilds. Revalidating the selected case also matched validation of the fixed fifty-case comparison cohort. Withdrawing five predecessor records reduced the seed case to nine qualifying companies, below our ten-company selection rule; restoring them returned it to fourteen.[1]
The implementation kept three different answers distinct: a supported link, a supported dated transition and a qualifying multi-company pattern. Across the tested changes, it updated those answers consistently. That is the behavior an investigator needs when a source changes.
Why put this in the database?
A team could implement these rules in SQL or a graph application. The design bet behind 8DB is to make source-linked conclusions and their update behavior reusable database machinery, so each investigation tool does not need to build its own dependency handling. This research integration exercises that machinery on a concrete ownership case.
The practical distinction is visible in the explorer: removing a source does not force every conclusion into one shared valid-or-invalid state. Each conclusion is checked against the evidence it actually needs. Bring one changing source and one decision it supports. An evaluation can measure the effort to identify affected conclusions, update them and explain the result.
The next test should resemble a real correction
I want an analyst to open a changed case and see the affected conclusion, the source that changed, the surviving evidence and the fact needed next. That is a practical way to turn provenance into less repeated investigation.
The next evaluation should use a genuine registry correction or an upstream entity split. It should carry the update through ingestion, restart and revalidation, with exact recomputation as the correctness reference. We would compare the conclusions flagged for review with an analyst's adjudication, measure unnecessary rechecks, and record any affected conclusion the system missed.
OpenSanctions' change feed is a practical input for that next test. A feed change can originate in an underlying source or in data processing, so its arrival alone is not proof that the real-world situation changed.[3] The evaluation must preserve that distinction while deciding what the customer needs to review.
Bring one source correction that was difficult to propagate. We can map the affected conclusions and agree a small evaluation against your current workflow, with correctness and review effort as the acceptance criteria.
Notes and evidence
- Recorded update results and case evidence. September 13, 2026 research rerun. Five sequential change events were compared with full rebuilds; the explorer displays those saved states rather than executing live queries. Evidence identifiers and compared fields are included. Consistency with a rebuild does not independently establish real-world ownership or completeness of the sources.
- OpenSanctions: dataset and source overview, statement-level provenance, identifiers and deduplication, and logic-v2 matching. These describe the data foundation and upstream capabilities used here; we have not run a head-to-head comparison.
- OpenSanctions: building a monitoring workflow and dataset delta files, reviewed September 17, 2026. These supply the integration context for the proposed real-update evaluation. Our saved experiment used controlled withdrawals, not a deployed consumer of the live change feed.
Evidence scope Research implementation · Five controlled evidence updates. Explore the evidence. Methods and retained scope notes.