This release adds 1 notable feature for engineering teams evaluating rollout.
Published 24d
Data Pipelines & ETL
✓ No known CVEs patched
✓ 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 summaryAuto‑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 viaGOLDENMATCH_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-intype: probabilisticmatchkeys / probabilistic routing); the default weighted path is unaffected. Measured F1-neutral on the probabilistic bench panel (gm_prob_nativevsgm_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=0restores the prior numpy operating point.
Fixed
- Auto-config no longer commits a standalone
exactmatchkey on a shared locality attribute (#1351). A high-density column mis-classified as an identifier (e.g. azipwhose cardinality inflates on the 1k-row profiling sample) could back anexactmatchkey and collapse everyone sharing a value into one cluster (~55% over-merge on real circulation data). A new discriminative-power veto (build_matchkeys→autoconfig_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 separatezipfromnpi: 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'ssoc_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-switchGOLDENMATCH_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
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]