ingest → standardize → matchkeys → block → score → cluster → golden → output.
Verdict table
Each verdict below is measured by a conformance test (or a documented architectural boundary), not assumed.What this means in practice
Handing off mid-numeric-pipeline is only as strong as the weakest link in the chain. If your hand-off point sits afterstandardize, after score (without
the shared WASM scorer), or after an embedding step, the resumed pipeline can
reach a different result than an all-one-language run. The failure modes are
concrete:
- a threshold decision flipping on a 4th-decimal score difference, or
- a date / standardized value not reproducing across the parsers.
Guidance
- Prefer the
clusteroridentityboundary for cross-language hand-off — both are byte-safe. - If you must hand off at the
scoreboundary, enable the shared WASM scorer on the TypeScript side (byte-identical only for the byte-exact covered scorers:jaro_winkler/levenshtein/token_sort/exact) and avoid re-thresholding across the boundary. Note on Fellegi–Sunter: the batteriesgoldenmatchimport now runs FS block scoring through the sharedfs-wasmkernel by default (byte-aligned with Python-native — the #1854 fixed full-field operating point), so hand off atscorefrom the baregoldenmatchentry for byte-safe FS. The leangoldenmatch/coreentry keeps the pure-TSprobabilistic.tspath (4-dp tolerance) unless you opt in withenableFsWasmScoring(). - Do not split a pipeline across
standardize/ dates, embeddings, or the auto-config controller and expect bit-exact reproduction. Run those phases in a single language, then hand off the durable artifact. - The distributed / VLM / routing phases have no TS path — run them in Python.
How this is verified (the conformance harness)
These verdicts are backed by a runnable cross-language conformance harness (Python oracle → TypeScript parity test), so they stay honest as the code evolves:- Clustering boundary — a Python emitter produces scored-pair scenarios plus
Python’s cluster partition; the TS test reruns each through
buildClustersand asserts the identical partition. Scenarios include the divergence-prone oversized-cluster MST auto-split (unambiguous and tied-weakest-edge). - End-to-end split-run — Python runs a real pipeline (
MatchEngine) and emits its scored pairs + clusters; the TS test (a) clusters Python’s real scored pairs and asserts it reproduces Python’s own clusters (hand-off fidelity), and (b) runs a full independent all-TSdedupeand asserts the same partition plus a bounded scored-pairs delta (no threshold flip). Blocking is neutralized so any divergence would be scoring/standardize, not a different candidate set. - Scoring tolerance — the scorer ground-truth parity test pins scores to 4 decimals across languages.
Known limit of the current evidence. The split-run’s clean agreement is
dataset-specific — the scorers happened to agree closely and no pair sat exactly
on the threshold. The 4-dp tolerance can still flip a cluster on adversarial data;
the honest next step (tracked in the design note) is a split-run over a corrupted
dataset engineered to sit pairs on the threshold, to find and quantify the
flipping case. “Passed on a fair test” is not “can never flip.”
Reference
- Design note + full verdict table:
docs/design/2026-07-24-cross-language-phase-conformance.md - Harness:
tests/parity/cluster-conformance.parity.test.ts,tests/parity/split-run.parity.test.ts, and their Python oracles underpackages/python/goldenmatch/scripts/emit_*_conformance_fixture.py/emit_split_run_fixture.py.