Skip to main content
GoldenMatch is built around one workflow, not a pile of knobs:
1

Zero-config first pass

dedupe_df(df) runs with no rules and no training. Auto-config profiles your data, picks a defensible matching config, and you get good results immediately.
2

You get the config it chose

The chosen config is returned to you, inspectable and versionable — never a hidden black box. Keep it, diff it, check it into git.
3

The healer suggests tweaks

review_config(df, config) reviews the results against the config that produced them and emits ranked, explainable edits — lower this threshold, swap that scorer, add negative evidence. Each suggestion is self-verified: it is simulated and kept only if it does not worsen an unsupervised health proxy, so a suggestion never makes your results worse.
4

You apply the tweaks

Accept the ones you want with apply_suggestion(config, suggestion) → an improved config.
5

Results improve. Repeat.

Re-run with the improved config; loop until the healer goes quiet.
Zero-config gets you most of the way in one pass; the healing loop closes the gap to an expert-tuned config without you having to be the expert. It is the user-facing expression of two project commitments: zero-config should embarrass the alternatives, and out-of-the-box should approach the hand-tuned expert.
The healer is wired into the default pipeline. Every dedupe_df(df) run now checks a free controller signal (RED/YELLOW health or a score dip) and, only when it fires, attaches cheap raw candidate suggestions to result.suggestions — no extra pipeline run on a healthy result. Opt into the expensive verified path with dedupe_df(df, suggest=True), or run the full apply-and-re-run loop with dedupe_df(df, heal=True). The same surface is on CLI (--suggest / --heal), MCP (review_config), A2A, REST, web, and the TUI (Suggestions tab). It requires goldenmatch[native] (the suggestion kernel is compiled); without the native wheel every surface degrades gracefully — it attaches no suggestions and never raises. Kill-switch: GOLDENMATCH_SUGGEST_ON_DEDUPE=0. On the TypeScript surface the same healer is the opt-in goldenmatch/core/suggest-wasm subpath (see TypeScript and WASM below); without the WASM kernel TS degrades gracefully to empty suggestions.

The loop in code

Or let the pipeline do it for you

The loop above is wired into dedupe_df directly, so you don’t have to call review_config by hand:
The default attach is free on a healthy result — the free controller signal short-circuits before the kernel is ever called. Set GOLDENMATCH_SUGGEST_ON_DEDUPE=0 to turn the surface off entirely.

What the healer suggests

The suggestion kernel emits ranked, explainable edits, each with a rendered rationale so the loop is never a black box: Blocking-pass and field-weight suggestions are staged for a later kernel version.

The self-verify gate (why a suggestion never makes things worse)

At suggestion time there is no ground truth, so the healer cannot peek at F1. Instead, for each candidate it simulates the edit (apply → re-run) and keeps it only if an unsupervised health proxy does not get worse than the current config. That structural guarantee — “no net-negative suggestion” — is what makes the loop safe to run unattended. The default proxy is cohesion (min_edge × saturating coverage, cap 0.50): it rewards clusters held together by strong intra-cluster edges and is sensitive to over-merge, so it correctly keeps precision-improving fixes that a recall-biased proxy would discard. Measured on the suggester gym, switching the gate to this proxy lifted live recovery from 0.15 → 0.54 (matching the raw kernel ceiling — the gate stops discarding correct fixes) with zero net-negatives on real perturbations. You can change or disable the gate: These are also in the full tuning reference.

TypeScript and WASM

The healer runs on the TS/JS surface too, via the suggest-core kernel compiled to WebAssembly (suggest-wasm). It is the same pyo3-free kernel (packages/rust/extensions/suggest-core) as the Python native path, so a suggestion is byte-for-byte identical across surfaces. It is wired into dedupe() with full parity: dedupe({ suggest }) and dedupe({ heal }), the same free trigger, and the same bounded heal loop. Every TS surface (core, CLI, MCP review_config, A2A review_config skill) reaches it.
  • Opt-in kernel. The always-on healer surface reaches the kernel through a tiny lean registry; the heavy WASM module is behind the opt-in subpath goldenmatch/core/suggest-wasm. Importing it and calling enableSuggestWasm() registers the backend. This is the exact TS analog of the Python [native] extra — it keeps default bundles lean (no inlined wasm) and edge-safe. disableSuggestWasm() unregisters it again.
  • Graceful-empty without the kernel. With no backend registered, every TS healer surface returns [] / undefined and never throws — dedupe() works exactly as before, just without suggestions. There is no hard failure for not opting in.
  • Kill-switch / explicit options. The default suggestion pass honors GOLDENMATCH_SUGGEST_ON_DEDUPE (set 0 to disable) where a Node-style process.env is available; { suggest: true } / { heal: true } are explicit and always run.
The TS kernel is byte-for-byte the same logic as Python and Rust: the suggestion golden vectors authored by the suggest-core oracle are run against the committed WASM in the TS parity suite and against the Python native path, so a suggestion’s {input → expected} is one shared cross-surface contract (TS == Rust == Python).
  • Auto-config — how the zero-config first pass converges on a defensible config.
  • Learning Memory — persists steward accept/reject decisions across runs (the durable layer beneath the loop).
  • Evaluation — measure F1 once you have labels.