Standing service data-checks-reviewed-and-tuned-every-month · revised 12 October 2026
Standing service
Every month, review our data checks: retune noisy ones and propose missing ones
Each month your check alerts are reviewed. Noisy checks are retuned and missing ones proposed, each change shown on a planted failure and recent history before you merge it.
This starts a conversation by email. Nothing is charged, and nothing is run, until we have agreed scope, data route and terms with you in writing.
The responsibility you hand over
Data checks decay. Thresholds drift out of date, new tables arrive with no checks, and noisy alerts teach people to ignore all of them. A monthly review keeps them useful, and only if each change is shown to work.
Who it’s for: Data lead whose checks were set up once and now either fire too often or miss new kinds of bad load.
Usually starts when: People have stopped reading the alerts, and a new table was never given any checks.
The result: Every month you receive a review of the alerts your checks raised, with noisy checks retuned and missing checks proposed as a pull request. Each change is shown to fire on a planted failure and stay quiet on recent good history. You review and merge.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A date for each month's report is agreed in writing before it starts, set to what a service at this stage can keep.
Runs once a month after the sample arrives. At launch the service is not staffed round the clock.
What must remain true
- Each month every fired alert is reviewed as true, false or ignored
- Every changed or new check is shown to fire on a planted failure and stay quiet on recent good history before you are asked to merge it
What we watch
- The month's alert history with your labels
- Counts, null shares and number or date ranges for tables
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A month closes and the labelled alert history arrives. | We review the alerts, retune noisy checks and propose missing ones as a pull request with evidence. |
| A check fires falsely more than the cap in a month. | We retune it and show the change on recent history, or propose dropping it. |
| A new table has no checks. | We propose up to three, each shown on a planted bad copy. Linked job: Data checks shown on one table |
We do on our own
- Review the alert history
- Prepare the pull request and evidence
- Propose new checks
We ask you first
- Any change that would silence a check for good
- Any request for row-level data or access
We escalate to you when
- A check missed a bad load that you report
- Alert volume doubles in a month
- The history stops arriving
How you know it held. Each month the review states alerts true, false and ignored, and every change in the pull request links to its planted-failure evidence.
How we keep it true
This service is never finished. Each month's report shows whether the thing it watches stayed true, and it continues until you end it.
Add data checks to one table and show they would have caught your last bad load Job Optional
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.
Bought separately; not part of the monthly fee
The one-off job that sets up the first checks on a table and shows each one firing.
What is included, and what is not
- The monthly review
- The pull request of changes
- The planted-failure and history evidence for each change
- A short summary
Included
- One data project with up to 40 checks already in place
- A monthly review of fired alerts: true, false and ignored
- Retuning of noisy checks and up to three new checks a month
- A pull request with each change shown on a planted failure and recent history
- A short summary of what changed and why
Not included
- Running or hosting the checks
- Fixing the data or the loading jobs
- Seeing row values: only the schema and the counts, null shares and number or date ranges you send are used
- Out-of-hours cover or any guaranteed response time
- Merging anything
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each month's review accounts for every fired alert as true, false or ignored.
Evidence: The review and your alert labels.
Every changed or new check fires on its planted failure and stays within the false-alert cap on recent history. We plant the failures, so this is a smoke test that a check can fire, not a measure of how many of your real bad loads it would catch.
Evidence: The evidence tables in the pull request.
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 went to a model.
Evidence: The input log.
Sign-off. You read each report and tell us whether the marks and rules still suit you. A month counts as delivered when you have received the report.
If it fails. If we cannot run a month because a sample is missing or has changed shape, we say so, explain what we need and do not guess. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- Checks exist in dbt, Soda or Great Expectations, with 90 days of alert history
- A named person labels each fired alert as true, false or ignored
- A pull-request route into your repository
- Only counts, null shares and number or date ranges leave your systems; no text values
We stop and tell you if
- No alert history exists
- Nobody labels the alerts
- You want row-level data sent to a model
- More than 40 checks, unless you ask for a quoted larger scope
What could go wrong
The service reads samples and writes reports, so there is nothing to undo. Ending it leaves your systems exactly as they are; you keep every report we sent.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Retuning hides a real failure. | No check is silenced for good without your approval, and each change is shown to fire on a planted failure. |
| Alert volume keeps rising. | The review reports volume each month and escalates a doubling. |
| Row values reach a model. | Only the schema and counts, null shares and number or date ranges are used, and the input log is available. |
A separate automated reviewer checks each change and its evidence before hand-over and does not mark the monthly sample. The alert owner on your side labels each fired alert and signs off. No person on our side is included unless your agreement names one, and at launch the work is largely automated.
Stays with a person
- You or your named person accept every report and every change to a rule, mark or setting
- You apply anything the report suggests in your own systems
Access we would need
- Redacted, synthetic or public samples you send each month by an agreed secure route
- Your labels for the monthly sample
Questions
Do you run the checks?
No. You run them in your own tool and send the month's alert history.
Can you turn a check off?
Only with your approval, and each change is shown first.
Do I need the one-off job first?
Not if checks already exist. We start from the alert history.
Also part of
Send an enquiry
Send us
- Which tool the checks run in and how many there are
- Roughly how many alerts fire a month
- No real records, personal data or credentials in the first enquiry
Later, once you agree
- The alert history with your labels each month by an agreed secure route
- Counts, null shares and number or date ranges for new tables
- A named person who labels alerts and merges
- A written cap on model usage
You keep your warehouse, repository and every decision. We work on the alert history and the counts, null shares and number or date ranges you send each month, return a pull request, and delete our copies at the end of each month. We have no warehouse login.
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-checks-reviewed-and-tuned-every-month” as the subject.