Build the review around explicit rules, stable source-row identifiers, and a denominator for every result. Preserve the raw export. The dashboard should explain the exceptions before anyone changes a value or deletes a record.
Declare what each rule means
Microsoft's data-quality documentation distinguishes completeness from correctness: a present value can still be wrong. It also describes uniqueness and allowed-value checks. The example below uses those concepts with its own declared five-row contract; it does not reproduce a Purview scan or combined score. Microsoft's data-quality rule documentation
Use three rules for this original fictional export: every row needs an owner; a business ID must occur exactly once in the selected dataset; and status must be exactly Open or Closed. Both occurrences of a repeated business ID fail the uniqueness rule. All five rows are evaluated by each rule. Blank owner means the value is missing, not that you have determined who the correct owner should be.
| Source row | Business ID | Owner | Status |
|---|---|---|---|
| 1 | A | Kim | Open |
| 2 | B | Lee | Open |
| 3 | B | [blank] | Closed |
| 4 | D | Sam | Hold |
| 5 | E | Tay | Closed |
The source-row number identifies a record independently of its business ID. Rows 2 and 3 both have ID B, so ID alone cannot tell a reviewer which occurrence they are inspecting. Keep all five raw rows and carry the source-row identifier through every exception view.
Reconcile rule counts with affected records
| Rule | Passing rows / evaluated rows | Failed source rows | What needs review |
|---|---|---|---|
| Required owner | 4 / 5 | 3 | Identify the owner from the authoritative source |
| Unique business ID | 3 / 5 | 2, 3 | Determine why B occurs twice |
| Allowed status | 4 / 5 | 4 | Check Hold against the declared status rule and source context |
These pass rates are 80%, 60%, and 80%, respectively. The results describe the declared checks; they do not prove the other values accurately represent reality.
There are four rule-failure instances: one for the missing owner, two for uniqueness, and one for status. The distinct affected source rows are the union {2,3,4}, giving three affected rows out of five. Row 3 appears once in that summary even though it fails two rules. Do not average the three rates into an unexplained overall quality score.
Separate inspection from correction
Selecting the uniqueness rule in a later interactive review copy should reveal rows 2 and 3, their values, and the 3/5 passing result. Selecting required owner should reveal row 3 with 4/5. Switching to the affected-record summary should list rows 2, 3, and 4 once each, while preserving each row's failed-rule list. Check these same source bindings after adapting the companion.
Do not silently remove a B row to make the result look better. The duplicate may be a repeated export record, or the business-ID rule may be inappropriate for the source. Neither conclusion is supplied here. Similarly, do not rewrite Hold as Open merely because it is outside the permitted list. Ask whether the source value or the declared rule needs correction.
Keep a separate correction-review record with source row, failed rule, evidence to seek, proposed change, actual reviewer decision, and verified result. Leave unsupplied decisions blank. Recalculate only after an authorized change is made in the maintained source and a new review dataset is identified.
Give empty data an honest result
In the workbook specification, store raw records, rule definitions, row-level outcomes, and the summary separately. Record the selected dataset and its row count. For this example, the denominator remains five for each rule; changing a dataset filter would require evaluating the selected rows again and naming the new denominator. A display filter should not quietly redefine uniqueness.
With no selected records, report “No rows evaluated; pass rate undefined.” Zero failures over zero rows is not a 100% pass result. A workbook or HTML preview should retain that empty-state meaning rather than use a favorable default.
Copy this prompt for the dashboard review specification
Create one complete, self-contained US-English HTML companion for “Data quality • source review”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for Full specimen; Empty dataset; Inspect owner; Inspect uniqueness; Inspect status; All affected rows; Select text. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Create a US English data quality dashboard review packet and native-workbook specification, not a claimed Purview scan. Return the raw table, three declared rules, complete row-level outcomes, rule summary, affected-row summary and correction-review sheet. Original records: row1 A/Kim/Open; row2 B/Lee/Open; row3 B/[blank]/Closed; row4 D/Sam/Hold; row5 E/Tay/Closed. Keep all five rows. Source-row identifiers are distinct from business IDs. Rules: owner required; business ID occurs exactly once across selected dataset, with both duplicate occurrences failing; status exactly Open or Closed. Evaluate all five rows for each rule. Expected passes: required owner4/5 (80%), uniqueness3/5 (60%), allowed status4/5 (80%). Failed rows: owner3; uniqueness2,3; status4. Four rule-failure instances, but distinct affected rows2,3,4: three of five. Preserve overlap without double-counting affected rows. Do not produce an arbitrary combined score or claim completeness establishes accuracy. Selecting a rule in a proposed HTML review copy must reveal its exact failed source rows and denominator without altering raw data; the overall summary lists each affected source row once. Keep display filtering distinct from changing the evaluated dataset. With zero evaluated rows, rates are undefined, not100%. Correction sheet: source row, failed rule, evidence needed, proposed change, blank actual reviewer decision and verification. No silent deduplication, owner guessing, Hold-to-Open rewriting or fix/delete controls. Native source remains authoritative; proposed interaction implementation/testing is pending.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# A Data Quality Dashboard Template That Shows the Rows Behind Each Failure
Your export has one missing owner, two occurrences of a duplicate ID, and one unexpected status. Adding those counts gives four failures. It does not mean four different records need attention: one row fails two rules. A dashboard that hides the source rows makes that distinction hard to check.
Build the review around explicit rules, stable source-row identifiers, and a denominator for every result. Preserve the raw export. The dashboard should explain the exceptions before anyone changes a value or deletes a record.
## Declare what each rule means
Microsoft's data-quality documentation distinguishes completeness from correctness: a present value can still be wrong. It also describes uniqueness and allowed-value checks. The example below uses those concepts with its own declared five-row contract; it does not reproduce a Purview scan or combined score. [Microsoft's data-quality rule documentation](https://learn.microsoft.com/en-us/purview/unified-catalog-data-quality-rules)
Use three rules for this original fictional export: every row needs an owner; a business ID must occur exactly once in the selected dataset; and status must be exactly `Open` or `Closed`. Both occurrences of a repeated business ID fail the uniqueness rule. All five rows are evaluated by each rule. Blank owner means the value is missing, not that you have determined who the correct owner should be.
| Source row | Business ID | Owner | Status |
| --- | --- | --- | --- |
| 1 | A | Kim | Open |
| 2 | B | Lee | Open |
| 3 | B | [blank] | Closed |
| 4 | D | Sam | Hold |
| 5 | E | Tay | Closed |
The source-row number identifies a record independently of its business ID. Rows 2 and 3 both have ID B, so ID alone cannot tell a reviewer which occurrence they are inspecting. Keep all five raw rows and carry the source-row identifier through every exception view.
## Reconcile rule counts with affected records
| Rule | Passing rows / evaluated rows | Failed source rows | What needs review |
| --- | --- | --- | --- |
| Required owner | 4 / 5 | 3 | Identify the owner from the authoritative source |
| Unique business ID | 3 / 5 | 2, 3 | Determine why B occurs twice |
| Allowed status | 4 / 5 | 4 | Check Hold against the declared status rule and source context |
These pass rates are 80%, 60%, and 80%, respectively. The results describe the declared checks; they do not prove the other values accurately represent reality.
There are four rule-failure instances: one for the missing owner, two for uniqueness, and one for status. The distinct affected source rows are the union `{2,3,4}`, giving three affected rows out of five. Row 3 appears once in that summary even though it fails two rules. Do not average the three rates into an unexplained overall quality score.
## Separate inspection from correction
Selecting the uniqueness rule in a later interactive review copy should reveal rows 2 and 3, their values, and the 3/5 passing result. Selecting required owner should reveal row 3 with 4/5. Switching to the affected-record summary should list rows 2, 3, and 4 once each, while preserving each row's failed-rule list. Check these same source bindings after adapting the companion.
Do not silently remove a B row to make the result look better. The duplicate may be a repeated export record, or the business-ID rule may be inappropriate for the source. Neither conclusion is supplied here. Similarly, do not rewrite `Hold` as `Open` merely because it is outside the permitted list. Ask whether the source value or the declared rule needs correction.
Keep a separate correction-review record with source row, failed rule, evidence to seek, proposed change, actual reviewer decision, and verified result. Leave unsupplied decisions blank. Recalculate only after an authorized change is made in the maintained source and a new review dataset is identified.
## Give empty data an honest result
In the workbook specification, store raw records, rule definitions, row-level outcomes, and the summary separately. Record the selected dataset and its row count. For this example, the denominator remains five for each rule; changing a dataset filter would require evaluating the selected rows again and naming the new denominator. A display filter should not quietly redefine uniqueness.
With no selected records, report “No rows evaluated; pass rate undefined.” Zero failures over zero rows is not a 100% pass result. A workbook or HTML preview should retain that empty-state meaning rather than use a favorable default.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Review exceptions
Use the HTML companion to check that selecting a rule preserves the same evidence and denominator after the controls have been built and tested. Maintain the data and approved corrections in the native workflow.
Finish with the three affected rows identified and an evidence question for each, so a smaller exception count never conceals the work still needed.