Engagement · Rebuild (scope-priced)
Two Warehouses, One Definition
“We acquired a company. Make the numbers agree.”
Two warehouses, two definitions of every metric, and a board asking which number is right. We read both, surface every conflict with its lineage, and build one reconciled model set.
In scope:
- Both warehouses read
- Every conflicting metric definition surfaced, each with the lineage that produced it
- A recommendation for each conflict, with the reasoning written down
- One reconciled set of models, run against the target warehouse
What we need
- Read access to both warehouses
- A decision-maker who can rule on which definition wins
How long
Out of scope:
- Owning the business decision about which definition is correct. We surface conflicts and recommend; you rule
- Anything outside the metrics named in the agreement
- Org or ownership changes implied by the answer
What we mean when we say tested.
We generate the models, run them against your Snowflake or Athena connection, and check that each one returns rows, that its primary key is unique, that no column comes back completely empty, and that the types are what we said they'd be. On top of that we run dbt's own generic tests — not-null, unique, accepted values, and foreign keys against their parent — and hand you the schema.yml for them, so the tests we ran are tests you keep. Where a test can't be evaluated soundly it comes back marked skipped, never passed. We don't run a full dbt build, and we don't compare your old numbers against the new ones row by row. If a figure has to reconcile exactly, that's a conversation for the call.
Scope the engagement in thirty minutes.
Bring the domain that causes the most difficulty. If it turns out this is not the right engagement for you, we will say so and point at the one that is.