The number arrives with its reasons attached
Lakeview and Power BI outputs generated from the same model, so a figure on a page can still name the claim it answers, the control that held it and the requirement that asked for it.
A report rebuilt a third time in DAX, because the warehouse number and the report number never matched and nobody could say which was right.
The visual layer is generated from the same model as the tables, so there is no third implementation to disagree with.
The last translation in a traditional stack is the most expensive one: the logic gets re-implemented in the reporting tool, because that is where the deadline lands. From then on there are two definitions of the same measure and no way to adjudicate between them without a person who remembers both.
Generating the visual layer from the model removes the second implementation rather than reconciling it. The metric on the page and the metric in the warehouse are the same statement rendered twice.
What that buys is not prettier dashboards. It is the ability to answer “why is this number what it is?” without a forensic exercise: the claim it answers, the exclusions applied, the control that held last night, and the person who ruled on the grain, all still attached.
Databricks and Power BI, natively
Lakeview from the model, and Power BI as .pbip in source format so it lives in your repository like everything else. Fabric is on the roadmap.
Provenance travels with the figure
The chain from requirement to claim to control to verdict is not a document about the dashboard. It is reachable from the dashboard.
Seeded runs are labelled as seeded
A number produced from generated sample data says so, everywhere it appears, so it can never be screenshotted into a steering pack as if it were real.