Quality Score Examples¶

Finding what pulls a container score down¶

Context. A team reviews the orders table, which scores in the low 80s even though most of its checks pass. With all weights at the default 1.0, its dimension scores are:

What happens. The multiplicative model starts from a baseline of 70 and adjusts up or down based on each dimension. A dimension does not pull the score down just by being below 100: each one has its own break-even point, and a score above it nudges the total up. Here Coverage (85) and Consistency (95) sit below their break-even points and pull the score down, while Accuracy (88) is above its own and gives a small boost. The result is a container score around 82.

Why it works. The dimension breakdown points straight at the fix: adding checks to the fields with the fewest raises Coverage, and profiling regularly while keeping the data's shape stable raises Consistency. See Container-Level Scoring for how much each dimension can move the score.

Understanding an unexpectedly low datastore score¶

Context. A datastore has 100 synced tables. The team actively monitors 2 of them, one scoring 100 and one scoring 0, so they expect a datastore score around 50 (the average of 100 and 0). The datastore score shows 8.

What happens. Containers showing - are excluded from the aggregate, so a score of 8 means more than 2 tables have scores. During setup, someone ran a profile and scan operation on the entire datastore, not just the 2 monitored tables. Every table that was both profiled and scanned now has a score, even tables nobody intended to monitor.

With no quality checks defined, each of those tables is heavily penalized:

• Coverage: No checks defined → treated as unmonitored → significant penalty
• Accuracy: No accuracy checks → data correctness is unverified → significant penalty
• Consistency: No profiling history → stability is unknown → significant penalty
• Completeness: Measured from profiling data → minimal penalty
• Conformity: No conformity checks → assumed fine → slight boost
• Precision: No precision checks → assumed fine → slight boost
• Timeliness: No freshness checks → assumed mostly on schedule → slight boost
• Volumetrics: No volumetric checks → assumed mostly stable → slight boost

Coverage, Accuracy, and Consistency outweigh the small boosts, and the combined effect brings an unchecked table's score down to roughly 10–15 from the 70-point baseline. With 98 tables scoring this low and the 2 monitored tables at 100 and 0, a datastore score of 8 is entirely plausible.

Why it works. Once the cause is clear, the team picks one of these options:

The most common cause of an unexpectedly low datastore score is a datastore-wide profile + scan during initial setup. Going forward, running operations on selected tables only keeps check-less tables out of the average.

Making critical tables count more¶

Context. A finance datastore has 20 scored tables. Two of them, general_ledger and invoices, feed the monthly close and score 60 and 70. The other 18 are staging and lookup tables that all score 90. Without tags, every container has a weight of 1, so the datastore score is (60 + 70 + 18 × 90) / 20 = 87.5, which hides the two problem tables.

What happens. The team creates a Critical tag with a weight modifier of +10 and assigns it to the datastore's two close tables. The container weights are recalculated the next time the datastore's tags change, or when a Move to, Merge, or Remove on a tag's page touches those tables. From then on each tagged table has a weight of 11, while untagged tables keep a weight of 1. The datastore score becomes (11 × 60 + 11 × 70 + 18 × 90) / (11 + 11 + 18) = 76.25.

Why it works. The datastore score now reflects the tables the business depends on, so a drop in the close tables moves the number everyone watches. See Tag Weight Modifiers for when weights are recalculated, and How Tags Affect the Datastore Score for the formula.

Ignoring timeliness on a static reference table¶

Context. A datastore holds a country_codes reference table that changes about once a year. It has a Freshness check, and because the table rarely changes, the check keeps flagging it as stale, so its Timeliness dimension pulls its score down. The rest of the datastore loads daily, and the team wants Timeliness to keep counting there.

What happens. The team opens the container's quality score settings and sets the Timeliness weight to 0 for country_codes only. The dimension is treated as fully healthy for that table and can no longer pull its score down. The datastore's own settings, and every container without an override, keep Timeliness at 1.0.

Why it works. A container override changes only that container, so one exception does not weaken the policy for the rest of the datastore. See Settings Inheritance and Overrides for how datastore and container settings combine.