Metric dictionary
Each measure defined once with its filters, time basis, and exclusions, published where anyone can read it.
Solution
BI Dashboards and Reporting
Agreed metric definitions, modelled tables and a small number of views tied to decisions, so a meeting argues about the action rather than the number.
Overview
What the system does
Reporting is a definition problem wearing a visualisation costume. When two departments quote different revenue figures, no chart library fixes it.
We start by writing definitions, build the model that produces them consistently, then create the smallest set of views that change what someone does.
The result is fewer dashboards than most organisations expect and considerably more trust in them.
Who needs this
Managers reconciling several systems before they can answer an operational question.
What we build
Start with a metric definition and its source records. Choose extraction cadence, join keys and handling for corrections. A dashboard should show data freshness and incomplete feeds rather than present every number as current.
Modules
Core modules
Source connections
Incremental extraction from operational databases, software platforms and files, with checkpoints and retry handling.
Modelled tables
Raw, cleaned and presentation layers, with conformed dimensions for customer, product, location and date.
History handling
Point in time reporting where the business needs to see what was true then, not only what is true now.
Quality gates
Freshness, row count, null rate and referential checks that block publication rather than publishing a wrong number quietly.
Dashboards
Executive summary, operational views for each team, and exception reports that only appear when something needs attention.
Scheduled distribution
Reports delivered by email on a schedule for people who will never log in, with the same numbers as the dashboard.
Self service layer
Documented tables, saved queries and a data dictionary so new questions do not require a project.
Architecture
How it fits together
A typical implementation flow, with explicit responsibilities at each boundary.
Integrations
- Operational PostgreSQL databases and read replicas
- Software platforms with reporting APIs
- Accounting systems
- Advertising and analytics platforms
- Spreadsheet and file sources
- Existing business intelligence tools over the modelled tables
- 01
Extract
Load source changes with a watermark and retained lineage.
- 02
Model
Apply tested definitions, dimensions and reconciliation checks.
- 03
Explain
Expose reports with drill-through records and visible freshness.
Security and controls
Design for the exceptions, not just the happy path.
Restrict row and column visibility by role. Minimize personal data in reporting stores and protect exports. A BI account should not inherit operational write permissions.
Technology options
We select the final stack after reviewing your existing systems and operating requirements.
Security and IP practicesFit
Industries that use this
FAQ
Questions people actually ask
How many dashboards should we have?
Fewer than you think. One executive view, one per operational team, and a set of exception reports that stay silent when things are fine. Anything nobody acts on is maintenance cost.
Can we keep our current reporting tool?
Yes. The modelled tables are the deliverable and any tool that speaks SQL can read them, which also means changing tool later is not a rebuild.
How do we stop two teams quoting different numbers?
One definition per metric, computed in the model rather than in each report. If a team needs a variant, it becomes a separate named metric with its own definition.
What if a source system changes?
The quality gates catch it, usually as a null rate or referential failure, and the load stops before the wrong figure reaches a dashboard.
Can we see history as it was reported at the time?
Yes, where the business needs it. Point in time modelling is a design decision because it changes the table structure, so we agree it early.
Do we need a large warehouse platform?
Usually not. At moderate volume, managed PostgreSQL with modelled tables is cheaper, simpler and fast enough. We size it against your real data.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.