Why records have to earn the system that reads them.
A person who opens a messy CRM quietly repairs it on the way past. They see four records for the same company and merge them in their head. They notice the title is three years stale. They know which of the two revenue numbers the team actually trusts.
That repair is never written down, and it is the reason the mess has been survivable.
The workflow you point at those records does not stop compensating. It compensates at the other end. Hand a deterministic script a wrong field and it throws an error and stops. Hand a model the same wrong field and it adapts, writes something plausible, and carries on. Both failed. Only one of them told you.
It also never gets the chance to merge anything. Your workflow reads record by record and writes back to each, so the four are never in front of it at once. It reads four companies because your CRM says there are four.
So the silent correction did not disappear when the person left the loop. It moved from the one reading to the one writing, and it stopped absorbing the mess and started spreading it, at volume, with confidence attached.
Below is the gate that belongs in front of any workflow that reads your records, in seven steps.
What was holding your messy CRM together?
The people reading it, and nobody counted that as infrastructure.
Remove the human from the read and the props come out at the same moment the volume goes up. A workflow that touches 400 records a day applies your worst field four hundred times before anyone opens a dashboard.
What should you clean first?
Scope what the workflow actually reads. Never the whole database.
Name the one workflow you want running, then list only the fields and records it will touch. That list is usually a fraction of what a cleanup project would have covered, and it is the only part that changes the outcome.
Stale records leave the scope here rather than getting scrubbed. Archiving the dead beats cleaning it.
How do you prove the cleanup worked?
Count the mess before you touch it. Duplicates in scope, empty required fields, fields where two systems disagree, records untouched for a year.
The before-number is the whole point. Without it, “the data is better now” is a feeling, and it will be challenged by the first person whose report looks wrong.
Why do duplicates come back?
Because the first merge was done by hand. Hand-merging clears today’s duplicates and teaches the system nothing.
Write the rules first. Which record survives, and for each field, which source wins. Rules mean next quarter’s duplicate meets a decision instead of an argument, and the person doing it is not relitigating survivorship from memory.
The same applies to two fields holding the same fact, which is the duplicate nobody counts.
What happens when the AI writes to the wrong field?
You put the failure back where you can see it.
Since the model will not stop adapting, the guard has to be something that cannot adapt. Three of them go in before any workflow writes.
Loop protection, so a process cannot trigger itself round after round. A do-not-touch list covering records and fields, honored at every write path including merges. And deterministic validation wrapped around every AI write, so a schema surprise throws the error the model would have smoothed over.
That last one is the whole trade. You are giving up a little tolerance in exchange for finding out.
Why does the mess refill after a cleanup?
Because nothing changed at the entry point. Cleanup without entry validation refills on a schedule, and the schedule is however fast your team works.
Treat the entry points field by field. Free text that should be a picklist. Fields with no owner. The test for any rule is whether it makes tomorrow’s records cheaper to trust without making them slower to create.
When is the data ready?
When a number moved, not when the work feels finished.
Re-run the counts from the start, and draw the conflict sample fresh at random rather than checking the records you just fixed. Until the numbers move, no workflow reads these records.
Starting points we use, and they are starting points rather than laws. Duplicates in scope under 2%. Required fields filled over 90%. Zero unexplained cross-system conflicts in a fresh sample. Entry validation live on every routed field.
A gate that reads a number cannot be argued with at the meeting where someone wants to launch.
What ties the seven steps together?
Every one of them removes a silent correction and replaces it with a written rule. That is the entire job. Your records were never as clean as the reports suggested. They were clean enough for a reader who compensated, and that reader is being taken out of the loop.
Clean data is the first place the judgment shows.
The full playbook, with the readiness audit, the merge rules, the write guards and the scorecard, is published at AI-Ready Data. The implementation kit is six markdown files you fill against your own records.