Explainer / 2026-10-04
What a measure needs before anyone should trust it
A short progression from a number on a dashboard to a definition someone can defend.
Executive
A number is not a decision
A measure is trustworthy enough to act on when you can say what it counts, what it excludes, over what period, and which decision it is for. If two reports share a name and not a definition, you do not have two estimates. You have two facts.
The useful first question in a meeting is not "is the trend up?" It is "up under which rule?"
Practitioner
The minimum definition
Before a visual is chosen, write six things in words an operator and an analyst will both sign.
- Decision, what action this measure is allowed to influence.
- Grain, the thing one row represents: a claim, a charge line, a visit, a day.
- Clock, the timestamp that starts and ends the window, and what happens to events still open.
- Inclusions and exclusions, including the cases people will argue about.
- Owner, who may change the definition, and how everyone else hears about it.
- Failure mode, the plausible way this number goes wrong even when the query runs.
View a teaching example
This example is constructed for teaching. It is not a client result and it contains no performance figures.
Two denial reports circulate in a specialty practice. One counts claims that carry a denial code on the remittance. The other counts charge lines sitting in a denial status in the practice-management system. Both authors can defend their query. The reports still should not be plotted on one axis. One is a payer response. The other is a workflow state. A claim can be in one and not the other.
The finding is not "denials got worse." The finding is "these reports are not comparable until we pick the decision we are actually in." If the decision is how payers are adjudicating, the remittance definition is the one to keep, and the other chart needs a different name.
Technical
Where the definition hides
In a warehouse or a semantic model, the definition is a sequence of choices: which source table, which status codes, which join, which filter on voided or adjusted rows, which date, which aggregation. Two queries can both be syntactically valid and still implement different measures. Lineage is the written path from source field to the sentence someone says in a meeting.
A semantic model helps when it makes those choices visible and reusable. It does not help when the ambiguity moves into an unnamed calculated column. Power BI, SQL, and a spreadsheet are the same problem at different levels of inspectability.
Show the mechanics
Ask for the grain of the fact table before arguing about the visual. If one path is at claim grain and the other is at charge-line grain, a sum will not mean the same thing even when every join key matches.
Then ask which clock. Service date, posting date, and remittance date answer different operational questions. Mixing them inside one trend is a modeling error, not a formatting error.
Then read the filter. Excluding still-open claims will make a recent period look artificially settled. Including them will make it look artificially bad. Both can be honest if the label says which one you did.
Technical detail
A practical test: hand the definition to a second person and ask them to recompute one period without looking at your file. If they cannot get the same count, the measure is not ready for a dashboard. The miss will be a status code, a join fan-out, or a date. Those are the defects worth fixing. The color of the bar is not.
I do not publish client SQL here. The standard does not require a particular engine.
What matters
Trust comes from a definition you can recompute, not from the confidence of the person presenting the chart.