Rebuilding Data Trust as an Operating Discipline

The Headache

Tuesday, 2:14 AM. The Sales semantic model refresh fails. Cause: a source system timeout.

Scenario A. The BI team catches it at 8:00 AM, rolls it back, and gets a clean refresh running by 10:00. Nobody outside the team is told. By noon, the VP of Sales has already opened the dashboard, noticed the numbers looked stale compared to what she saw yesterday, decided the dashboard was broken again, and pulled up her own tracker. She notes internally that this is the third time this quarter. She stops opening the dashboard for the rest of the week.

Scenario B. At 8:05 AM, an automated notice publishes to a designated Teams channel: “Sales semantic model refresh failed at 2:14 AM. Cause: source system timeout. ETA to resolution: 10:00 AM. Current data as of Monday 8:00 PM. Follow-up notice at resolution.” The VP of Sales sees it at 8:30, adjusts her morning expectations, checks back at 10:15 for the resolution notice, and moves on with her day. She trusts the dashboard slightly more than she did yesterday, not less.

Same failure. Opposite trust outcome. The difference is not technical. The difference is that in Scenario B, the team is running a communication rhythm as an operational discipline.

Issue Four diagnosed the six signs of eroded trust and the operating-model causes behind them. This issue is the design. If you have not read Issue Four, you can, but the short version is this: trust does not erode because the data is wrong. Trust erodes because the operating model around the data is silent. Everything below is about how to stop being silent.

The Blueprint: Three Operating Disciplines That Restore Trust

We build these into every trust engagement in the same order, because they compound. Freshness transparency creates the surface. The single-answer rule prevents definitional drift on top of that surface. The communication rhythm sustains both over time. Skip any one and the other two lose most of their value.

1. The Freshness Contract

Every certified dashboard should tell the consumer three things without them having to click anything: when the data was last refreshed, what the target refresh cadence is, and whether there are any currently known issues. In our engagements we build this as a standardized header component that lives on every certified report, pulling from the platform’s monitoring layer. Three pieces of information, non-negotiable. When they are absent, the consumer’s default assumption is uncertainty, and uncertainty compounds into distrust faster than any actual failure would.

The known-issues layer is where most teams under-invest. The instinct is to hide problems until they are resolved. That instinct is wrong. The most trusted operational tools in software (status pages from Datadog, GitHub, Stripe) are trusted precisely because they publish incidents transparently and immediately, then update the resolution status until closed. The counterintuitive lesson: publishing failures builds more trust than hiding them, because the consumer learns that they don’t have to be their own monitoring system. The commitment we ask clients to make is that every material issue is published to a defined status channel within four hours of detection, with an ETA and daily updates until closed. Material means anything that would meaningfully change a decision. A cosmetic bug is not material. A missed refresh on a certified model absolutely is.

2. The Single-Answer Rule

“Which number is right” is almost never a data problem. It is a definitional problem. Finance and operations both have defensible numbers because they are answering slightly different questions with slightly different definitions. The trust-restoring move is not to declare one of them the winner. It is to acknowledge that both are correct within their context and to specify which context wins for which decision.

The pattern we implement is a measure definition registry: a single, versioned document (typically a wiki, sometimes a git repo, occasionally just a well-maintained spreadsheet) where every KPI that appears in a board deck or executive dashboard has one canonical name, one plain-English definition, one technical definition (the DAX or SQL), one designated human owner, and a specification of which decision contexts it applies to.

The naming rule matters most. Refuse to have a single unqualified metric name. “Revenue” alone is a trap. “Revenue (Booked),” “Revenue (Billed),” and “Revenue (GAAP Recognized)” are three different measures with three different owners, and the registry says so. When someone says “revenue” without a qualifier in a board deck, the executive sponsor’s job is to ask “which one.” The answer must resolve to the registry, not to whoever spoke first with confidence. The escalation rule closes the loop: when a disagreement surfaces, the designated executive decides in writing, and the decision is added to the registry with reasoning so future disagreements about the same measure are resolved by reference rather than re-litigated.

3. The Communication Rhythm

Trust does not persist. It has to be maintained by a rhythm of communication that is predictable, boring, and inviolable. Four cadences.

Weekly, a platform health summary to executive sponsors and BI power users. Uptime, refresh success rate, current known issues, changes shipped. Five bullets. Five minutes to read. The value is not the information (usually unremarkable). The value is that it exists at the same time every week, whether there is news or not.

Monthly, a consumer-facing changelog. What changed in certified reports, what new measures were added, what got deprecated. Distributed to every consumer of certified content. The rule: any change to a certified measure that could shift a decision appears here before the change ships, not after.

Quarterly, a structured trust check-in with executive sponsors, which is essentially the six-symptom diagnostic from Issue Four run again. Are executives arriving at meetings with their own spreadsheets? Are reports going unopened? Track it. Trend it. Correct it.

Ad hoc, incident communications with defined SLAs. Initial notice within one hour of detection. Resolution notice within one hour of resolution. Root cause within one week. The SLA does not exist to be met perfectly. It exists so consumers know what to expect. All four cadences publish to one designated channel (typically a Teams channel called something like “Platform Status” that is pinned in the executive team’s Teams client). Not scattered across email, Slack, and DMs. Consumers should have exactly one place to look, and that place should be reliably worth looking at.

The Gotcha

Most teams read the above, estimate the setup cost, and decide the ongoing maintenance is too expensive. They stand up the freshness header, publish the registry, run the weekly summary for six weeks, and then it lapses. A rhythm that isn’t reliable is worth nothing. We now insist, in every trust engagement, that maintenance of the rhythm becomes a defined role, not an “everyone’s responsibility” arrangement. Typically it is 5 to 10 percent of one BI team member’s time, formally assigned, with a named backup. If nobody owns the rhythm, the rhythm dies, and trust erodes right back to baseline within two quarters. We have seen this specific decay happen enough times that we now treat the named-owner assignment as a non-negotiable output of the workshop.

The Reddit Reality Check

A recurring thread, paraphrased: a BI lead complains that their team is constantly blamed for data quality issues that turn out to be upstream or definitional. The community response tends toward “get better data quality tooling” or “push back harder on ownership boundaries.”

The reality is that the issue is almost never the data quality itself. It is that when problems occur (as they always do), consumers do not hear about them from the platform team. They discover them themselves. That is where the blame comes from. The trust-restoring move is not to eliminate problems, which is impossible. It is to make the platform team the source of truth about the state of the platform, which is a communication problem, not a data quality one. Teams that get this right are still blamed occasionally, but they are blamed less, and the blame lands with different weight when the consumer already knows the team is transparent about failures.

What We’re Watching

Copilot-generated auto-summaries for semantic models are now live in the OneLake catalog. Model owners and contributors can generate a plain-English summary of a semantic model’s purpose and characteristics, review and edit it, and publish it as part of the model’s discoverability metadata. This is directly relevant to the trust theme because it lowers the cost of one of the most under-invested trust surfaces: the “what is this thing for” question that every consumer implicitly asks when they encounter a new dashboard.

The wince-worthy caveat: an AI-generated summary is only as good as the underlying metadata it is drawing from. A semantic model with descriptive measure names, well-documented tables, and thoughtful column descriptions will summarize well. A semantic model where the measures are named “Measure1” and “Sales_Final_v4” will produce a summary that reads like a hostage note. The feature accelerates trust for well-documented models and accelerates distrust for undocumented ones. Fix the metadata before you generate the summary, or don’t publish the summary until you have.

One question for the comments:

What is your current platform status cadence? Weekly? Monthly? Only when things break? Never? Honest answers get honest sympathy.

The Strategist’s Corner

If reading through the three disciplines above made you realize your organization is running roughly zero of them consistently, you are in the majority. We deliver these as an Adoption and Trust Workshop: a structured half-day session with your BI team, executive sponsor, and a small group of key consumers, ending with the freshness contract drafted, the top ten board-deck measures added to a starter registry, the communication rhythm calendar populated, and the named owner assigned before anyone leaves the room. The follow-on engagement implements the rhythm inside your Fabric tenant and hands over ongoing operation to your team within one quarter. Book a 30-minute scoping call →

Issue Six moves into the next arc of Season Two: managed self-service and the build-rights question. Once trust is stable and the platform is transparent, who is actually allowed to build on top of it? The enablement model, the specific rule for what a business analyst can produce without central-team involvement, and the operating agreement that makes “yes, with conditions” the default answer instead of “no, by policy.”

Measure Twice. #5: Originally Posted on LinkedIn, July 8, 2026