Data Mesh: Dataset Contract & SLA Template

Purpose

This template helps domain teams publish trusted datasets by making expectations explicit between producers and consumers. Use it to document ownership, schema and semantic contracts, SLA targets, monitoring and test cases, access controls, change management, and escalation paths. Treat the contract as a living document: keep it versioned, discoverable, and linked to automated monitoring where possible.

How to use this template

1. Copy this template into your team’s dataset registry or knowledge store.
2. Fill in required fields and attach or link the authoritative schema (JSON Schema, Avro, Parquet, etc.).
3. Define measurable SLAs and test queries; configure monitoring and alerts to validate SLAs automatically.
4. Review and approve with consumers, then publish with a stable dataset identifier and version.
5. Maintain change logs, review cycles, and deprecation processes.

Contract header (identity & versioning)

• Dataset ID: stable unique identifier used in catalogs and APIs
• Dataset Name: human-friendly name
• Version: semantic or date-based versioning (e.g., 1.2.0 or 2026-08-01)
• Canonical Schema Link: link to authoritative schema (JSON Schema, Avro, Parquet, BigQuery table, etc.)
• Sample Data / Example Rows: minimal sample payload or link
• Semantic Glossary: short definitions of important terms and key fields

Ownership & contacts

• Producer Team: team or service responsible for publishing
• Producer Contact: primary contact (email, Slack handle, pager)
• Data Steward: responsible for quality & semantic correctness
• Consumer Representative(s): primary consumer contacts for coordination and acceptance testing

Upstream commitments (producer responsibilities)

Describe what the producer commits to deliver. Make commitments measurable:

• Publish cadence (e.g., incremental hourly, daily batch at 02:00 UTC)
• Supported query patterns and performance expectations
• Compatibility guarantees across versions (backwards compatible fields, deprecated fields policy)
• Notification process for schema or semantic changes

Consumer responsibilities

• Register acceptance tests and notify producers of integration problems
• Provide realistic test workloads and feedback on data quality
• Follow access control and privacy rules

SLA: measurable expectations

Define each SLA as a measurable metric, target, measurement method, reporting cadence, and escalation path.

• Freshness (latency): target value and unit (for example: < 1 hour from event time to availability in dataset). Describe how measured (event-time vs processing-time) and the query or job used for measurement.
• Completeness: percentage of expected rows/records or coverage of primary keys (for example: >= 99.5% of daily expected rows). Define how expected count is determined.
• Error tolerance / data quality: allowed error rate (for example: < 0.1% invalid rows), with definition of what counts as an error (schema mismatch, nulls in PK, semantic rule violations).
• Availability / delivery success: percent of scheduled publishes that succeed (for example: 99% weekly success rate).
• Schema stability: expected number of breaking schema changes per quarter, or guarantee of non-breaking compatible changes by default.

Monitoring & observability

List monitoring endpoints, dashboards, and test queries that prove the contract. Provide concrete examples and threshold values that trigger alerts.

• Monitoring queries or jobs (links to notebooks or SQL queries)
• Dashboard links (availability, freshness, completeness, error rate)
• Alerting rules (conditions, destination channels, on-call escalation)
• Lineage pointers (upstream datasets, transformations, critical jobs)

Test cases & acceptance criteria

Include at least one consumer acceptance test that the producer and consumer agree on. Make tests runnable and automatable.

• Example test SQL or code snippet that validates a key semantic rule
• Expected results or ranges for test runs
• Pass/fail thresholds and where test results are published

Access, privacy & security

• Access classification: Public / Internal / Confidential / Restricted
• Privacy classification: None / PII / PHI / Financial / Other — list sensitive fields and handling rules
• Access controls: roles, groups, and required approvals
• Encryption & transport: required at-rest and in-transit protections
• Retention & deletion: policy and legal requirements

Change management & versioning

• Change notification process (how and when consumers will be notified)
• Compatibility policy (what counts as breaking vs non-breaking change)
• Versioning approach (semantic, date-based, or other)
• Grace periods and migration support for breaking changes

Deprecation & retirement

Define how the dataset is deprecated: notice periods, archival approach, migration guides, and final removal process.

Escalation & dispute resolution

• Primary escalation contacts for SLA breaches
• Escalation timeline (e.g., 1 hour initial notification, 4 hours mitigation plan, 24 hours executive notification)
• Process for raising and resolving semantic disagreements

Operational checklist (for publishing)

1. Attach canonical schema and sample rows.
2. Provide semantic glossary for critical fields.
3. Configure monitoring queries and dashboards.
4. Define SLA metrics with measurement queries and alert thresholds.
5. Run consumer acceptance tests and record results.
6. Publish dataset in the catalog with version and contact info.
7. Schedule review cadence and add to team’s maintenance backlog.

Example (concise)

Dataset ID: orders.v1

Freshness SLA: < 30 minutes (measured event-time to table availability; monitoring SQL: link)

Completeness: >= 99% of expected daily order rows (expected computed from payments system)

Allowed error rate: <= 0.05% invalid rows (schema violations counted)

Access: Internal, contains PII (masking rules apply), role-based access required

Producer contact: payments-team@example.com

Notes & next steps

Treat this template as a living contract. For maximal reliability, pair this document with automated monitoring, a dataset registry, and periodic audits. Where available, connect SLA measurements to automated alerts and a runbook that outlines mitigation steps for common failures.