Data Quality Scoring, Sharing Advisory and Trust Snapshot Automation: The Warning Still Lets You Decide

A detailed list of data-quality issues is useful when you are actually fixing something, but it is the wrong format for the thirty seconds before a client call, when the question is simply "is this good enough to show right now." Collapsing many small signals into one defensible number is genuinely harder than just listing them — it requires deciding how much each kind of problem should count, and deciding a REAL question along the way: should the system actually stop someone from sharing something flawed, or does that just create friction people route around the first time it happens to be wrong? Centriu Dash answers that question by design: it warns clearly, but it never overrides the person's own judgment about their own data.

Turning a handful of different issue types into one trustworthy score means assigning real, deliberate weight to each severity level and each dimension, and testing that the resulting number actually behaves sensibly across combinations — a critical credential failure should dominate the score in a way three low-severity freshness warnings never should. Skipping that calibration and just counting issues produces a number that misleads as often as it helps. And deciding to make a warning informational rather than a hard block is itself a considered design choice, not a default — most systems that bother building a "gate" at all tend to make it stop something, because that is the simpler behavior to implement and reason about.

Every detected issue carries a severity — info, low, medium, high or critical — mapped to a fixed weight (0, 4, 10, 22 and 40 respectively). Those weights sum, per dimension (freshness, completeness, validity, consistency, anomaly, credentials, and demo-data penalty) and overall, into a single score capped at 0-100, and the combination of what is present resolves to one of six statuses: healthy, attention, risk, critical, insufficient data (nothing connected yet), or demo (only demonstrative-data flags present, nothing else). The score's own stated purpose is narrow and explicit: it measures the operational reliability of the data, not whether the underlying business result is good or bad.

Before sharing, presenting, or marking something ready, an advisory banner evaluates the current gate result and displays it — but the gate's own philosophy, confirmed directly in its source comment, is to never block on a minor issue; a true stop only ever triggers on an open critical issue or the presence of demonstrative data, and even then, the banner's own visible text states the person still decides, warning only that the result could be misinterpreted. A separate, lighter-weight version of the same gate can be scoped to a single dashboard, report or presentation rather than the whole organization.

Separately, and automatically, every time a presentation is generated Dash captures a snapshot of the quality state at that exact moment — the score, the status, and the titles of any open issues — and attaches it permanently to that specific presentation. The snapshot never stores raw data values or any credential; it exists specifically so a person opening that presentation weeks later can see how trustworthy the data was declared to be when it was actually built, independent of whatever the live quality score reads today. The same capture also runs as part of Dash's own scheduled automation engine, and in both cases a snapshot failure is deliberately non-blocking — it never interrupts the actual presentation or automation it is attached to.

A team generates a client presentation for the month. At that exact moment, one of the connected sources has been showing a credential warning for two days — a medium-severity issue, not enough to push the overall score into "critical," but enough to pull it down from "healthy" into "attention." The advisory banner shows this before the presentation is finalized: a warning, not a block, with the specific issue listed. The team reviews it, decides the affected metric isn't material to this particular client's presentation, and proceeds.

Dash automatically captures a snapshot at generation time: score, "attention" status, and the credential-warning issue title, attached to that specific presentation. Three weeks later, someone else on the team reopens the same presentation because a client asked a follow-up question. By then, the credential has long since been reconnected and the live score reads "healthy" — but the attached snapshot still shows exactly what it said the day the presentation was actually built, so nobody has to guess or dig through history to answer "was this reliable when we sent it."

A team gets one honest, calibrated number instead of a list they have to mentally total themselves, and a warning that informs rather than blocks — reducing the chance the whole feature gets routed around the first time someone disagrees with it. And every generated presentation carries its own permanent, tamper-proof record of how trustworthy the data was declared at the moment it was built, closing a gap that a live-only score can never close on its own.

A team that specifically wants a hard technical block preventing anyone from sharing flawed data will find this is not built that way — by explicit design, the advisory only ever stops on an open critical issue or demonstrative data, and even then it still lets the person decide. It is built to inform judgment, not replace it.

A raw list of individually-labeled issues asks the reader to do the weighing themselves, every time, under time pressure. A gate that hard-blocks on any detected problem trains people to work around it, so the warning eventually gets ignored altogether, including the one time it was right. Centriu Dash instead does the weighing once, consistently, into a single defensible score — and keeps the resulting warning informational rather than obstructive, so the person closest to the actual client relationship keeps the final call.