Data & AI Technical Review
A technical review of your data platform, without access to your data
We analyse your dbt project and build artefacts, and report what is wrong with them. Each finding names the asset, the file, the evidence and the owner.
We do not connect to your warehouse, read production data or clone your repository.
- Critical
not_null_fct_orders_customer_idtestmodels/marts/schema.yml
The test not_null_fct_orders_customer_id is failing on 1,284 rows.
Fix: Fix the data or retire the assertion — a permanently failing test trains the team to ignore the suite.
- Critical
stripe.chargessourcemodels/staging/_sources.yml
Source stripe.charges was past its error threshold when freshness was last measured, 19 hours old.
Fix: Trace the loader behind this source; a freshness breach is an ingestion failure, not a dbt one.
- High
int_orders_enrichedmodelmodels/intermediate/int_orders_enriched.sql
int_orders_enriched reads a schema-qualified relation directly rather than through ref()/source().
Fix: Replace the literal relation with ref(), or declare it as a source and use source().
- Medium
fct_ordersmodelmodels/marts/fct_orders.sql
fct_orders declares no owner, while this project owns others via dbt groups.
Fix: Put fct_orders in a group, or set the meta key this project already uses.
- Medium
acme/analyticsrepositoryNo CI configuration was found for any of the common providers.
Fix: Add a pipeline that at minimum installs, builds and runs the test suite on every pull request.
- Low
stg_paymentsmodelmodels/staging/stg_payments.sql
stg_payments has no description.
Fix: Add a description to the model's schema YAML.
Deliverables
-
Report
A PDF with the summary first and the evidence behind it. Each area is scored, and each score states what it rests on.
-
Worklist
A CSV with one row per finding: asset, file, evidence, recommendation and owner, so the work can be assigned.
-
Portal
A page on this site you sign in to with a magic link. Every finding in one table, filterable by model, check or owner.
What we look for
Fifteen areas, and what we check in each.
-
Metric consistency
Duplicated model logic, relations that bypass
ref(), models with no asserted grain, and YAML columns the warehouse does not have. -
Build reliability
Failing tests and errored models from the last run, and the models each failure blocked.
-
Source freshness
Sources past their freshness threshold, and sources with no freshness check configured.
-
Build performance
Models taking the largest share of build time, full rebuilds on every run, and tests costing more than the asset they check.
-
Change risk
Deep lineage, models everything else depends on, models with no contract, and whether the models that change most are the tested ones.
-
Documentation
Models, columns and sources without a description, and the share of the project that represents.
-
Ownership
Models, sources and exposures with no group, no
metaowner and no reachable contact. -
Actual usage
Which models anyone queries, how many people read each one, and which tables take the largest share of warehouse scans.
-
Governance readiness
Whether CI and CODEOWNERS exist, how concentrated contribution is, and credential files committed to the repository.
-
AI lifecycle
Unpinned model libraries, no record of which run produced which model, output nobody evaluates, and notebooks committed with their outputs.
-
Orchestration
Scheduled jobs with no owner, retry or failure alert, and which dashboards depend on a job that would fail without telling anyone.
-
BI semantic layer
Measures naming columns that do not exist, untested join keys, and Looker, Power BI or Tableau models reading tables your pipeline does not build.
-
Metric definitions
The same measure defined differently across Looker, Power BI, Tableau and dbt metrics, and joins that inflate a Looker total.
-
SQL without dbt
Lineage rebuilt from plain SQL files: cycles, tables with two writers, queries selecting every column, duplicated files and untested tables.
-
Platform and lineage
Terraform grants broader than the job needs, public buckets, warehouses that never suspend, and jobs whose last recorded run failed.
Methodology
Checks are implemented as rules over your project's files and artefacts rather than generated by an LLM. Every check reports whether it ran, and a check with no evidence is recorded as unknown rather than as a pass.
Each area is scored separately, and each score states how many checks and entities it rests on. Where a check matches a published rule — dbt Labs' dbt_project_evaluator, OpenSSF Scorecard — we name the rule and how closely it corresponds.
Inputs
All of these are output your team already generates. We need the first row. Each further artefact adds what a manifest alone cannot answer.
| Artefact | How you get it | What it adds |
|---|---|---|
manifest.json | dbt parse, or any build — already in target/ | Testing, documentation, lineage, modelling, ownership, the dbt semantic layer |
run_results.json | Sits beside it after dbt build | What the last build did, plus per-model build times |
sources.json | dbt source freshness | Whether upstream sources are arriving on time |
catalog.json | dbt docs generate | Where the YAML and the warehouse disagree, plus table sizes and row counts |
| A read-only GitHub token | Fine-grained and read-only. A private repository needs Contents as well as Metadata to list its files; we open only named config files | CI, contributor concentration, CODEOWNERS |
| Your change history | One git command you run yourself — commit dates and file paths only, no names or messages | Which models change most often, and whether those are the tested ones |
| Your LookML project | A copy of the .lkml files. Measure SQL is reduced to a fingerprint | Whether dashboards read the models dbt builds, and whether their joins count correctly |
| A project folder | Picked in your browser and read there: SQL, Power BI, Tableau, Terraform, Airflow and Dagster files | Lineage without dbt, one measure defined several ways, broad grants, jobs behind dashboards |
| OpenLineage events | An export from Marquez or your lineage backend | What actually ran, which jobs failed, and which tables two jobs write |
| Warehouse query history | A read-only query you run yourself — no credential | Which models anyone actually reads, and what scans the most |
| Warehouse credentials | Optional, never required | Nothing the query above does not already give us |
Upload what you have. A review can start from the manifest, or from a project folder alone.
Security and data handling
We read named dbt artefacts and repository metadata through a read-only token. No rows, no query results, and no clone.
A project folder is read in your browser and never sent. We receive the findings only. Measure definitions in SQL, LookML, DAX or Tableau are reduced to fingerprints, unless you ask to see them side by side.
profiles.yml is excluded from collection because it may contain warehouse credentials.
The analysis runs with no LLM calls and produces the full report on its own. An optional interpretive pass sends a digest — check ids, severities, counts, example asset names — to a third-party provider. It is off unless you ask for it, owner names and email addresses are excluded, and the report records what was sent.
Limitations
- Your data. We never read a row. From
catalog.jsonwe read the warehouse's statistics about each relation to report the largest tables and whether anything in the project declares a reader for them. Query performance and cost are out of scope. - Your source code. Through the token we read repository metadata, dbt config files and your dependency manifest. A project folder you pick is read in your browser. We never open a notebook, and retain nothing we read.
- Behaviour outside the files. How your scheduled jobs have actually run needs the scheduler's own history, and which dashboards people open lives in Looker. Both are out of scope. Looker views are linked to tables, not fields to columns.
- Ownership held elsewhere. If owners live in a rota rather than in dbt groups or
meta, we report those assets as unowned. That describes the project metadata, not your team. - Remediation. We produce the report and the worklist. Carrying the work out is a separate scope — ask if you want both.
Pricing
£2,000 for a review of one dbt project and its repository. That covers the analysis, a person going through every finding, the report, the worklist and a readout with your team. For a larger estate — several projects, or LookML and orchestration on top — we agree the scope and the price with you before any work starts.
£500 for a reassessment once your team has made changes: we run the same inputs again, confirm what is fixed and report anything new.
We invoice after scoping. There is no subscription and no sales call needed to find out the price.
Frequently asked questions
How long does it take, and what do we need to do?
Upload the artefacts to your portal and answer a few questions about what the platform is for. Each file is read and discarded in the same request — we keep the findings and a checksum, not your file. The checks then run over every model, source and test in the project, not a sample. A person reviews each finding, cuts the ones that do not warrant your time, and writes the report. Most reviews are back within a week.
Can we compare the score to another review?
To an earlier review of your own project, yes — the report names the check-suite version it ran, and we say when a version change makes two scores incomparable. Not to another company, and not to a standard. Where a check matches a published rule we name it and say how closely.
Who can see the findings?
You do. Findings are held per client with database-level isolation. The portal has no signup, access is by invitation to named addresses, and we can withdraw it at any time with immediate effect.
We already run dbt_project_evaluator. What does this add?
Execution and ownership, mostly. dbt_project_evaluator checks what the project declares; we also read what the last build did, who each asset routes to, and how the repository is maintained. If your models are already tested, documented and owned, say so when you get in touch and we will tell you whether a review is worth it.
Request a review
Send us a short description of your stack. We will confirm whether the review fits, and come back with a scope and a price.