The Analytics Platform Maturity Curve
The previous article, Designing for Unconditional Recovery, closed the Infrastructure track's coverage of resilience with a specific claim: that recovery has to be designed in from the start, not discovered during an incident. Before this series turns to its own close, it's worth pausing to do something it has never done in one place before — look back across every Data-track article published so far, not as nine separate lessons, but as one continuous argument about how an organization's relationship with its own data actually matures.
Stage Zero, Never Actually Covered
This series has never discussed spreadsheets, and it's worth admitting that plainly rather than forcing a citation where none exists. Every organization's data maturity technically starts with someone tracking numbers in a spreadsheet, and this series simply began one stage past that point — its first article opened with an organization that already had an operational database, already had a dashboard, and was already discovering that the two don't answer the same questions. The maturity curve's true starting point sits just outside everything this publication has covered. What the series actually documents is everything that happens after an organization outgrows the spreadsheet, which turns out to be most of the hard part.
Stage One: Static Reports
The first article in this series established the split between OLTP and OLAP — the observation that the schema optimized for running a business is structurally the wrong shape for explaining one, and that this is why data warehouses and medallion architectures (Bronze, Silver, Gold) exist at all. That article is this curve's Stage One in disguise: static reporting only became viable, at any real scale, once organizations accepted that reporting needed its own copy of the data, transformed and aggregated outside the path of live transactions. Before that separation, "reporting" meant running expensive analytical queries directly against the system of record, which is not a stage anyone can sustain past a modest scale.
Stage Two: Interactive Dashboards, and Where They Went Wrong Twice
The canonical business model article is this curve's Stage Two, told from the inside of its own failure. Interactive dashboards are what happens once static reports aren't enough — stakeholders want to slice, filter, and drill into numbers themselves rather than requesting a new report for every question. That article showed exactly what goes wrong at this stage when nobody intervenes: business logic migrates into Power Query transformations and DAX measures because the visualization tool is the only layer flexible enough to keep up with stakeholder demand, until nobody can say where a metric's definition actually lives anymore.
What makes Article 3 unusual in this framework is that it is simultaneously the failure that defines Stage Two and the fix that defines Stage Three. The dashboard absorbing business logic is Stage Two going wrong. The canonical business model that article proposes as the remedy — vendor-agnostic entities, a centralized transformation layer, definitions the business owns instead of definitions vendors happen to expose — is Stage Three's actual entry criteria. Most maturity-curve descriptions treat these as sequential stages an organization walks through cleanly. This series shows they're the same crisis, viewed from before and after the fix.
Stage Three: Semantic Models Are More Than Vendor-Agnostic Entities
A semantic model is not just "the canonical business model with a nicer name." Two other articles in this series belong here, and both address a dimension of semantic modeling the canonical-business-model article didn't have room to cover on its own. Cost of Generic Relationships argued that a semantic model's entities have to be explicit and typed — a generic EAV structure that can represent anything ends up representing nothing the query optimizer can reason about, which means "semantic" cannot mean "maximally flexible." It has to mean "explicitly, deliberately structured around the business's actual concepts."
History as a First-Class Feature adds the dimension a purely structural semantic model still lacks: time. A semantic model that only represents current state can answer "what is true now" and nothing about how the business got there — and Article 7 showed that the honest answer to "when did this change" is almost always "we didn't keep that," unless versioning was designed in from the start. A mature semantic layer is not just entity-centric. It's entity-centric and temporally aware, which is two separate architectural commitments that this series happened to cover as two separate articles.
Three more articles support Stage Three from underneath, without describing the semantic layer directly at all: The Hidden Cost of Moving Data, the cost of random UUID keys, and Modern Analytical Transport. None of these are about what a semantic model contains. All three are about whether a semantic model can actually be queried at the volume and speed a real organization needs — serialization taxes, B-Tree locality, and the ODBC bottleneck this series spent a full article resolving are the physical cost of ignoring what an elegant semantic model still has to pay for every time someone actually uses it.
Stage Four: Operational Intelligence
This is the stage most maturity-curve descriptions gesture at vaguely — "data-driven decision-making," "predictive analytics" — without saying precisely what distinguishes it from a very good dashboard. This series is more specific, because two of its articles drew the line directly. The Dashboard-First Anti-Pattern defined it structurally: a Gold table has earned Stage Four only when it serves a named organizational action — a workflow that fires, a decision someone is accountable for — rather than merely being queryable and pretty. That is the actual distinction between Stage Three and Stage Four: Stage Three produces trustworthy numbers a person looks at. Stage Four produces numbers a system acts on.
Spatial Intelligence is Stage Four's current frontier within this series specifically because it's the first Data-track article where the "action" being served isn't a dashboard-adjacent metric at all — it's a live operational process (route reconstruction, delay propagation) that has no meaningful tabular representation and required abandoning the relational join entirely for the geometry it was never built to handle.
A More Important Lesson
This article is not really about a five-stage maturity model. Plenty of those already exist, described in the abstract, in a slide deck, with no specific evidence behind any stage. What makes this version different is that every stage above is a citation, not an assertion — a claim this series already made, defended, and showed failing in a specific, concrete way, several chapters before this article ever connected it to a curve.
That's the thing worth taking from reading the Data track in order rather than as nine standalone pieces: the mistake most organizations make with this curve isn't misunderstanding the stages. It's assuming the stages are a technology roadmap — buy the semantic layer tool, buy the operational intelligence platform — when every article in this series showed the same thing happening instead: the stage fails not for lack of the right software, but for lack of the discipline the previous stage was supposed to have already installed.
Looking Ahead
The Infrastructure track has its own version of this same argument, made across ten different articles about circuit breakers, memory bounds, socket limits, backpressure, caching, and recovery — and it deserves the same treatment this article just gave the Data track: read together, not one at a time, as evidence for a single claim about when resilience actually has to be designed in. That is where this series closes.
End of Track 01. Proceed to Track 02: Stability Is an Architectural Core Constraint, Not a Post-Script Feature.