Decisions
Intelligence and decision layers
The layer between the data a company has and the decisions it makes. Built to support judgement, not to automate it away — and instrumented so that when it is wrong, you find out.
There are dashboards and nobody opens them.
Numbers are argued about in meetings because two systems disagree.
Problems are noticed by customers before they are noticed internally.
Someone exports to Excel before every decision, and that export is the real reporting layer.
- 01
One definition per metric
Revenue, active customer, churn — defined once, computed once, used everywhere. Most reporting disputes are definition disputes wearing a data costume.
- 02
Anomaly and pattern detection
Detecting the structural change rather than the noise, and surfacing it to a person with enough context to act. An alert nobody can act on is a cost.
- 03
Decision support, not replacement
Models that narrow the options and show their reasoning. Where a decision is consequential, a person makes it and the system tells them what it thinks and why.
- 04
Reporting built for the operator
Designed around the decision a specific person makes on a specific rhythm. If the daily view answers a quarterly question, it will not be opened twice.
- 01
A metric layer with single, documented definitions
- 02
Operational reporting aimed at named decisions and named people
- 03
Anomaly detection with routing and thresholds you can tune
- 04
A reconciliation between the analytics layer and the accounts
Invariant
A metric with two definitions has none.
- Do we need a data warehouse first?
- Often not. Companies underestimate how far a well-defined metric layer over the operational database goes, and overestimate how much a warehouse solves on its own.
- Will this replace our analyst?
- No, and that is deliberate. It removes the reconciliation work analysts spend most of their time on, which is not the same thing.
- How large can the data be?
- Our own research work resolves transaction graphs of fifteen million rows in under two minutes on ordinary hardware. Scale is rarely the limiting factor; definition is.
Each one carries what it is good for, what it is proven on here, and the point at which it stops working. We take no vendor commissions on any of them.
- PostgreSQL
- A relational database with real transactions: either every part of a change lands or none of it does.
- Retrieval-augmented generation
- Answering from a body of documents the model retrieves at question time, rather than from what it absorbed in training.
- TypeScript
- A typed layer over JavaScript: shapes are checked when the code is compiled, and erased before it runs.
- Python
- A general-purpose language whose value in this practice is narrow and specific: the reference implementations for reading and writing awkward archive and binary formats — .docx, .xlsx internals, font tables — are written in it.
- Playwright
- A Node library that launches and drives Chromium, Firefox and WebKit through one API — written for end-to-end tests, equally usable as a scriptable browser.
- Model Context Protocol
- An open protocol that lets an assistant call tools and read live data directly, instead of being handed an excerpt somebody pasted.
- SQL
- The language a relational database is actually configured in — tables, constraints, indexes and access policies.
The one that comes back to the table every quarter with the same two positions and no new information. That is a measurement problem wearing a strategy costume, and the first meeting is about what would have to be true for the argument to end.