Bind the control before the first row lands
Data quality arrives last because it’s scoped last. Move it to the moment the meaning gets decided and it stops being a project.
Your data quality initiative isn’t a project you failed to fund. It’s a symptom of having built the model without it.
Quality arrives last because it’s scoped last. It shows up on the plan as phase four, and phase four is where the budget went. So the checks get written months after the meaning was decided, by someone who wasn’t in the room when it was decided, reconstructing the rules from the code that implements them. Which is circular. You’re testing the SQL against itself.
Now look at what you wrote in week one. “Flag contract accounts with three or more consecutive estimated reads.” That’s a business rule and it’s a control. Same sentence. Nobody needs to re-derive it in month five. Somebody needs to stop throwing it away in month one.
Every claim implies a check
Once a requirement is a set of typed claims instead of a paragraph, the symmetry gets structural. A claim that a measure sits at contract-account grain implies a uniqueness check. A claim that flat-rate accounts are excluded implies a check that none appear. A claim that the window is twelve months implies a freshness and completeness pair. You’re not inventing a quality backlog. You’re reading one off a model you already agreed.
The catalogue is what stops this becoming a thousand bespoke asserts. A control is a vocabulary item, parameterised to your asset, versioned independently of your code, vendor-neutral so it survives the platform decision you haven’t made yet. Binding one is a design act, done at the same desk, in the same hour, as the decision it protects.
A failing control shouldn’t be a notification. It should be a closed door.
Alerts are advisory. Tokens are load-bearing.
This is the line I won’t compromise on. If the outcome of a check is a message in a channel, then shipping is still a human decision made under delivery pressure at five on a Thursday, and you already know how that goes. The verdict has to issue something the orchestrator reads before it publishes. Pass, and the token exists. Fail, and it doesn’t, and the publish doesn’t happen. Not because somebody was disciplined. Because there was nothing to publish with.
The second half is what you keep. A test tells you it passed. Evidence tells you what held, under which control version, with which parameters, against which query, and what the observed value was. Eighteen months on, an auditor doesn’t want your log line. They want to re-run the thing and get the same verdict. Only one of those two survives the request.
What it does to the role
- Phase 4a DQ engineer writes asserts in a notebook, months after the meaning was fixed
- Outputa pass/fail log line. No parameters, no version, not reproducible
- Effectan alert channel everyone muted in the second week
- Audita reconstruction project, quoted in weeks
- Week 1controls bound to claims the moment the claim is agreed
- Outputa verdict, retained with version, parameters, query and observed value
- Effecta release token the orchestrator has to read to publish
- Backlogthe standing “data quality backlog” as a workstream
The uncomfortable corollary: bind quality at design time and a large body of remediation work stops existing. Not the people. The work. Nobody spends February reconciling a table against a spec that drifted, because the spec is what generated the table and the control was bound to the same sentence.
So the next time someone asks when the data quality workstream kicks off, the honest answer is that it already did. It started the day somebody wrote down what the number was supposed to mean.