One model ofthe truth.
Pipelines, warehouse modelling and reporting that reconcile. We start from the decisions a team needs to make, work backwards to the metrics that inform them, and only then to the tables underneath.
- X
- LineageWhere a number came from, and what derived it.
- Y
- MeaningWhat it is supposed to represent, and who owns that.
Reporting projects fail at the top of the ladder, not the bottom.
The tables are rarely the hard part. What breaks a data project is starting there: modelling whatever the source system happens to emit, and discovering afterwards that nobody agreed what the numbers were supposed to mean.
So we work upward. Which decision, made by whom, how often. Then the metric that informs it, written down with its edge cases and an owner. Only then the model, and only then the tables.
- 01Decisionwho chooses, how often
- 02Metricdefined, owned, written down
- 03Modelentities, grain, history
- 04Tablethe last thing designed
Read upward — the table is derived, not assumed
- 01
Ingestion
sources, as they are
- 02
Pipelines
scheduled, observable
- 03
Transformation
tested, versioned
- 04
Models
entities and metrics
- 05
Insight
a decision someone makes
- 01
Two dashboards, two answers
Almost always a definition problem rather than a query problem. The fix is a written metric definition with an owner, and then the model that enforces it.
- 02
A simple question takes a week
When every answer needs an analyst to join four exports by hand, the bottleneck is the model, not the people.
- 03
Nobody owns the definition
Active customer means three different things in three teams. Naming that, in public, is often the highest-value hour of the engagement.
- 04
The report exists; the decision does not
Reporting built without a decision attached becomes wallpaper. We start from the choice being made, and stop when it can be made.
- D1
Ingestion you can trust
Scheduled extraction from the systems you already run, with schema changes surfaced rather than silently absorbed.
- Source connectors
- Incremental loads
- Schema drift alerts
- Replay
- D2
Warehouse modelling
Entities, grain and history modelled deliberately, so a join cannot quietly double a number.
- Dimensional models
- Slowly changing history
- Tests on transforms
- Documentation
- D3
A semantic layer
Metric definitions written once and reused everywhere, so every tool asking the same question gets the same answer.
- Metric definitions
- Ownership
- Version control
- Reconciliation checks
- D4
Reporting people use
Fewer dashboards, each answering a named question, with the definition and the freshness visible on the page.
- Decision-first layout
- Freshness indicators
- Drill-through
- Access control
- 01
Start from the decision
Which choice is being made, by whom, how often. Everything downstream is derived from that answer.
- 02
Define the metrics in writing
Including the edge cases: refunds, cancellations, timezones, the customer who is also a supplier.
- 03
Model, then move
The shape of the warehouse is settled before pipelines are built, so pipelines are not rewritten to fit a late model.
- 04
Reconcile out loud
New numbers are compared against the old ones, and every difference is explained before the old report is retired.
- L1Storage
- PostgreSQLWarehousesColumnar storesPartitioning
- L2Movement
- ELT pipelinesBatch and incrementalOrchestrationReplay
- L3Modelling
- Dimensional designSQL transformsTestsLineage
- L4Delivery
- Semantic layersReportingEmbedded analyticsExports
Bring the two reports that disagree.
Send the numbers nobody can reconcile, and the decision they are supposed to support. We will find where the definitions diverge and what it would take to have one answer.