Building matchers that explain themselves

At On-Music, I work on systems that link film and TV transmissions to productions and episodes. Source metadata can be incomplete or conflicting, so a useful result needs more than a winning candidate.

It needs an explanation that QA can inspect, an explicit path for ambiguous records, and a record of what a reviewer decided. This account describes the design at a high level; internal data, measurements and test results remain private.

Keep the scoring signals visible

The matching engine uses weighted signals such as title similarity, episode alignment, runtime distance and source quality. Conflict penalties help distinguish candidates that look plausible but disagree with other metadata.

The useful output includes both the decision and the reasons behind it. A score breakdown lets a reviewer see whether a candidate won because several signals agreed or because one strong signal outweighed weaker evidence.

This is a deterministic scoring system. Future machine learning work can build on recorded outcomes, but that possibility does not turn the current matcher into an ML model.

Design the record around review questions

The audit trail needs to support practical investigation:

1. Why was a record matched?
2. Why did this candidate beat the alternatives?
3. Which inputs were missing or conflicting?
4. What did the reviewer decide?

SQL Server audit records and structured score breakdowns make the evidence available after the run. React inspection tools bring it into the review workflow.

That connection matters. Persisting a detailed explanation is useful only if the person checking the decision can find and understand it.

Make uncertainty actionable

Confidence bands distinguish decisions that can proceed from those that need closer inspection. Explicit “no match” outcomes prevent the system from forcing a weak candidate simply because one candidate must rank first.

The review interface exposes candidates, scoring evidence and conflicts. Reviewer outcomes can then be retained as durable feedback instead of disappearing into an isolated correction.

Keep the system measurable before adding complexity

I want the deterministic system to be explainable and its review outcomes recorded before introducing more complex modelling.

That gives later work a foundation: labelled outcomes, decision histories and evidence of where ambiguity occurs. It also helps distinguish a data-quality problem from a scoring rule or a review-interface problem.

The engineering spans the scorer, pipeline, data model and reviewer tooling. Each part affects whether people can investigate a result and use the system with confidence.