The real problem
Most data quality tools hide the assumptions that decide what gets found.
Teams usually feel CRM data problems before they can measure them. The same contact appears twice. A dashboard counts the same company twice. Ownership is missing right before handoff. Stage values drift into variants that no longer match the pipeline.
A generic cleaner can return a score, but that score is only true for the assumptions behind it. If the audit only checks exact email matches, it misses duplicate contacts with changed emails. If it uses fuzzy names without company context, it may group people who should stay separate.
That is why the artifact puts configuration before the score. The configuration explains what kind of truth the score is allowed to tell.
Start with the artifact
Open the working audit before reading the build notes.
The article makes more sense after seeing the tool run. Load the sample, switch between Standard, Configured, and Custom, and watch the same dataset produce a more honest score as the checks become more specific.
Three audit models
Standard, Configured, and Custom are different checks, not visual themes.
The preset cards are there because duplicate detection is dataset-dependent. The same file can produce different scores because each preset asks a different operational question.
Standard
Algorithm defaults, no field context
Standard is deliberately narrow. It uses email-only blocking with a strict threshold, which is good for obvious duplicate records that share the same email address.
It is easy to explain and low-risk, but it misses the structural problems that usually hurt a CRM: changed emails, variant spellings, and duplicate contacts split across the same company.
Configured
Field roles mapped, fuzzy matching on
Configured marks email as an identity field, then uses names and company context as supporting signals. This catches near-matches that Standard cannot see.
The score often drops here. That is not a bug. The additional exceptions were already in the data; the audit is now looking hard enough to find them.
Custom
Tuned to this dataset structure
Custom is the version built around the shape of the sample CRM export. It uses company-aware blocking, owner context, and a lower threshold because those signals matter in this dataset.
This is the most actionable run. It is also the lowest score, because it finds the duplicate clusters and field problems that a default audit would miss.
Same file, three scores
The health score falls as the checks get honest.
These three runs use the same 4,217-row sample. Standard reports 76. Configured, with field roles mapped and fuzzy matching on, finds more of the duplicates that were already there and drops to 71. Custom, tuned to how this CRM is structured, lands at 53. The data did not get worse between runs; the audit got more honest.
Uniqueness moves the most, from 89 to 73 to 12, while the duplicate exceptions found climb from 32 to 76 to 252. The higher score was hiding the work, not removing it.
Email-only blocking. It looks healthy because it is not looking hard.
Which matches it trusts, and which it only flags
A single shared field is a lead, not a verdict.
The score is only as honest as the rule behind each check. The audit is deliberately slow to call two records the same, because the cheap version, act on any one shared value, is exactly how a real merge deletes a real customer.
The trust rules behind the score
Two signals, hard before soft, and a guard against fake clusters.
Two signals before it acts. One shared email is a candidate, not a duplicate; the audit wants a second agreement, a name, a company, a domain, before it treats two records as the same. One clue can lie; two rarely agree by accident.
Hard signals before soft ones. A shared exact identifier is hard evidence; a fuzzy name is soft. Two soft agreements are not worth one hard one, and the confidence score reflects that split rather than counting every match equally.
A guard against the placeholder cluster. A column where thousands of rows share N/A or 000-000 is not a signal. Block on it blindly and you invent one giant fake duplicate cluster, so the audit caps or skips those degenerate buckets.
Valid is not correct. A well-formed email, or a checksum that recomputes, can still point at the wrong entity, so the audit surfaces the exception for a human instead of trusting the format and auto-fixing it.
What the score is made of
The dimensions stay visible so the health score does not become a black box.
Completeness shows missing decision fields
Missing data is not equally important. A blank phone field may be harmless in one workflow, while a missing owner or email can break a handoff. The artifact shows field-level notes so the user can see what is dragging the score down.
Uniqueness is where configuration matters most
Exact identifiers are precise but narrow. Fuzzy matching increases recall, but only becomes useful when company, owner, domain, and threshold choices match the dataset. That is why the artifact lets the user compare audit models.
Consistency catches controlled-value drift
Stage, country, status, and lifecycle fields should usually have a controlled vocabulary. Variants like Prospect, prospect, and PROSPECT split reports and quietly damage dashboards.
Freshness stays quiet unless the date field matters
A freshness check only makes sense when a date field actually represents operational recency. The artifact does not force a stale-data warning when no date field has been marked decision-critical.
Why the interface is arranged this way
The page reads like an investigation: setup, signal, priority, evidence.
File strip establishes trust
The user sees the file name, row count, column count, and browser-only privacy state before interpreting the audit. That makes the scope of the result clear.
Configuration explains the score
The cards come before the gauge because the score is meaningless without knowing which duplicate model is active. This prevents the lower Custom score from being misread as a worse dataset.
Prioritized fixes translate data into work
The fix list tells the operator what deserves attention first: missing critical fields, duplicate clusters, enum drift, or other exceptions that would change real decisions.
Exception rows are the proof layer
The table stays plain on purpose. It shows type, field, explanation, severity, and confidence so a human can review the evidence before changing records.
The design rule
Surface and rank. Do not silently decide.
Auto-fixing looks attractive in a demo, but merging CRM records affects ownership, attribution, active deals, reporting history, and customer communication. The artifact stops before that decision point.
High-confidence exact duplicates are shown differently from fuzzy matches. Drift is shown as variants rather than silently normalized. Missing fields are ranked by impact, not patched with guesses.
Production version
The Builds artifact audits a snapshot. The real version would catch the pattern earlier.
Run the tuned rules continuously
A production version would connect to the CRM or scheduled export, remember the tuned rules for that dataset, and track whether data health is improving or decaying over time.
Move checks closer to data entry
The bigger win is warning before a duplicate is created, flagging missing owner fields before handoff, and normalizing enum values before dashboards split.
If you can feel the CRM data is wrong but cannot say exactly where, a tuned audit is the honest first step.
The concept shows the model. A real audit starts from the decisions the data is supposed to support, then tunes the duplicate logic and field checks to the shape of your actual export, which is where a generic score stops being useful.
Bring the page, report, or workflow as it is now.
We reply with the clearest next step, or an honest no.
