Job data-quality-checks-proposed-and-proven-on-one-table · revised 12 October 2026
Add data checks to one table and show they would have caught your last bad load
For one table, up to 15 checks in your tool's syntax, each shown to fire on a planted bad copy and stay quiet on 90 days of good history. The model sees only the schema, counts and ranges.
You might be seeing
- A table was wrong for days and every job showed green
- Nobody knows which checks would have caught last month's bad load
No passwords, keys, card details or admin invites needed to start.
What usually happened
Drift that passes schema validation is common: renamed columns, a headers-only file, text in a numeric column, a changed date format. A model can propose checks quickly, but its thresholds are unvetted. A check only counts if it fires on a planted bad copy and stays quiet on good history.
Who it’s for: Analytics engineer or data lead after a bad load that passed every schema check.
Usually starts when: A load went through without an error and put wrong data in a table; the problem was found days later.
The result: For one table, up to 15 checks in your tool's syntax (dbt tests, Soda or Great Expectations). Each is shown to fire on a planted bad copy and to stay quiet on 90 days of good history, apart from exceptions you accept. A copy that recreates your last bad load makes at least one check fire, and the model sees only the schema and a profile of counts, null shares and number or date ranges that you generate, with no text values.
Check whether this job fits
Answer these without sending files or logins. Nothing is submitted unless you choose to contact us.
What you get
- The pull request with up to 15 checks
- The planted bad copies and the results
- The 90-day false-alert list
- A 'what to do' note for each check
- Run steps
Included
- One table in a warehouse or database, with at least 90 days of history
- Up to 15 checks that cover the agreed risk list: nulls, duplicates, freshness, volume drop, range and references
- One planted bad copy per check, one copy that recreates your last bad load, and a 90-day replay for false alerts
- A short 'what to do when this fires' note for each check
- A pull request into your repository that you review and run
Not included
- Running or hosting the checks for you
- Seeing row values: the model gets only the schema and a profile of counts, null shares and number or date ranges
- Fixing the data or the loading job
- Checks across many tables
- A promise that no bad load will get through
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each of the checks fires on its own planted bad copy, and you approve every planted copy before the build; at least three are failures you choose, from your own incidents or the ones you fear most. A check that stays silent is removed or fixed before hand-over. We plant the copies, so this is a smoke test that each check can fire.
Evidence: The check-by-check planted-failure table.
A copy of the table that recreates your last bad load (or the failure you fear most), which you build or approve, makes at least one check fire.
Evidence: The approved copy and the check that fired.
Across 90 days of good history, false alerts are no more than the agreed count (we propose 3 across all checks), and each is listed.
Evidence: The false-alert list.
Every item on the agreed risk list (nulls, duplicates, freshness, volume drop, range, references) has at least one check.
Evidence: The coverage table.
The input log shows only the schema, counts, null shares and number or date ranges; no text value and no list of most common values was sent to a model.
Evidence: The input log.
You have approved or rejected each check, and each has a 'what to do when this fires' note.
Evidence: Your decision per check and the notes.
Sign-off. You inspect the planted-failure table and the false-alert list, approve the checks and sign off in writing. Payment follows sign-off. You run the checks.
If it fails. If an acceptance test above is not met, you do not pay for this fixed scope. You keep the results and the failures, and we agree whether to stop or re-quote. No surprise work.
When it fits, and when we stop
It fits when
- One table with at least 90 days of history and a read-only way to take a profile of counts, null shares and number or date ranges
- Your tool is dbt, Soda or Great Expectations
- A named person owns the alerts and approves or rejects each check
- You can name the last bad load, or the failure you fear most
We stop and tell you if
- There is no history to replay
- You want row-level data sent to a model
- Nobody owns the alerts
- The table holds personal data and a profile of counts, null shares and number or date ranges cannot be taken without it
What could go wrong
The job reads copies you send and writes files. It changes nothing in your systems, so there is nothing to revert. Our copies of your files are deleted when the job ends.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Checks fire so often that people stop reading them. | The 90-day replay lists every false alert, and the cap is agreed in writing. Checks over the cap are tuned or dropped. |
| A model-proposed threshold is wrong for your data. | Each threshold is shown on your own history and approved or rejected by your owner. |
| Row values reach a model. | The model gets only the schema and a profile of counts, null shares and number or date ranges. The input log is part of the evidence. |
A separate automated reviewer checks the checks, the planted failures and the false-alert list before hand-over. The alert owner on your side approves each check and the planted copies, and signs off. No person on our side is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the table, the risk list, the false-alert cap and the severe errors
- Receive the schema, the profile and 90 days of the same
- Propose up to 15 checks; you approve or reject each
- Plant a bad copy for each check, then replay 90 days of good history
- Independent review of the checks, the planted failures and the false alerts
- Hand over the pull request and results; delete our copies
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the price, a start window and a delivery date before you accept, and work starts only after inputs, a secure handoff route and permissions are in place. Model usage up to a cap agreed in writing is included, and an enquiry creates no charge or booking.
Need to keep it working?
Want the checks reviewed and tuned monthly? A monthly service does that.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing managed lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Free tools such as dbt tests, Soda's free tier and Metaplane's free plan can run data checks that you or their detectors define. This job adds the demonstration that each check fires on a planted failure and stays quiet on good history. www.soda.io
- dbt Copilot can generate tests from a prompt if you already use the dbt platform. docs.getdbt.com
Questions
Does the AI see my data?
It sees the schema and a profile of counts, null shares and number or date ranges, never row values or text values. The input log is part of what you receive.
Will this catch every bad load?
No. It shows which failures your checks would have caught and how often they raise a false alarm.
Do you run the checks?
No. You merge the pull request and run them in your own tool.
Send an enquiry
Send us
- The table's column names and types, as text
- What went wrong last time, in a sentence, and which tool you use
- No real records, personal data or credentials in the first enquiry
Later, once you agree
- A profile of counts, null shares and number or date ranges, and 90 days of the same, by an agreed secure route
- A planted-bad-copy sample you approve
- A named alert owner
- A written cap on model usage
You keep your warehouse, your repository and every decision. We work on a profile of counts, null shares and number or date ranges that you generate and send by an agreed secure route, return a pull request, and delete our copies when the job ends. We have no warehouse login and see no row values or text values.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “data-quality-checks-proposed-and-proven-on-one-table” as the subject.