goldenmatch

What the golden entity is

GoldenMatch is presented as an entity-resolution product that does more than cluster records. The README explains that it resolves messy records from many sources into one durable golden entity per real-world customer, and that this identity survives re-runs. Every entity gets a stable entity_id using UUIDv7 that persists as new data arrives, unlike run-local cluster numbers that reshuffle each time. Whole-record provenance is a core claim: every field of the golden record traces back to the source record that won it, including which source, when it was last seen, and which survivorship strategy picked it. The values it did not pick stay visible rather than being dropped. Conflicting values collapse to one best value through an explicit survivorship policy that can be most-complete, source-priority, most-recent, or majority-vote. Every identity change lands in an append-only event timeline, and the log is sealed with a hash-chained, tamper-evident audit that a reviewer can independently verify. The customer_360 call composes the golden record, per-field provenance, linked source records, the event timeline, and the relationship neighborhood into one read. The README labels the identity spine as production-grade and in the main branch, while the customer_360 serving view and the source-registry layer are described as newer, actively landing pieces. The same customer_360 call returns the relationship neighborhood so downstream systems can see how one entity connects to others, which the README presents as part of the durable identity rather than a separate lookup.

Two engines and many surfaces

The project separates the work into two engines. The identity compute engine is Arrow-native and Rust-authoritative, and its job is to block, score, and cluster records with throughput and vectorized, deterministic execution per run. The identity control plane is a transaction-native state machine, with SQLite as the default storage and Postgres as another option, and its job is to hold stable ids, survivorship, merge and split, provenance, and the append-only audit. The README argues this split matters: the compute layer is backend-replaceable so heavy matching can move to a query engine that plans, spills, and distributes, while the identity layer is a real state machine rather than a columnar rebuild-every-time batch. The same capabilities reach Python, edge-safe TypeScript with an opt-in WASM backend, SQL inside PostgreSQL and DuckDB, and MCP or REST or A2A surfaces, all governed by a conformance spec rather than copy-paste. The suite also includes sibling tools that clean and standardize records before they reach the identity layer: InferMap for schema mapping, GoldenCheck for data-quality scanning, GoldenFlow for transforms, GoldenAnalysis for reporting, and GoldenPipe for declarative orchestration. The project states it owns its string-matching primitives instead of renting them. Those primitives include faster-than-rapidfuzz fuzzy scorers and jellyfish-compatible phonetic encoders published on their own, so other projects can use them without pulling in the whole suite, which the README frames as a portability benefit.

Accuracy and scale claims

The README backs its matching claims with reported benchmark numbers and says every headline number maps to a single committed runner script. On messy customer records the opt-in Fellegi-Sunter engine is said to beat hand-tuned Splink head to head, with a reported pairwise F1 of 0.827 against 0.757 and cluster B3 of 0.862 against 0.788 on a shared evaluator. The project reports accuracy on customer-shaped data including NC Voter at 0.9719 F1 and Febrl3 at 0.9912 F1. A privacy-preserving record linkage mode using Bloom-filter PPRL is reported at 92.4 percent F1 on FEBRL4 with HMAC-salted encodings. Scale is demonstrated by a reported 250 million row dedupe in 11.2 minutes, verified from a laptop CSV up to a distributed run. The SQL path runs inside PostgreSQL as a pgrx extension and inside DuckDB, so resolution can happen without moving data out of the warehouse. For Spark, the Rust kernels are shipped as a single jar called over JNI so executors need no Python environment installed. The README also reports cross-language parity is measured, not assumed, and lists which boundaries are byte-safe versus only convergent, so users know where handoffs stay seamless and where they should not expect bit-exact reproduction. The README states the rule of thumb is to hand off at the cluster or identity boundary for a seamless result, and not to split a run across standardize, dates, embeddings, or the controller if bit-exact reproduction is required. The suite also ships knowledge-graph packages that use GoldenMatch as the resolution stage inside GraphRAG frameworks, with reported gains on labelled sets over several other graph builders.

Editorial conclusion

GoldenMatch is distributed under the MIT license, and the repository's most recent commit was on 2026-08-26. The project lives at github.com/benseverndev-oss/goldenmatch.