Job dbt-models-built-from-your-spec-and-proven-against-totals · revised 12 October 2026
Build the reporting tables I have specified, and prove them against my control totals
Up to three reporting tables, written as tested dbt models or SQL views from your written spec, each reconciling to control totals you sign off. Reviewed and merged by your team.
You might be seeing
- Reporting tables are specified but not built
- The last build produced numbers that did not match the finance totals
No passwords, keys, card details or admin invites needed to start.
What usually happened
An agent can write models from a spec quickly, but a model that runs is not a model that is right. The check that matters is whether the output matches totals finance already trusts. Without control totals and tests, speed only moves the error sooner.
Who it’s for: Analytics lead with a clear spec for a few reporting tables and no spare engineering time.
Usually starts when: The spec is written and agreed, the tables are not built, and last time a hurried build gave numbers that did not match finance.
The result: Up to three reporting tables are built as tested models or views from your written spec in a pull request, each reconciling to control totals you sign off, with tests for keys, nulls and joins. Your team reviews and merges, and we touch nothing in production.
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 models or views
- The tests
- The reconciliation table against your control totals
- Short documentation of each table
- Run steps
Included
- Up to three tables defined in a written spec you supply
- dbt models or SQL views with tests for unique keys, not-null columns and join fan-out
- Reconciliation of each table to control totals you supply
- Work on a masked read-only clone and a private branch
- A pull request, short documentation and run steps
Not included
- Deciding what a number should mean
- Access to production data or deployment
- More than three tables without a larger quote
- Dashboards
- Personal data columns
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each table reconciles to the control total you supply, within the tolerance you set in writing.
Evidence: The reconciliation table.
Tests for unique keys, not-null columns and join fan-out exist for every table and pass on the clone.
Evidence: The test list and run output.
Three input rows that you change on a second snapshot, without telling us which, move each table by an amount you compute yourself.
Evidence: The three changes and your computed amounts beside the table movements.
The pull request touches only the agreed model paths.
Evidence: The diff list.
Sign-off. Your named person signs the control totals and your reviewer merges the pull request. Payment follows sign-off.
If it fails. If a table does not reconcile to its control total within your tolerance, it is reported as failed with the difference, and that table's share of the quoted price is not due (the quote shows each table's share). 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
- A written spec for each table, agreed by your stakeholders
- Control totals you trust for each table, signed by a named person
- A masked read-only clone and a private repository branch
- A reviewer on your side who merges
We stop and tell you if
- The spec is disputed or changes during the build
- No control totals exist to check against
- Only production data is available
- Personal columns cannot be masked
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 |
|---|---|
| The tables run but the numbers are wrong. | Each table must reconcile to a control total within the tolerance you set in writing. A table that does not is reported as failed. |
| A join multiplies rows and inflates a total. | A fan-out test is written for every join and must pass. |
| Warehouse access exposes personal data. | Work is on a masked read-only clone, reached by a secure route after agreement. |
A separate automated reviewer checks the models, the tests and the reconciliation before hand-over. Your named reviewer signs off the reconciliation and merges the pull request. 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 spec, the control totals, the tolerance and the severe errors
- Receive the masked clone and the private branch
- Write the models or views with key, null and join tests
- Reconcile each table to its control total on the clone
- Independent review of the models, tests and reconciliation
- Hand over the pull request; 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 more tables built from further specs? Each batch is quoted separately.
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
- dbt Copilot can draft models and tests if you use the dbt platform. This job adds the reconciliation to your control totals and an independent review. docs.getdbt.com
- Our engineering lane can build and maintain data models as part of a wider backlog. syntheticindustry.ai
Questions
Who decides what the numbers mean?
Your stakeholders, in the spec. We build to it and prove it against your totals.
Do you deploy the models?
No. Your team reviews and merges the pull request.
What if the totals do not reconcile?
The table is reported as failed with the difference, and that table's share of the price is not due.
Send an enquiry
Send us
- The three tables in a sentence each
- The tool that holds the data (dbt, plain SQL) and how big it is
- No real records, personal data or credentials in the first enquiry
Later, once you agree
- A written spec for each table
- A masked read-only clone and a private branch by an agreed secure route
- Control totals signed by a named person
- A written cap on model usage
You keep your warehouse and your repository. We work on a masked read-only clone and a private branch, return a pull request for you to review and merge, and delete our copies when the job ends. We have no production access.
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 “dbt-models-built-from-your-spec-and-proven-against-totals” as the subject.