# Data Quality Standard: [Organisation name]

> Organisation-wide standard for data quality: the dimension vocabulary every team uses, criticality tiers, the rule catalogue format (rule ID, dimension, check, threshold, severity, owner, enforcement point), measurement and the scorecard, data observability signals (freshness, volume, schema, distribution, lineage), issue management and root cause, the roles of data owner, steward and custodian, and how quality rules flow into data contracts and pipelines. The dimension vocabulary is structured on the characteristic names of ISO/IEC 25012:2008 (data quality model) and maps to the quality dimensions of the Bitol Open Data Contract Standard (ODCS) v3.2.0. Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- This standard sets organisation rules. It does not describe one
  dataset. Per-dataset rules, thresholds and service levels live in each
  Data Contract (`data/data-contract`); how data is built lives in the
  Data Pipeline Specification (`data/data-pipeline-spec`).
- Fill sections 1 to 4 first (scope, roles, vocabulary, tiers) and get
  them approved by the governance forum. Everything else depends on the
  shared vocabulary and on agreeing which data is Tier 1.
- Keep severity names identical to the ones used in data contracts and
  dbt tests (Critical, Major, Minor), and incident severity identical to
  the Incident Severity Matrix (`ops/incident-severity-matrix`).
- Worked examples use Corvid Commerce, a fictional SaaS retailer with a
  lakehouse on Apache Iceberg, transformations in dbt and two data
  products, "Orders" and "Checkout". Replace them with your own.
- Related documents: Data Contract (`data/data-contract`), Data Product
  Specification (`data/data-product-specification`), dbt Project
  Standard (`data/dbt-project-standard`), Data Classification Policy
  (`data/data-classification-policy`), Data Incident Postmortem
  (`data/data-incident-postmortem`), Data Governance Operating Model
  (`data/data-governance-operating-model`), Metric Definition
  (`data/metric-definition`), Observability Specification
  (`ops/observability-spec`), Alerting Policy (`ops/alerting-policy`).
-->

## Document control

<!-- Guidance: This is a governed standard. Record who owns it, who approved it and when it is next reviewed. A change to severity names or tier criteria is a minor version at least, because contracts reference them. -->

| Field | Value |
|---|---|
| Document ID | [STD-DQ-001] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@head-of-data-governance] |
| Approvers/reviewers | [@chief-data-officer], [@data-platform-lead], [@domain-data-owners], [@dpo] |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD (at least annually, and after any SEV1 data incident) |
| Classification | [Internal] |
| Applies to | [All shared datasets, data products and reports in the analytics platform] |
| Dimension vocabulary basis | ISO/IEC 25012:2008 characteristic names; ODCS v3.2.0 `dimension` values |
| Related documents | [Data governance operating model], [Data classification policy], [Incident severity matrix] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief data officer | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Data platform lead | [@name] | [Decision] | YYYY-MM-DD |
| Data governance council chair | [@name] | [Decision] | YYYY-MM-DD |
| Data protection officer (privacy dimensions) | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by the data governance council |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added the staging uniqueness requirement after data incident DIP-2026-014 |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Purpose, scope and principles](#1-purpose-scope-and-principles)
2. [Roles and responsibilities](#2-roles-and-responsibilities)
3. [Data quality dimension vocabulary](#3-data-quality-dimension-vocabulary)
4. [Criticality tiers and minimum controls](#4-criticality-tiers-and-minimum-controls)
5. [Rule catalogue](#5-rule-catalogue)
6. [Severity, thresholds and actions on failure](#6-severity-thresholds-and-actions-on-failure)
7. [Enforcement points](#7-enforcement-points)
8. [Data quality in contracts and pipelines](#8-data-quality-in-contracts-and-pipelines)
9. [Data observability signals](#9-data-observability-signals)
10. [Measurement and scorecard](#10-measurement-and-scorecard)
11. [Issue management and root cause](#11-issue-management-and-root-cause)
12. [Exceptions and waivers](#12-exceptions-and-waivers)
13. [Conformance, review and improvement](#13-conformance-review-and-improvement)
14. [Glossary and references](#14-glossary-and-references)
15. [Standard and licence note](#standard-and-licence-note)

## 1. Purpose, scope and principles

<!-- Guidance: State why the organisation has a data quality standard and what it covers. Questions: which data is in scope (shared datasets only, or every table)? Which decisions depend on it? Pitfall: a scope so broad that nobody can conform, so the standard is ignored. -->

### 1.1 Purpose

This standard defines how [Organisation name] specifies, measures, enforces and improves the quality of shared data. It gives every team the same words for quality problems, the same way to write a rule, the same severity levels and the same path from a failed check to a fixed root cause. The goal is that a consumer can tell, before using a dataset, how good it is for the intended use and who to call when it is not.

### 1.2 Scope

In scope:

- Every dataset published for use outside the producing team: data product output ports, shared marts, semantic models, certified dashboards and extracts sent to partners.
- Every pipeline that produces such a dataset, from ingestion to publication.
- Reference and master data used by those datasets.

Out of scope (covered elsewhere):

- Quality of application databases for their own transactional use (owned by the application team, see Database Design, `architecture/database-design`).
- Machine learning model quality and evaluation (covered by the AI and ML templates in this library).
- Security classification and handling rules (Data Classification Policy, `data/data-classification-policy`).

### 1.3 Principles

1. **Fitness for use.** Quality is judged against a stated use. A dataset can be excellent for trend analysis and unfit for invoicing. Every rule names the use it protects.
2. **Measured, not asserted.** A quality claim without a rule, a threshold and a result is an opinion. Publish results where consumers can see them.
3. **Fix at the source.** Cleansing downstream hides defects and multiplies cost. Correct the producing process; use downstream repairs only as a declared, temporary measure.
4. **Prevent before detecting.** Contracts, schema enforcement and tests at build time stop defects early. Observability catches what prevention misses; it does not replace it.
5. **Proportionate controls.** Controls scale with criticality (section 4). Tier 3 data does not need Tier 1 ceremony.
6. **One vocabulary.** Teams use the dimension names in section 3, in contracts, test tags, tickets and dashboards.

## 2. Roles and responsibilities

<!-- Guidance: Name real roles, not people, and make every rule traceable to an owner. Questions: who decides a threshold, who fixes a failed rule, who can grant a waiver? Pitfall: making the data platform team accountable for business correctness it cannot judge. -->

| Role | Accountable for | Typical holder |
|---|---|---|
| Data owner | Business accountability for a data domain or product: approves quality requirements, accepts residual risk, approves waivers for their data | Business or domain leader |
| Data steward | Defines business rules and thresholds with consumers, triages issues, maintains business definitions and the rule catalogue entries for the domain | Domain analyst or analytics engineer |
| Data custodian | Operates the technical controls: storage, pipelines, test execution, access, backup and recovery; implements rules defined by the steward | Data or platform engineer |
| Data producer | Builds and runs the pipeline or source system that creates the data; fixes defects at the source | Source application team or data engineering team |
| Data consumer | States the intended use and the quality it needs, reports issues, respects published caveats | Analysts, data scientists, downstream products |
| Data quality lead | Owns this standard, the scorecard, tooling standards and the quarterly review | Data governance office |
| Governance council | Approves this standard, tier criteria and policy exceptions above the owner's authority | Cross-domain forum |

### 2.1 Responsibility matrix

| Activity | Owner | Steward | Custodian | Producer | Consumer | DQ lead |
|---|---|---|---|---|---|---|
| Assign criticality tier | A | R | C | C | C | C |
| Define rule and threshold | A | R | C | C | C | I |
| Implement and schedule check | I | C | A/R | R | I | I |
| Triage a failed rule | I | A/R | R | R | I | I |
| Fix root cause at source | A | C | C | R | I | I |
| Grant waiver | A | R | C | C | I | C |
| Publish scorecard | I | C | R | I | I | A |
| Review this standard | C | C | C | C | C | A/R |

R = responsible, A = accountable, C = consulted, I = informed. Exactly one A per row.

## 3. Data quality dimension vocabulary

<!-- Guidance: Agree the words before you write rules. Questions: which dimensions do your tools and contracts already use? Which ISO/IEC 25012 characteristics matter for your data? Pitfall: copying a list of definitions from a standard or vendor. Write your own operational meaning and check the official text for the normative definitions. -->

### 3.1 Characteristic names (ISO/IEC 25012 alignment)

ISO/IEC 25012:2008 groups 15 data quality characteristics under two points of view: inherent (properties of the data itself) and system-dependent (properties that depend on the systems that store and serve the data). Some characteristics belong to both points of view. The table lists the characteristic names only; read the standard for the normative definitions. The "How we use it" column is this organisation's operational guidance, written for this template.

| Characteristic | Point of view | How we use it (operational guidance) | Typical rule types |
|---|---|---|---|
| Accuracy | Inherent | Values match the real-world fact or an authoritative source | Reconciliation to source, reference lookup, sample audit |
| Completeness | Inherent | Required values and expected records are present | Null checks, row count against expectation, coverage of keys |
| Consistency | Inherent | No contradictions within a record, across tables or across systems | Cross-field logic, referential integrity, cross-system totals |
| Credibility | Inherent | Consumers have reason to trust the source and its provenance | Certified source flag, provenance recorded, owner sign-off |
| Currentness | Inherent | Data is recent enough for the decision it supports | Freshness lag, effective-date checks |
| Accessibility | Inherent and system-dependent | Authorised people, including users of assistive technology, can reach and use the data | Catalogue entry, access path documented, accessible report formats |
| Compliance | Inherent and system-dependent | Data follows applicable standards, conventions and regulations | Format standards (ISO 4217, ISO 3166), retention tags, classification labels |
| Confidentiality | Inherent and system-dependent | Only authorised users can access and interpret the data | Masking checks, access reviews, no personal data in open zones |
| Efficiency | Inherent and system-dependent | Data can be processed with acceptable resources | Storage format, partitioning, avoidable duplication |
| Precision | Inherent and system-dependent | Values carry the exactness the use needs | Decimal scale, timestamp granularity, unit checks |
| Traceability | Inherent and system-dependent | Access and changes can be audited and lineage followed | Lineage events present, audit columns, change history |
| Understandability | Inherent and system-dependent | Users can read and interpret values, units and codes | Descriptions present, units stated, code lists published |
| Availability | System-dependent | Data can be retrieved when needed | Query success rate, platform uptime |
| Portability | System-dependent | Data can move between systems without losing quality | Open table formats, export tests |
| Recoverability | System-dependent | Data quality survives failures and can be restored | Snapshot retention, restore tests, replayable ingestion |

### 3.2 Operational dimensions used in rules

Rules in contracts and tests use a shorter operational set, aligned with the `dimension` values of the ODCS v3.2.0 quality object. Every rule carries exactly one operational dimension.

| Operational dimension (ODCS value) | Maps to ISO/IEC 25012 characteristic | Use for |
|---|---|---|
| `accuracy` | Accuracy | Reconciliation, reference matching, plausibility of values |
| `completeness` | Completeness | Nulls in required fields, missing records, row volume |
| `conformity` | Compliance, Precision | Format, type, allowed values, code lists, scale |
| `consistency` | Consistency | Cross-field, cross-table and cross-system agreement |
| `coverage` | Completeness | Share of the expected population present (for example all stores, all markets) |
| `timeliness` | Currentness | Freshness lag and on-time delivery against the service level |
| `uniqueness` | Consistency | No duplicate entities at the declared grain |

"Validity" is used informally by many tools. In this organisation, a validity rule is recorded as `conformity`. "Volume" and "freshness" are observability signals (section 9); when written as rules they are recorded as `completeness` and `timeliness`.

## 4. Criticality tiers and minimum controls

<!-- Guidance: Tiers make controls proportionate. Questions: what happens to the business if this data is wrong for a day? Is it used for external reporting, money movement or regulated decisions? Pitfall: everything is Tier 1, so nothing is. -->

### 4.1 Tier criteria

| Tier | Criteria (any one is enough) | Example *(Example)* |
|---|---|---|
| Tier 1 | Feeds external or regulatory reporting, financial close, automated decisions that move money or affect customers, or a certified executive metric | Corvid Commerce "Orders" product, `orders` output port |
| Tier 2 | Feeds internal decisions made weekly or more often, or more than one domain depends on it | "Checkout" product, `fct_checkout_sessions` |
| Tier 3 | Exploratory, team-internal or experimental data | Sandbox marts, one-off analyses |

### 4.2 Minimum controls per tier

| Control | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| Data contract with quality rules (`data/data-contract`) | Required | Required | Optional |
| Uniqueness rule at the declared grain | Required, Critical | Required, Major | Recommended |
| Completeness rules on critical data elements | Required, Critical | Required, Major | Recommended |
| Reconciliation to the system of record | Required, daily | Recommended | Not required |
| Freshness monitoring against service level | Required, paging | Required, ticket | Optional |
| Volume, schema and distribution monitors | Required | Volume and schema required | Optional |
| Lineage events emitted (OpenLineage) | Required | Required | Recommended |
| Scorecard published | Weekly | Monthly | Not required |
| Postmortem after consumer-impacting incident | Required (SEV1, SEV2) | Required (SEV1, SEV2) | At owner's discretion |
| Named owner, steward and custodian | Required | Required | Owner only |

## 5. Rule catalogue

<!-- Guidance: One catalogue per domain, held as code next to the tests where possible, and exported to the catalogue for consumers. Questions: can a machine evaluate every rule? Does each rule say who acts when it fails? Pitfall: rules without thresholds ("should be complete") or without owners. -->

### 5.1 Rule ID convention

Rule IDs use `DQ-<DOMAIN>-<NNN>`, for example `DQ-ORD-001` for the Orders domain. IDs are never reused. A retired rule keeps its ID with status `Retired`. The same ID appears in the data contract, in the test name or tag, in alerts and in incident tickets, so a failure can be traced end to end.

### 5.2 Required fields

| Field | Meaning |
|---|---|
| Rule ID | Stable identifier, `DQ-<DOMAIN>-<NNN>` |
| Dataset and element | Table, column or object the rule applies to |
| Dimension | One operational dimension from section 3.2 |
| Check | What is evaluated, written so a reviewer can implement it without guessing |
| Threshold | The pass condition, with unit and comparison operator |
| Severity | Critical, Major or Minor (section 6) |
| Owner | Steward accountable for the rule |
| Enforcement point | Where the check runs (section 7) |
| Schedule | Every load, hourly, daily or on demand |
| Action on failure | Block, quarantine, warn; who is notified |
| Business impact | One sentence on what goes wrong for consumers |
| Status | Proposed, Active, Waived, Retired |

### 5.3 Catalogue

| Rule ID | Dataset and element | Dimension | Check | Threshold | Severity | Owner | Enforcement point | Action on failure |
|---|---|---|---|---|---|---|---|---|
| DQ-ORD-001 *(Example)* | `orders.order_id` | uniqueness | Count of duplicate `order_id` values | `mustBe: 0` | Critical | [@orders-steward] | EP3 transformation (dbt test) | Block publish; page producer on-call |
| DQ-ORD-002 *(Example)* | `orders.customer_id` | completeness | Count of null `customer_id` | `mustBe: 0` | Critical | [@orders-steward] | EP3 transformation | Block publish |
| DQ-ORD-003 *(Example)* | `orders.currency` | conformity | Values outside the ISO 4217 code list | `mustBe: 0` | Major | [@orders-steward] | EP2 ingestion | Quarantine rows; ticket to producer |
| DQ-ORD-004 *(Example)* | `orders` daily `net_amount` | accuracy | Daily sum compared with the order service ledger | Difference at most 0.1% | Major | [@finance-steward] | EP4 publish (reconciliation job) | Mark day provisional; alert producer |
| DQ-ORD-005 *(Example)* | `orders` daily rows | completeness | Daily row count | Between 40,000 and 160,000 | Minor | [@orders-steward] | EP4 publish | Warn; notify consumers channel |
| DQ-ORD-006 *(Example)* | `orders` | timeliness | Now minus latest loaded `order_ts`; implemented as contract service level SLA-ORD-001 (latency), not as a quality rule (section 8.1) | At most 60 minutes | Major | [@orders-custodian] | EP5 observability | Page during business hours; ticket otherwise |
| DQ-ORD-007 *(Example)* | `stg_payments_api__payments.payment_id` | uniqueness | Count of duplicate `payment_id` values in staging | `mustBe: 0` | Critical | [@payments-steward] | EP3 transformation | Block downstream models |
| DQ-CHK-001 *(Example)* | `fct_checkout_sessions.session_key` | uniqueness | Duplicate session keys | `mustBe: 0` | Major | [@checkout-steward] | EP3 transformation | Block publish |
| DQ-CHK-002 *(Example)* | `fct_checkout_sessions` | consistency | Sessions with `order_completed` but no matching row in `orders` | At most 0.5% per day | Minor | [@checkout-steward] | EP4 publish | Warn |
| [DQ-XXX-nnn] | [dataset.element] | [dimension] | [check] | [threshold] | [severity] | [@owner] | [EPn] | [action] |

Rule DQ-ORD-007 is the staging control added after data incident DIP-2026-014 (see the worked example in Data Incident Postmortem, `data/data-incident-postmortem`). Duplicates in a source feed are cheaper to stop in staging than to detect in a revenue reconciliation.

### 5.4 Writing a good rule

- Write the check as a query or test name a reviewer could run.
- Derive thresholds from observed history and from the consumer's tolerance, not from habit. Record the evidence in the rule's change log.
- Prefer zero-tolerance thresholds only where zero is achievable; otherwise the rule fails constantly and is ignored.
- Link every Critical and Major rule to the use it protects (report, metric, decision) in the business impact field.

## 6. Severity, thresholds and actions on failure

<!-- Guidance: Rule severity says what the pipeline does when a check fails. Incident severity (SEV1 to SEV4) says how serious an incident is. Keep both, and keep them separate. Pitfall: rating every rule Critical, so every failure blocks and teams disable tests. -->

### 6.1 Rule severity levels

| Severity | Meaning | Default pipeline action | Notification |
|---|---|---|---|
| Critical | Publishing would give consumers wrong numbers for a Tier 1 or Tier 2 use | Stop: do not publish the affected partition; keep the last good version visible | Page the producer on-call any hour for Tier 1; business hours for Tier 2 |
| Major | Data is usable with a caveat, or a subset is wrong | Quarantine failing rows or publish with a provisional flag | Ticket to producer within 1 business day; consumer channel notice |
| Minor | Early warning; no known consumer impact yet | Publish and record | Daily digest |

Rule severity names are not incident levels. The Incident Severity Matrix (`ops/incident-severity-matrix`) also names SEV1 "Critical", SEV2 "Major" and SEV3 "Minor", but a Critical rule failure is classified separately (section 6.2) and is not automatically SEV1; many Critical failures are stopped at the publish gate and never become incidents. In alerts and tickets, write the rule severity with the word "rule" (for example "Critical rule DQ-ORD-001 failed") and the incident level only as SEV1 to SEV4, so the two scales are never confused.

### 6.2 From a failed rule to an incident

A failed rule becomes a data incident when wrong, late or missing data has reached a consumer or an automated decision, or is about to. Then classify the incident with the Incident Severity Matrix (`ops/incident-severity-matrix`), SEV1 (most severe) to SEV4. Each criterion of the matrix is evaluated on its own and the most severe result wins. Data specific examples *(Example)*: corrupted or lost data that cannot be recovered within the recovery point objective, or confirmed unauthorised access to personal or confidential data in an analytics zone, is SEV1 (matrix sections 4.3 and 4.4); wrong figures in a certified metric that can be corrected from intact source records, such as two days of overstated revenue, is SEV2 (section 4.3); a late mart with no data loss is SEV3; a Minor rule trend that has not yet affected anyone is SEV4. Any incident involving personal data is also handled with the Incident Response Plan (`compliance/incident-response-plan`), which decides on breach notification.

### 6.3 Threshold setting method

1. Profile at least [90] days of history for the measure.
2. Agree the consumer tolerance (for example, finance accepts a 0.1% reconciliation difference before close).
3. Set the threshold at the tighter of the tolerance and what the process can reliably achieve, and record both values.
4. Review thresholds that fail more than [5%] of runs or never fail in [180] days; both are signs the threshold is wrong.

## 7. Enforcement points

<!-- Guidance: Decide where each kind of rule runs. Questions: can a defect be stopped before anyone sees it? Which checks need the source system to cooperate? Pitfall: running every check only at the end, where a failure can no longer be traced to its cause. -->

| ID | Enforcement point | What runs there | Typical dimensions |
|---|---|---|---|
| EP1 | Source and producer | Input validation, contract tests in the producer's CI, schema registry compatibility checks | conformity, completeness |
| EP2 | Ingestion | Schema enforcement, type casting with quarantine, deduplication of replayed events | conformity, uniqueness |
| EP3 | Transformation | Tests on models (unique, not null, accepted values, relationships, unit tests), model contracts | uniqueness, completeness, consistency |
| EP4 | Publish gate | Reconciliation, volume ranges, write-audit-publish (stage, test, then expose) | accuracy, completeness, coverage |
| EP5 | Observability | Freshness, volume, schema change and distribution monitors on published data | timeliness, completeness, consistency |
| EP6 | Consumption | Report-level checks, certified dashboard tests, consumer feedback | accuracy, understandability |

```mermaid
flowchart LR
  SRC["EP1 Source and producer"] --> ING["EP2 Ingestion"]
  ING --> TRN["EP3 Transformation"]
  TRN --> PUB{"EP4 Publish gate"}
  PUB -->|pass| OUT["Published dataset"]
  PUB -->|Critical fail| HOLD["Hold: keep last good version"]
  OUT --> OBS["EP5 Observability monitors"]
  OUT --> USE["EP6 Consumption"]
  OBS -->|anomaly| ISS["Issue or incident (section 11)"]
  HOLD --> ISS
  USE -->|consumer report| ISS
```

Use a write-audit-publish pattern for Tier 1 data: write the new partition or snapshot to a staging location (for example an Apache Iceberg branch or an unpublished snapshot), run the EP4 checks, then publish atomically. Consumers never see a partially checked load.

## 8. Data quality in contracts and pipelines

<!-- Guidance: Explain how this standard becomes executable. Questions: where do rules live as code? How does a contract change reach the tests? Pitfall: the contract and the tests drift apart because they are maintained by different people in different places. -->

### 8.1 Contracts

Each Tier 1 and Tier 2 dataset has a Data Contract (`data/data-contract`) that applies this standard to one dataset. In ODCS v3.2.0 terms, rules sit in the `quality` list of a schema object or property, with `dimension`, `type` (`text`, `library`, `sql` or `custom`), a comparison operator such as `mustBe` or `mustBeBetween`, and `severity`. Use the rule ID as the quality rule `id` so the contract, the test and the alert share one identifier. Service levels such as freshness and latency go in the contract's service-level section, not in the quality list. The rule catalogue may still list them, as DQ-ORD-006 does, so the scorecard covers timeliness; the catalogue entry then names the contract service level that implements it.

### 8.2 Pipelines

- The Data Pipeline Specification (`data/data-pipeline-spec`) lists the rules each pipeline step enforces and the action on failure.
- In dbt projects, follow the dbt Project Standard (`data/dbt-project-standard`): every model has a primary key test, staging models test source keys, and tests carry the rule ID as a tag or in their name.
- Rules generated from the contract are preferred over hand-written duplicates. If both exist, the contract wins and the duplicate is removed.
- A contract change that tightens a threshold or adds a Critical rule is reviewed by the producer before merge, because it can block their releases.

### 8.3 Data products

The Data Product Specification (`data/data-product-specification`) publishes the scorecard and observability status of each output port as part of its management interface, so consumers find quality information where they find the data.

## 9. Data observability signals

<!-- Guidance: Observability finds the defects nobody wrote a rule for. Questions: which signals are monitored for each tier, by which tool, and who receives the alert? Pitfall: hundreds of automatic anomaly alerts with no owner, which teaches people to ignore them. -->

Monitor five signals on every published Tier 1 and Tier 2 dataset.

| Signal | Question it answers | Measure | Default monitor *(Example)* | Linked dimension |
|---|---|---|---|---|
| Freshness | Is the data as recent as promised? | Lag between now and the latest event or load time | Breach of contract freshness, checked hourly | timeliness |
| Volume | Did the expected amount of data arrive? | Rows or bytes per load or partition | Outside 50% to 200% of the 28-day median for the same weekday | completeness |
| Schema | Did the structure change? | Added, removed, renamed or retyped fields | Any change not announced in the contract change log | conformity |
| Distribution | Do values look like they usually do? | Null rate, distinct count, mean, percentiles, category shares | Null rate change above 5 percentage points; category share shift above 10 points | accuracy, consistency |
| Lineage | What feeds this and what does it feed? | OpenLineage run, job and dataset events with facets | Missing run event for a scheduled job; new unregistered upstream | traceability |

### 9.1 Lineage

Emit OpenLineage events (specification 2-0-2, as published by the OpenLineage project) from orchestrators and transformation tools. Each run sends a `START` event and one terminal event (`COMPLETE`, `FAIL` or `ABORT`); datasets carry facets such as the schema, and input datasets can also carry data quality assertions (the assertions facet is defined for inputs only). Lineage is what turns a failed check into a blast-radius list during an incident (see Data Incident Postmortem, `data/data-incident-postmortem`).

### 9.2 Alert routing

Route alerts according to the Alerting Policy (`ops/alerting-policy`): an alert pages a human only when the rule severity and the tier together require it (section 6.1). Every monitor has an owner and a runbook link. Review monitors that fired more than [10] times in a month without action; tune or delete them.

## 10. Measurement and scorecard

<!-- Guidance: Publish one score per dataset that consumers can understand, plus the detail behind it. Questions: what is the period, how are rules weighted, what are the bands? Pitfall: a single score that hides one Critical failure behind many trivial passes. Always show Critical failures separately. -->

### 10.1 Method

- **Rule pass rate** = passed evaluations / total evaluations in the period.
- **Rule weight** by severity: Critical 3, Major 2, Minor 1.
- **Dataset score** = sum of (weight x pass rate) / sum of weights, over all active rules.
- **Bands** *(Example)* for Tier 1: Green at or above 98.0%, Amber 95.0% to below 98.0%, Red below 95.0%.
- **Override**: any Critical rule failure that reached consumers in the period makes the dataset Red, whatever the score.

The ISO/IEC 25024:2015 standard defines data quality measures for the ISO/IEC 25012 characteristics. Use it, by clause reference, if you need formally defined measures for audits; the method above is a simpler operational score.

### 10.2 Worked example: Corvid Commerce `orders`, 28-day period

*Example:* period of 28 days, daily evaluation except DQ-ORD-006 (hourly, 28 x 24 = 672 evaluations).

| Rule | Dimension | Severity | Weight | Evaluations | Passed | Pass rate | Weight x pass rate |
|---|---|---|---|---|---|---|---|
| DQ-ORD-001 *(Example)* | uniqueness | Critical | 3 | 28 | 28 | 100.00% | 3.0000 |
| DQ-ORD-002 *(Example)* | completeness | Critical | 3 | 28 | 27 | 96.43% | 2.8929 |
| DQ-ORD-003 *(Example)* | conformity | Major | 2 | 28 | 28 | 100.00% | 2.0000 |
| DQ-ORD-004 *(Example)* | accuracy | Major | 2 | 28 | 26 | 92.86% | 1.8571 |
| DQ-ORD-005 *(Example)* | completeness | Minor | 1 | 28 | 27 | 96.43% | 0.9643 |
| DQ-ORD-006 *(Example)* | timeliness | Major | 2 | 672 | 658 | 97.92% | 1.9583 |
| **Total** | | | **13** | | | | **12.6726** |

Dataset score = 12.6726 / 13 = 97.48%, which is Amber for a Tier 1 dataset. The DQ-ORD-002 failure was blocked at the publish gate and did not reach consumers, so the Critical override does not apply. The two DQ-ORD-004 failures were the duplicate payment days investigated in DIP-2026-014.

### 10.3 Scorecard layout

| Dataset | Tier | Owner | Score | Band | Critical failures reaching consumers | Open issues | Trend vs last period |
|---|---|---|---|---|---|---|---|
| `orders` *(Example)* | 1 | [@orders-owner] | 97.48% | Amber | 0 | 2 | Down 1.2 points |
| `fct_checkout_sessions` *(Example)* | 2 | [@checkout-owner] | 99.10% | Green | 0 | 0 | Stable |
| [dataset] | [tier] | [@owner] | [score] | [band] | [count] | [count] | [trend] |

Publish the scorecard in the data catalogue and in the data product's management port. Keep the per-rule detail one click away.

## 11. Issue management and root cause

<!-- Guidance: Every failed Critical or Major rule creates or updates an issue. Questions: where are issues tracked, how fast must they be triaged, and when does an issue become an incident? Pitfall: closing the issue when the data is patched, without fixing the cause. -->

### 11.1 Issue lifecycle

Every issue moves through the states below. Only the steward closes an issue, and only after the rule has passed for the agreed verification period.

```mermaid
stateDiagram-v2
  [*] --> New
  New --> Triaged: steward assigns severity and owner
  Triaged --> Mitigated: workaround or data repaired
  Triaged --> Incident: consumer impact confirmed
  Incident --> Mitigated: incident process
  Mitigated --> Resolved: root cause fixed at source
  Resolved --> Verified: rule passes for agreed period
  Verified --> [*]
  Triaged --> Waived: approved waiver (section 12)
  Waived --> Triaged: waiver expires
```

### 11.2 Targets

| Rule severity | Triage within *(Example)* | Root cause fix planned within *(Example)* |
|---|---|---|
| Critical | 1 hour (Tier 1), 4 business hours (Tier 2) | 10 business days |
| Major | 1 business day | 30 days |
| Minor | 5 business days | Next quarterly review |

### 11.3 Issue record

Record for each issue: issue ID (`DQI-<YYYY>-<NNN>`), rule IDs affected, datasets and periods affected, detection source (rule, monitor, consumer), consumer impact, workaround, root cause category, fix, verification evidence and closure date.

### 11.4 Root cause categories

Use these categories so the quarterly review can find patterns:

| Category | Examples |
|---|---|
| Source process | Manual entry error, missing validation in the source application, business process change not communicated |
| Source system change | Schema or semantics changed without notice, new code values |
| Ingestion | Replay or retry duplicates, partial loads, timezone conversion |
| Transformation logic | Wrong join grain (fan-out), filter error, late-arriving data handling |
| Reference data | Outdated mapping table, missing code |
| Orchestration and platform | Skipped run, dependency ordering, resource failure |
| Rule gap | No rule existed, threshold too loose, wrong severity, alert misrouted |
| Definition | Producer and consumer understood the field differently |

For root cause analysis, use a causal chain and contributing factors as in Postmortem (`dev/postmortem`). A rule gap is always recorded in addition to the technical cause, because it explains why the defect was not caught earlier.

## 12. Exceptions and waivers

<!-- Guidance: Allow exceptions, but make them visible and temporary. Questions: who can approve, for how long, and with what compensating control? Pitfall: permanent waivers that silently lower the standard. -->

- A waiver suspends or relaxes one rule for one dataset for a stated period, at most [90] days, renewable once with council approval.
- The data owner approves waivers for Major and Minor rules; the governance council approves waivers for Critical rules on Tier 1 data.
- Each waiver records the reason, the consumer notice given, a compensating control and the expiry date. Waived rules appear on the scorecard as Waived, not as passing.

| Waiver ID | Rule ID | Dataset | Reason | Compensating control | Approved by | Expires |
|---|---|---|---|---|---|---|
| WVR-2026-003 *(Example)* | DQ-CHK-002 | `fct_checkout_sessions` | Marketplace orders arrive up to 48 hours late during migration | Daily manual reconciliation by steward | [@checkout-owner] | YYYY-MM-DD |
| [WVR-YYYY-nnn] | [rule] | [dataset] | [reason] | [control] | [@approver] | YYYY-MM-DD |

## 13. Conformance, review and improvement

<!-- Guidance: Say how you will know the standard is followed. Questions: which evidence does an internal audit look at? Which metrics show improvement? Pitfall: measuring the number of tests instead of the outcomes they protect. -->

### 13.1 Conformance evidence

A dataset conforms when, for its tier: the minimum controls in section 4.2 are in place; every Critical and Major rule has an owner, a threshold, an enforcement point and recent results; and open issues are within the targets of section 11.2. Evidence is the contract in version control, test results, monitor configuration, lineage events and the issue log.

### 13.2 Programme metrics

| Metric | Definition | Target *(Example)* |
|---|---|---|
| Tier 1 coverage | Share of Tier 1 datasets with all section 4.2 controls | 100% |
| Consumer-detected defects | Share of incidents first reported by a consumer rather than a rule or monitor | Below 20% |
| Time to detect | Median time from defect introduction to detection, Tier 1 | Below 2 hours |
| Repeat root causes | Issues with a root cause category seen in the same dataset within 90 days | Falling quarter on quarter |
| Waivers past expiry | Count of waivers not renewed or closed by expiry | 0 |

### 13.3 Review

The data quality lead runs a quarterly review with stewards: scorecard trends, repeat root causes, noisy monitors, waivers and rule gaps from postmortems. The standard itself is reviewed at least annually and after every SEV1 data incident.

### 13.4 Related standards

ISO 8000 is a multi-part series on data quality, including master data exchange and data quality management. Parts such as ISO 8000-1:2022 (overview), ISO 8000-8:2015 (information and data quality concepts and measuring) and ISO 8000-150:2022 (roles and responsibilities framework for data quality management) can inform the roles and processes above. The DAMA-DMBOK (2nd Edition Revised, 2024) has a Data Quality knowledge area that many organisations use for training. Check the current editions before citing them in an audit.

## 14. Glossary and references

<!-- Guidance: Define the terms your teams argue about. Keep definitions in your own words. -->

### 14.1 Glossary

| Term | Meaning in this standard |
|---|---|
| Critical data element (CDE) | A field whose errors have material financial, regulatory or customer impact |
| Data contract | Agreement between a producer and consumers on schema, quality and service levels for one dataset |
| Data incident | Wrong, late, missing or exposed data that reached or threatened consumers or decisions |
| Data observability | Automated monitoring of freshness, volume, schema, distribution and lineage of data |
| Enforcement point | The pipeline stage where a rule is evaluated (EP1 to EP6) |
| Rule severity | Critical, Major or Minor: what the pipeline does when a rule fails |
| Incident severity | SEV1 to SEV4: how serious an incident is, per the Incident Severity Matrix |
| Write-audit-publish | Load to an unexposed location, test, then publish atomically |
| Waiver | Approved, time-limited relaxation of one rule for one dataset |

### 14.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| ISO/IEC 25012:2008, Software engineering, SQuaRE, Data quality model, iso.org/standard/35736.html | Edition 2008, checked 2026-10-24 | Characteristic names and points of view (names only) |
| ISO/IEC 25024:2015, Measurement of data quality, iso.org/standard/35749.html | Edition 2015, checked 2026-10-24 | Pointer to formal measures (cited only) |
| ISO 8000-1:2022, ISO 8000-8:2015, ISO 8000-150:2022, Data quality series | Editions as listed, checked 2026-10-24 | Related standards (names only) |
| Bitol Open Data Contract Standard (ODCS) v3.2.0, github.com/bitol-io/open-data-contract-standard | Released 2026-09-08, Apache-2.0 | Quality object fields and `dimension` values |
| OpenLineage specification 2-0-2, openlineage.io | Project release 1.54.0, 2026-10-13, Apache-2.0 | Run, job, dataset and facet concepts for lineage |
| DAMA-DMBOK, 2nd Edition Revised, DAMA International | 2024 | Knowledge area name only |
| [Internal: incident severity matrix, alerting policy] | [Version] | Incident severity and alert routing |

## Standard and licence note

Structure aligned with the data quality model of ISO/IEC 25012:2008 (characteristic names and the inherent and system-dependent points of view only), with pointers to ISO/IEC 25024:2015 and the ISO 8000 series by name. Based on the Bitol Open Data Contract Standard (ODCS) v3.2.0 (Apache-2.0, github.com/bitol-io/open-data-contract-standard) for the quality rule fields and dimension values, and on the OpenLineage specification 2-0-2 (Apache-2.0, openlineage.io) for lineage concepts. No ISO text, definition or table and no DAMA-DMBOK content is reproduced; the operational guidance is original text written for this collection. Corvid Commerce is fictional. Check the current official versions of the standards and specifications before use. Template licence: MIT.