Skip to content

GoldenMatch

v2.6.0 Feature

This release adds 1 notable feature for engineering teams evaluating rollout.

Published 24d Data Pipelines & ETL
✓ No known CVEs patched
Read the diff → Tool health → What is this tool? →

✓ No known CVEs patched in this version

Topics

data-cleaning data-engineering data-matching data-quality deduplication entity-resolution
+14 more
fellegi-sunter fuzzy-matching knowledge-graph llm master-data-management mcp-server polars pprl python record-linkage rust splink typescript zero-config

Affected surfaces

auth rbac

Summary

AI summary

Auto‑config now vetoes problematic standalone exact matchkeys, preventing over‑merging of records.

Full changelog

Changed

  • Native Fellegi-Sunter (FS) block scorer is now authoritative by default (reference mode). _fs_native_enabled() flips from opt-in to default-on: when the native ext is importable, the probabilistic path uses the native Rust FS kernel (rapidfuzz-rs decides comparison levels); the numpy vectorized path becomes the reproducible fallback via GOLDENMATCH_FS_NATIVE=0 (also the automatic fallback for TF-adjustment / non-native-scorer fields or a missing wheel). Part of the Rust-is-the-reference direction (docs/design/2026-07-01-rust-is-the-reference-roadmap.md). Scoped to the probabilistic path only (opt-in type: probabilistic matchkeys / probabilistic routing); the default weighted path is unaffected. Measured F1-neutral on the probabilistic bench panel (gm_prob_native vs gm_probabilistic): febrl3 and synthetic_person identical, historical_50k −0.0007 (within noise); dblp_acm not measured (Leipzig CSVs gitignored in CI). Boundary-level score differences are possible where a rapidfuzz-rs vs rapidfuzz-py similarity sits exactly on a comparison-level threshold — the native result is now the reference; GOLDENMATCH_FS_NATIVE=0 restores the prior numpy operating point.

Fixed

  • Auto-config no longer commits a standalone exact matchkey on a shared locality attribute (#1351). A high-density column mis-classified as an identifier (e.g. a zip whose cardinality inflates on the 1k-row profiling sample) could back an exact matchkey and collapse everyone sharing a value into one cluster (~55% over-merge on real circulation data). A new discriminative-power veto (build_matchkeysautoconfig_discriminative.should_veto_exact) demotes a proposed exact key to blocking-only when records sharing its value do NOT co-agree on other identity fields — measured from the data, not from cardinality (which cannot separate zip from npi: both moderate-cardinality, opposite correct answers). Name-typed basket fields co-agree FUZZILY (SequenceMatcher ≥ 0.85) so corrupted duplicates keep their key (e.g. febrl3's soc_sec_id, whose duplicates carry corrupted names); structured ids compare exactly. Veto-only (never promotes; classification/blocking untouched), fail-safe keep on thin support / df=None; kill-switch GOLDENMATCH_DISCRIMINATIVE_VETO=0. Auto-config accuracy gate held (febrl3 / ncvr_synthetic / historical_50k F1 unchanged).

Weekly OSS security release digest.

The CVE patches and breaking changes that affected production tools this week. One email, every Sunday.

No spam, unsubscribe anytime.

Share this release

Track GoldenMatch

Get notified when new releases ship.

Sign up free

About GoldenMatch

All releases →

Related context

Related tools

Earlier breaking changes

  • v3.1.0 `GOLDENMATCH_FRAME=polars` now requires the `[polars]` extra; raises error without it.
  • vgoldencheck-v3.0.0 `inferred_type` emits neutral dtype vocabulary (str/int/uint/float/date/datetime/bool/other) instead of raw Polars dtypes.
  • vgoldencheck-v3.0.0 'inferred_type' now emits a neutral dtype vocabulary instead of raw Polars dtype strings.
  • vgoldencheck-v3.0.0 `scan_file`, `scan_dataframe`, and CLI `check` now run without Polars, using Arrow-native pyarrow.Table.
  • v3.0.0 Result frames now return pyarrow.Table instead of Polars DataFrame.

Beta — feedback welcome: [email protected]