Minting Coins on Demand

Opening Scene

Most coins a mint produces are struck well in advance and held in reserve, ready to be distributed whenever they’re needed. But a mint capable of striking a coin on the spot, the instant a specific, perhaps unusual denomination is actually needed, offers a genuinely different kind of flexibility than relying purely on a fixed, pre-struck reserve. Both approaches have their place, and knowing which one a given situation actually calls for matters.

Precomputed versus on-demand metric calculation in a semantic layer presents this exact same tradeoff, and it’s a genuinely important architectural decision, not a minor implementation detail.

In Plain English

A semantic layer can serve a metric’s value in two broad ways: precomputed, where the value is calculated in advance and stored, ready for fast retrieval, or computed on demand, where the value is calculated fresh at query time, always reflecting the very latest underlying data. Precomputation trades some freshness for speed and lower cost; on-demand computation trades some speed and cost for guaranteed freshness. Neither is universally better — the right choice depends on the metric’s actual use case.

The Old Way

Many organizations defaulted to one approach uniformly across all their metrics — either precomputing everything for consistent performance, accepting some staleness as an unavoidable cost, or computing everything on demand for guaranteed freshness, accepting the performance and cost implications as simply the price of correctness.

This uniform approach meant some metrics were needlessly stale when genuine real-time freshness actually mattered for their use case, while others incurred unnecessary computational cost and latency being recalculated on demand when a periodically-refreshed, precomputed value would have served their actual use case just as well.

What’s Changing (and Why AI Is the Reason)

Modern semantic layer platforms increasingly support a genuine hybrid approach, choosing per metric based on actual need. Rather than a uniform, organization-wide default, mature platforms let each metric’s precomputation strategy be chosen based on its specific freshness requirements and query patterns, similar to the compute-storage separation flexibility covered for lakehouses elsewhere on this site.
AI-assisted usage analysis can inform which metrics genuinely benefit from precomputation versus on-demand calculation. Rather than guessing at a metric’s ideal caching strategy, AI-assisted analysis of actual query patterns, freshness sensitivity, and computational cost can recommend the genuinely appropriate approach for each specific metric.
AI-assisted adaptive caching can dynamically adjust a metric’s computation strategy based on changing usage patterns over time. Rather than a fixed, one-time decision, AI-assisted tooling can monitor how a metric’s actual usage evolves and adjust its precomputation strategy accordingly, keeping the tradeoff well-tuned as real-world conditions change rather than letting an initially sound decision go stale.

The Metaphor, Fully Extended

Mint Element	Precomputed vs. On-Demand Concept
Coins struck in advance and held in a ready reserve	Metric values precomputed and stored for fast retrieval
A mint striking a specific coin on the spot when needed	A metric value calculated fresh at query time
A kingdom uniformly choosing one approach for every denomination	An organization defaulting to one computation strategy across all metrics regardless of need
A treasury advisor recommending reserve levels based on actual demand patterns	AI-assisted usage analysis recommending precomputation strategy per metric
A mint adjusting its reserve strategy as trade patterns shift over time	AI-assisted adaptive caching adjusting computation strategy as usage patterns evolve

For Beginners: What to Actually Do

Practice distinguishing metrics that genuinely need real-time freshness (an operational alert threshold, for instance) from ones where a periodically-refreshed value serves the actual use case just as well (a monthly executive summary).
Get comfortable with the idea that precomputation versus on-demand calculation is a genuine tradeoff, not a case where one approach is simply, universally better.
When a metric feels slow to load or noticeably stale, consider explicitly whether its current computation strategy actually matches its real use case, rather than assuming the current setup must be correct.
Notice that this decision can and often should differ metric by metric, rather than being a single organization-wide default applied uniformly.

For Practitioners and Leaders: The Deeper Layer

Evaluate your semantic layer’s metrics individually for their genuine freshness requirements and query patterns, rather than applying one uniform precomputation strategy across the board.
Use AI-assisted usage analysis to inform per-metric decisions about precomputation versus on-demand calculation, grounding the choice in actual data rather than guesswork or historical default.
Use AI-assisted adaptive caching for metrics whose usage patterns genuinely shift over time, keeping the precomputation tradeoff well-tuned rather than letting an initially sound decision become outdated.
Track the cost and performance implications of your computation strategy choices explicitly, using that data to inform future architectural decisions as your semantic layer’s metric catalog grows.

Quick Recap

Semantic layers can serve metrics either precomputed (fast, potentially stale) or computed on demand (always fresh, higher cost and latency) — a genuine tradeoff rather than a universally correct choice.
Defaulting to one uniform approach across all metrics historically left some metrics needlessly stale and others unnecessarily costly to compute.
Modern semantic layer platforms support choosing per metric based on actual need, and AI-assisted usage analysis can inform which approach genuinely fits each specific metric.
AI-assisted adaptive caching keeps this tradeoff well-tuned over time as a metric’s real usage patterns evolve, rather than treating the initial decision as permanent.

Where This Fits in the Series

Article 16 covered the higher stakes of AI agents consuming metrics directly. This article covered a genuine architectural tradeoff in how metrics get computed. Article 18 looks at knowing when a transaction genuinely doesn’t need an official coin at all.