Essay

Data SLAs: Time as an Architectural Contract

*Time is commonly expressed in Data Platform service agreements through a single phrase such as “daily by 08:00” or “latency below one hour.” These promises conflate event occurrence, source availability, ingestion, processing, validation, publication, and consumer visibility. This essay develops temporal service levels as explicit architectural contracts. It distinguishes latency, freshness, availability, completeness, and recovery; formalises percentile and window-based objectives; and examines late data, watermarks, and dependency budgets. It also argues that time is not merely a performance dimension. Temporal guarantees shape which claims can be made and which decisions are legitimate. A dataset that is technically available may be too stale for action, while a fresh partial dataset may be more dangerous than a delayed complete one.*

8 minute read·July 2026·Davide Scuteri Moretti

data SLASLOfreshnesslatencyevent timewatermarkstemporal contractsreliability engineering

Themes

— Contracts

Abstract

Time is commonly expressed in Data Platform service agreements through a single phrase such as “daily by 08:00” or “latency below one hour.” These promises conflate event occurrence, source availability, ingestion, processing, validation, publication, and consumer visibility. This essay develops temporal service levels as explicit architectural contracts. It distinguishes latency, freshness, availability, completeness, and recovery; formalises percentile and window-based objectives; and examines late data, watermarks, and dependency budgets. It also argues that time is not merely a performance dimension. Temporal guarantees shape which claims can be made and which decisions are legitimate. A dataset that is technically available may be too stale for action, while a fresh partial dataset may be more dangerous than a delayed complete one.

1. One timestamp is never enough

A record can carry multiple times:

t_{e}, t_{s}, t_{i}, t_{p}, t_{v}, t_{c},

representing event occurrence, source commit, ingestion, processing completion, validation, and consumer availability. The difference between any pair defines a distinct latency.

End-to-end latency is often

L_{e 2 e} = t_{c} - t_{e},

but operational diagnosis requires decomposition:

L_{e 2 e} = (t_{s} - t_{e}) + (t_{i} - t_{s}) + (t_{p} - t_{i}) + (t_{v} - t_{p}) + (t_{c} - t_{v}) .

Each component has a different owner and failure mode. A platform cannot control source capture delay in the same way it controls queueing or transformation time.

Temporal contracts should therefore name the clock and boundary. “Available within one hour” is incomplete unless it states one hour from what event and available where.

2. SLA, SLO, and SLI

A service-level indicator is a measured quantity. A service-level objective is a target over that quantity. A service-level agreement adds organisational or commercial commitments and consequences.

For freshness indicator

F (t) = t - max (t_{e} r e p r ese n t e d in p u b l i s h e dd a t a),

an objective might state

P (F (t) \leq 30 min) \geq 0.99

over a defined evaluation window.

Percentiles and compliance proportions are usually more informative than averages. A mean latency can conceal severe tail delays. Critical processes may need maximum bounds or separate tail objectives.

The contract should specify measurement location, excluded periods, maintenance treatment, and handling of missing telemetry. Otherwise the SLO can be met by redefining the measurement.

3. Freshness is not completeness

A dataset can be fresh because it contains the latest event while missing earlier partitions or source segments. Conversely, a complete daily snapshot may be several hours old.

Let freshness be $F$ and completeness for expected scope $W$ be

C_{W} = \frac{∣ D _{r ece i v e d} \cap W ∣}{∣ D _{e x p ec t e d} \cap W ∣} .

Temporal admissibility may require both:

F \leq θ_{F} \land C_{W} \geq θ_{C} .

Expected completeness is difficult when the platform does not know how many records should arrive. Source manifests, sequence ranges, reconciliation totals, or historical models can provide evidence. Absence of evidence should not be interpreted as complete zero activity.

4. Event time and processing time

Streaming systems distinguish event time from processing time. Event-time windows align computation with represented occurrence, while processing-time windows align with arrival. Late events force a policy choice.

A watermark $w (t)$ asserts that events earlier than $w$ are unlikely or no longer accepted. For allowed lateness $δ$ :

w (t) = max (t_{e} o b ser v e d) - δ .

Closing a window produces timely results but may exclude late evidence. Keeping windows open improves completeness but delays publication and consumes resources. There is no universally correct $δ$ ; it reflects source behaviour and decision cost.

Corrections after closure should have defined semantics: update, restate, append revision, or ignore with explicit policy. Temporal contracts must include late-data behaviour, not only nominal cadence.

5. Dependency budgets

A data product depends on upstream products and tasks. Its latency budget can be allocated across the dependency path.

For critical path $P$ :

L (P) = v \in P \sum L_{v} + e \in P \sum Q_{e},

where $L_{v}$ is task processing and $Q_{e}$ queue or handoff delay. The product SLO requires

L (P) \leq B .

Budget allocation makes bottlenecks visible and prevents every team from consuming the entire end-to-end allowance. Yet local SLO compliance does not guarantee global compliance when retries, fan-in, and correlated delays interact.

Executable lineage and traces are necessary to attribute breach accurately.

6. Error budgets for data products

Site reliability engineering uses error budgets to balance reliability and change. Data products can adopt a similar model. If objective allows violation fraction $ϵ$ , budget over $N$ evaluation intervals is

B_{e} = ϵ N .

Consumption can reflect freshness, completeness, or quality breaches. When budget is exhausted, the team may pause risky changes or prioritise reliability work.

Data error budgets require care because not all intervals have equal consequence. A delay during low activity differs from a delay during a critical reporting deadline. Weighted budgets can assign impact $w_{t}$ :

B_{u se d} = t \sum w_{t} [b r e a c h_{t}] .

This makes the temporal contract sensitive to organisational rhythms without hiding exceptions.

7. Recovery time and historical debt

An incident can be resolved operationally while historical data remains incomplete. Mean time to restore service and time to repair data history are different indicators.

Let

T_{r es t or e} = t_{ser v i cer es t or e d} - t_{in c i d e n t},

T_{r eco n c i l e} = t_{hi s t or y cor r ec t e d} - t_{in c i d e n t} .

A pipeline may resume in one hour but require two days to backfill missed events. Consumers need to know whether current and historical windows are trustworthy.

Temporal contracts should therefore include recovery point and reconciliation objectives. A green current feed should not erase historical debt.

8. Temporal semantics and legitimate decisions

Time determines what a dataset can support. A stale inventory view may cause stock-out. A late alert may be informational but no longer actionable. A current partial view may exaggerate or understate a rate.

Decision admissibility can be expressed as

A d mi t (D, u, t) = 1

only if freshness, completeness, and validity satisfy purpose-specific thresholds. The platform should expose these conditions to consuming applications rather than relying on users to inspect timestamps manually.

This is where temporal engineering becomes epistemology. A claim is not merely true or false; it is available at a time, based on evidence available at a time, for a decision that expires at a time.

9. Calendars, clocks, and institutional time

Temporal SLAs are not purely metric. Organisations operate through calendars, shifts, cut-offs, business days, and regulatory periods. “Daily” can mean every 24 hours, by local midnight, before a morning meeting, or after all source systems close.

Calendar logic should be explicit and versioned. Daylight-saving transitions, holidays, source time zones, and regional calendars can create silent breaches or duplicated windows. A service clock must define

C a l e n d a r = (z o n e, b u s in ess d a y s, c u t o f f s, e x ce pt i o n s) .

Institutional time is constructed. Architecture should encode that construction rather than assume UTC alone resolves meaning.

10. Designing a temporal contract

A complete contract names event and observation clocks, indicators, objectives, evaluation windows, percentile rules, completeness evidence, late-data treatment, maintenance exclusions, recovery expectations, and ownership.

An example temporal contract tuple is

T_{C} = (c l oc k, b o u n d a r y, S L I, S L O, w in d o w, l a t e, r eco v er y, o w n er) .

It should be testable from platform telemetry and linked to downstream use policies. Breaches generate not only alerts but data-product status changes.

The contract should also state what it does not guarantee. An hourly refresh may not guarantee source completeness or semantic finality. Precision protects consumers from interpreting performance as certainty.

10. Provisionality and temporal truth

Temporal contracts should also distinguish provisional and final publication. A product may be released early because operational value declines rapidly with delay, then consolidated after late evidence and reconciliation. Let $Y_{t}^{(p)}$ be the provisional state available at time $t$ , and $Y^{(f)}$ the final state after closure. The revision magnitude is

R_{t} = d (Y_{t}^{(p)}, Y^{(f)}) .

Monitoring $R_{t}$ reveals whether early publication is a reliable approximation or a source of systematic distortion. The contract can set both a provisional freshness objective and a finalisation objective, with distinct permissible uses.

This distinction is culturally important. Organisations often treat the first visible number as definitive even when engineering labels it provisional. Interfaces, APIs, and downstream contracts should preserve provisionality as machine-readable status. A rapidly available estimate can be valuable, but only if consumers know what kind of temporal claim it is.

11. Breach semantics and communication

A temporal breach is not merely an alert to the platform team. It changes the evidential status of consuming products. Breach handling should identify the first missed boundary, affected event-time interval, known completeness, expected recovery, and decision classes that should pause or degrade.

Let product status be

S_{D} = (f r es hn ess, co m pl e t e n ess, f ina l i t y, r eco v er y s t a t e) .

Status should propagate through lineage. A downstream metric that depends on a stale source cannot remain green simply because its own task ran on schedule. Communication becomes part of the contract: machines need status flags, operators need diagnostic context, and decision-makers need an intelligible statement of consequence. A temporal SLO is credible only when its violation has predefined semantics.

Conclusion

Time in a Data Platform is not one latency number. It is a structured relation among event occurrence, source commitment, ingestion, processing, validation, publication, and knowledge. Service levels become meaningful only when these boundaries and clocks are explicit.

Freshness must be paired with completeness; end-to-end latency decomposed across dependencies; late data governed through watermarks and correction policies; recovery measured both for service and history. Calendars and decision horizons add institutional semantics to technical time.

Extracted images (64):

parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_1.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_10.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_11.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_12.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_13.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_14.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_15.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_16.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_17.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_18.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_19.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_2.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_20.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_21.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_22.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_23.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_24.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_25.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_26.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_27.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_28.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_29.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_3.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_30.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_31.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_32.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_33.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_34.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_35.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_36.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_37.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_38.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_39.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_4.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_40.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_41.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_42.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_43.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_44.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_45.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_46.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_47.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_48.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_49.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_5.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_50.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_51.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_52.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_53.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_54.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_55.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_56.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_57.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_58.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_59.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_6.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_60.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_61.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_62.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_63.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_64.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_7.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_8.jpg
parsed-documents://20260717-165842-890120/The_Discipline_of_Data_Platforms_15_Essays.docx/images/page_9.jpg