Overview#
An intelligence analyst is reviewing data ingested from three separate sources: an OSINT provider, a financial intelligence unit database, and a law enforcement records system. The same individual appears in all three, but with different name spellings, different date-of-birth formats, and two different passport numbers from the same issuing country. Manually reconciling those records would take hours and might still produce the wrong match. The Correlation domain resolves them in seconds, with a confidence score and a breakdown of which fields drove the match.
Entity deduplication is not glamorous work, but getting it wrong corrupts every analysis that follows.
Key Features#
- Multi-tier matching with deterministic and probabilistic strategies.
- ML-powered similarity scoring for entity comparison.
- Configurable correlation rulesets with adjustable thresholds.
- Confidence scoring for match quality assessment.
- Automated entity merging with conflict resolution.
- Cross-data-source correlation for entity deduplication.
- Batch and real-time correlation execution modes.
- Audit logging for all correlation decisions and merges.
Use Cases#
Intelligence analysts receive clean, deduplicated entity records from multiple intelligence data sources, with the correlation engine resolving duplicate records at ingestion rather than leaving the deduplication to manual analyst review.
Financial crime investigators build accurate network graphs of persons, organisations, and accounts linked to an investigation, knowing that duplicate entities from different data sources have been properly reconciled rather than appearing as separate nodes.
Law enforcement data quality teams run batch correlation jobs on periodic data imports from partner agencies, maintaining entity data quality across a growing multi-source dataset without dedicated manual review resources.
Cross-domain analysts performing POLE model analysis (Person, Organisation, Location, Object, Event) rely on correlation to ensure that the same real-world entity appearing across multiple POLE categories is correctly linked in the investigation knowledge graph.
Integration#
Integrates with entity management, investigation, and data source domains for cross-platform entity resolution and deduplication.
Open Standards#
- GraphQL (June 2018 specification): The entire API surface is implemented as a GraphQL schema, exposing typed queries, mutations, and real-time job-progress subscriptions for all correlation operations.
- RFC 4122 (UUID): All entity, ruleset, job, and result records are keyed by RFC 4122 UUIDs, ensuring globally unique, collision-resistant identifiers across multi-source data ingestion.
- ISO 8601: Timestamps and date-of-birth values are ingested, normalised, and returned exclusively in ISO 8601 format, enabling consistent temporal matching across heterogeneous source systems.
- OAuth 2.0 (RFC 6749): API access is gated by named OAuth 2.0 scopes (
intelligence:readandintelligence:enrich), enforced on every query, mutation, and subscription resolver. - ICAO Doc 9303: Machine-readable travel document numbers (passports) are treated as deterministic hard-key identifiers in the scoring engine, triggering an immediate high-confidence match when two records share the same passport value.
- ISO 13616 (IBAN): International Bank Account Numbers are included as hard-key identifiers, supporting financial crime and sanctions-screening use cases where account-level deduplication is required.
- ITU-T E.212 (IMEI / IMSI): Mobile equipment and subscriber identifiers are explicit hard-key fields, enabling deterministic correlation of persons across telecommunications data sources.
- ISO 9362 (SWIFT/BIC): SWIFT business identifier codes are held as hard-key identifiers alongside IBAN, completing the financial-entity deduplication capability for cross-border investigation graph construction.
Last Reviewed: 2026-02-05 Last Updated: 2026-04-14