The pipeline ran green. The numbers are still wrong.

Find out why the numbers are wrong

A total moved and nobody knows why, or a report disagrees with the system it reads from. I trace it to the model and the rows, fix the cause, and add the test that fails the build next time.

Take over or extend a dbt project

Staging and dimensional models, tests that fail the build rather than decorate it, linting that holds across a team, and documentation in the same pull request as the model.

Add a market or a source without a fork

A new country or system comes in through the same staging layer and lands in the same core models, so there is still one place to fix any number.

Revenue comes in short, and every test passes

The build is green. A surrogate key arrives empty on a slice of rows, the join silently drops them, and the revenue number is quietly low.

I trace it back to the staging model, fix the key, and add the test that would have caught it.

A rerun doubles the numbers instead of repairing them

An incremental model without a reliable unique key does not heal when you run it again. It doubles. The table looks fine until someone sums it.

I fix the key strategy so a rerun is safe, which is the property you wanted from incremental in the first place.

Customer names arrive garbled in a report

An encoding mismatch between the source and the warehouse turns an apostrophe into three characters of noise. Nothing errors. It reaches a customer facing report weeks later.

I find the boundary where the encoding breaks and fix it there, not in the report.

Old numbers sit next to live ones

A source system gets switched off. Nobody removes its models, so they keep building from a table that stopped updating, and stale rows sit beside live ones with nothing to tell them apart.

I cut the dead lineage out rather than leave it to fail quietly.

34

dbt models, two markets

A retail business operating in two countries needed one analytics warehouse. The countries named categories differently, and the second market had to come in without forking the project.

I built the staging layer, covering products, categories, shops, terminals, transactions and cart items, then the dimensional models on top of it. I brought the second market into the core models, used fuzzy matching to reconcile category ids across the two countries, and added a Step Function trigger for the shared product catalog.

Both markets run on the same core models, so a fix lands once. The models ship with tests that fail the build.

573

commits on a genotype data system

A livestock genomics data platform was replacing a legacy ingestion process. Illumina IDAT files had to be detected, linked to metadata, checked for authorisation, loaded as genotypes, then checked for discordance against other samples from the same animal.

I built the sample QA framework, including the manual override path and the checks that run before a flag is allowed to change. I added the discordance trigger, wrapped the job in a transaction, and chained parentage verification off it.

The discordance job runs from a trigger inside one transaction, so a failure does not leave half a result, and parentage verification follows from it. Every manual override leaves an audit record of who made it and why.