Who this is for
Analytics engineer or data lead after a bad load that passed every schema check.
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.
What is 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
You receive
- 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
What is 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
What we need from you first
- 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
Never send passwords, keys, customer records or confidential code in the first enquiry. Secure handover is agreed after scoping.
How we check it is done
- 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.
- 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.
- 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.
- Every item on the agreed risk list (nulls, duplicates, freshness, volume drop, range, references) has at least one check.
- 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.
- You have approved or rejected each check, and each has a 'what to do when this fires' note.
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.
When we would stop or decline
- 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
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.
Price and terms
£295 · untested offer price. £295 after the acceptance tests below pass and you sign off. No payment before sign-off.
This is a new service with no published client results. The price is a starting point we have not yet tested with buyers. Nothing is ordered or charged by the enquiry. The full specification is on the Synthetic Industry catalogue.