Open Data Infrastructure
Data Product SLAs in Open Data Infrastructure
How to define data product SLAs across freshness, schema, lineage, access, cost, recovery, and open infrastructure ownership.
A data product SLA that only says "daily refresh" is not an SLA. It is a hope with a timestamp.
The practical problem
Data product teams need service commitments that consumers can understand and operators can measure. In ODI, those commitments have to survive across open tables, catalogs, engines, lineage systems, and AI consumers.
The SLA should describe what the data product promises, how the platform measures that promise, and what happens when the promise breaks. Anything less becomes dashboard theater.
Core idea: a data product SLA is an observable infrastructure contract, not a paragraph in a wiki.
The dimensions to define
Freshness is the obvious dimension. It should specify expected update cadence, allowed delay, data arrival window, and how consumers see stale or late data.
Schema and quality are next. The SLA should define which schema changes are compatible, which quality checks block publication, and which failures degrade trust without fully stopping the product.
Access, lineage, cost, and recovery complete the contract. Consumers need to know who can use the product, where it came from, what it costs to serve, and how quickly it can recover after a platform incident.
What breaks first
- Freshness is measured at ingestion, but consumers care about published table state.
- Schema changes are technically valid but break downstream semantic assumptions.
- Lineage exists but is not part of incident triage.
- AI consumers use the product without seeing degraded quality or stale context labels.
Questions to ask
Use these questions when defining a data product SLA.
- What freshness, quality, access, lineage, cost, and recovery commitments exist?
- Where is each commitment measured?
- Which failures block publication, and which failures degrade status?
- How do humans and agents discover current SLA status?
- Who owns response when the SLA fails?
For related operating models, read Running the Open Lakehouse in Production, Cost Allocation for Open Lakehouse Workloads, and AI-Ready Data Quality Signals.
Sources to start with
Data product SLAs should be backed by lineage, metadata, table contracts, and risk-aware AI signals.