Data quality and SLAs

Data quality and service level agreements (SLAs) make a data product’s guarantees explicit and measurable: how good the data is, and how reliably it is delivered. In the Data Product Standard application, quality is expressed as measurable dimensions enforced by concrete checks, and delivery is governed by an SLA. This page covers the quality dimensions, the checks and operators that test them, the SLA dimensions, and where each attaches to a data product.

Data quality dimensions

Data quality is expressed as a set of dimensions. Each dimension pairs a target objective with a unit — the level the product commits to and how that level is measured. A consumer can then compare products on the same terms, dimension by dimension.

A data quality definition can also name the external tool that measures it, such as SodaCL, Montecarlo, DQOps, or Custom. The application supports the following dimensions:

Dimension	What it measures
Accuracy	How closely the data reflects the real-world values it represents.
Completeness	Whether all required records and fields are present, with none missing.
Conformity	Whether values follow the expected format, type, or standard.
Consistency	Whether the same data agrees across records, tables, and systems.
Coverage	Whether the dataset includes every entity or the full range it should.
Timeliness	Whether the data is current and available when consumers need it.
Validity	Whether values fall within the allowed set, range, or business rules.
Uniqueness	Whether each real-world entity appears once, without duplicates.

Quality checks

Quality checks are the concrete tests that enforce a dimension. A dimension states the goal; a check is the executable test that confirms whether the data meets it. Each check combines the following properties:

Property	What it defines	Allowed values
Type	How the check is defined	Library, SQL, Custom, Text
Dimension	The quality dimension the check enforces	Any dimension listed above
Severity	How the application treats a failing result	Info, Warning, Error
Metric	The quantity the check evaluates	Null Values, Missing Values, Invalid Values, Duplicate Values, Row Count
Engine	The tool that runs the check	Soda, Great Expectations, Monte Carlo, dbt

The type, dimension, and severity options above are the complete set. The metric and engine values are common examples rather than a fixed list. Severity ranges from Info, for a result worth recording, through Warning, up to Error for a failure that breaks the product’s guarantee.

Comparison operators

A quality check tests its metric against a target value using a comparison operator. The operator defines the pass condition — the relationship the measured value must satisfy for the check to succeed.

Operator	Meaning
Must Be	The value equals the target.
Must Not Be	The value does not equal the target.
Must Be Greater Than	The value is strictly greater than the target.
Must Be Greater Or Equal To	The value is greater than or equal to the target.
Must Be Less Than	The value is strictly less than the target.
Must Be Less Or Equal To	The value is less than or equal to the target.
Must Be Between	The value falls within a range, inclusive of both bounds.
Must Not Be Between	The value falls outside a given range.

For example, a check on the Row Count metric can use the operator Must Be Greater Than with a value of 1000. It then passes only when a load produces more than 1000 rows. A severity of Error marks a failing result as a broken delivery rather than a note for review.

A quality check can attach to a data contract, a schema object, or a schema property. This lets a test apply at the level where it belongs — across the whole contract, on a single schema object, or on one schema property.

Service level agreements (SLAs)

An SLA states the service commitments for a data product or a data contract — the availability, freshness, and support that consumers can rely on. Commitments are expressed as SLA dimensions, each with an objective and a unit, in the same way data quality uses dimensions.

Dimension	What it commits to
Latency	How quickly data becomes available after an event or request.
Uptime	The share of time the product is available for consumption.
Response Time	How quickly the product answers a query or request.
Error Rate	The maximum share of failed requests or records.
Update Frequency	How often the data is refreshed.
Time to Detect	How quickly an incident is identified.
Time to Notify	How quickly consumers are told about an incident.
Time to Repair	How quickly a detected incident is resolved.
Email Response Time	How quickly support replies to an email request.
End of Support	The date after which the product no longer receives support.
End of Life	The date after which the product is retired.

An SLA also records how to reach support: a phone number, an email address, and the hours during which each is available.

Where quality and SLAs attach

Data quality and SLAs attach at two levels — to the data product as a whole, and to specific parts of a data contract. The product level sets the headline promise; the contract level binds tests to the exact data being delivered.

Level	What it carries
Product level	The data product carries Data Quality and SLA objects that describe its overall guarantees.
Contract level	A data contract carries quality checks and SLA properties bound to specific schema objects and properties.

A documented quality check with a severity of Error tells a consumer exactly which condition will fail their pipeline before they build on the data. An SLA dimension such as Update Frequency tells them how current that data will stay. For the full list of attributes on each object type, see Data product object types and attributes.