Data SLOs: the Rastro method for reliable AI

Reliable AI starts before the model

Data SLOs define the minimum level of reliability a dataset must maintain to support a decision, process, or AI application. They turn vague terms such as “good data” or “up-to-date data” into verifiable commitments: maximum freshness of 15 minutes, completeness above 99%, no critical duplicates, lineage coverage, and consistency across business definitions.

This discipline has become urgent because data no longer supports only retrospective analysis. It powers recommendations, forecasts, agents that query internal systems, and automations that act on customers, inventory, pricing, and risk. In April 2026, Google Cloud highlighted that agents need to reason over historical context and live operational reality to act quickly. The implication is direct: delayed or disconnected data is not only an analytics failure; it is an execution failure. Read the announcement.

The challenge is that many companies monitor pipelines but do not monitor whether data is fit for a specific decision. A flow can complete without a technical error and still deliver a dataset that is incomplete, semantically ambiguous, or outdated. The Rastro method was designed to close this gap. It connects operational risk, quality rules, accountability, and incident response.

The Rastro method for operating data SLOs

Rastro stands for Risk, Attribute, Signal, Tolerance, Response, and Optimization. The framework starts with a simple premise: not all data requires the same standard, but all critical data requires an explicit standard. Rather than trying to raise the entire platform to the highest level of control, the company prioritizes the assets that truly drive decisions and processes.

1. Risk: start with the decision, not the table

The first step is to identify where incorrect, delayed, or incomplete data creates a material consequence. The prioritization unit should not be the most accessed table or the most complex pipeline. It should be the decision that depends on that asset.

Map the processes that use data to approve credit, set prices, prioritize leads, trigger service, plan demand, detect fraud, calculate commissions, or guide an AI agent. Then classify the impact of a failure across four dimensions: revenue, customer experience, regulatory risk, and operational continuity.

This approach avoids a recurring mistake: treating quality as a horizontal initiative with no connection to outcomes. The result is an extensive list of generic checks, limited business adoption, and no clarity about what should be fixed first.

Example: a services company uses an agent to classify urgent support requests. The active contracts table is more critical than a historical campaign dataset because an incorrect contract status could lead the agent to deny priority to an eligible customer. The SLO should originate from the risk of that decision, not from the technical convenience of monitoring the table.

2. Attribute: translate trust into observable dimensions

After defining the risk, select the quality attributes that truly matter for the intended use. The most common are freshness, completeness, validity, uniqueness, consistency, accuracy, availability, and traceability. However, the selection must be contextual.

For an executive dashboard updated weekly, a lag of a few hours may be irrelevant. For a collections automation, the same lag can generate inappropriate outreach. For a recommendation system, the issue may be less about freshness and more about attribute coverage. For a generative AI application, the deciding factor may be traceability: it must be possible to know where the content used as context came from.

Recent evolution in data platforms points in this direction. In April 2026, Google Cloud announced capabilities that combine lineage, quality profiling, search, and table-level access controls to provide enterprise context to agents. This reinforces that trust is not a single metric; it is the combination of quality, governance, and auditability. See the details.

Example: a sales operation uses “active customer” as a criterion to prioritize opportunities. The most important attribute is not only record completeness. It is semantic consistency: the same definition of active customer must apply in the CRM, data warehouse, financial system, and context provided to the sales agent.

3. Signal: build metrics that detect degradation early

An SLO without an operational signal becomes documentation. The third step is to define how each attribute will be measured and how often. The metric must be objective, automatable, and sufficiently sensitive to detect degradation before it becomes a business incident.

For freshness, measure the age of the last valid data, not just pipeline execution. For completeness, assess the proportion of required fields populated against the expected total. For validity, apply domain rules, such as dates within possible ranges, ZIP codes in the correct format, or non-negative monetary values. For consistency, compare metrics and keys across systems that should agree.

It is also useful to combine deterministic checks and anomaly detection. Deterministic rules capture known violations. Statistical models help identify unexpected changes in volume, distribution, cardinality, or seasonal behavior. Recent research on continuous observability based on table-format metadata proposes reducing the cost of these checks by leveraging signals already present in the infrastructure. Review the study.

Example: an orders pipeline can finish successfully while still delivering 40% fewer records than usual. An execution signal would indicate that everything is fine. A business signal compares current volume with the historical range for the same day and time, identifies the deviation, and blocks use of the dataset by sensitive automations.

4. Tolerance: establish limits and an error budget

The fourth step is to turn metrics into commitments. An SLO should declare an objective, an evaluation window, and a tolerance for failures. Rather than promising perfection, the team defines the acceptable level of risk for each asset.

A practical formulation is: “The available balance table will have freshness below five minutes in 99.5% of daily measurements” or “The validated email field will have minimum completeness of 98% in the dataset used for the retention campaign.” The remaining tolerance constitutes the error budget. When that budget is exhausted, the priority shifts from adding new functionality to restoring reliability.

This concept matters because it eliminates abstract disputes. The conversation shifts from “is quality poor?” to “has the asset exceeded the risk the process accepts?” It also prevents technical teams from being pressured to promise impossible availability or accuracy for external sources, human-entered data, or integrations subject to delays.

Example: a logistics platform accepts up to 30 minutes of delay in weather forecast data for next-day route planning. However, it accepts only five minutes of delay in vehicle location data used to reschedule in-progress deliveries. These are two SLOs, two tolerances, and two distinct operational responses.

5. Response: connect alerts to decisions and clear owners

Detecting a failure does not resolve the issue. The fifth step is to define who responds, what can continue operating, and what containment action applies. Every critical SLO should have a business owner, a technical owner, and an escalation protocol.

The business owner defines acceptable impact and validates whether the data still supports the decision. The technical owner maintains rules, integrations, observability, and remediation. When the SLO is violated, the system must know whether to block an automation, display a warning, use the last reliable version, reduce the scope of the decision, or route the case for human review.

This design is particularly relevant for AI agents. An agent should not receive only a dataset or a set of documents. It also needs reliability signals: refresh date, source, permitted scope, coverage level, and quality status. Without them, the system tends to treat any available information as equally valid.

Example: if inventory freshness exceeds the 10-minute SLO, the sales assistant should not state availability as fact. It can respond that confirmation is temporarily unavailable, open a verification request, and avoid promising a delivery date based on outdated data.

6. Optimization: use incidents to redesign the system

The final step is to turn failures into structural learning. Every relevant violation should trigger a brief review: what was the initial signal, how much time passed before detection, which decisions were affected, which containment worked, and which root cause must be eliminated.

The objective is not to produce lengthy reports. It is to adjust contracts, rules, architecture, and accountability. If the same failure recurs, the issue is likely not the alert. It may lie in reliance on a manual spreadsheet, an ambiguous definition, the absence of validation at the source, or an integration without a schema contract.

Preparing data for AI requires this continuous cycle. In March 2026, a Google Cloud initiative with DigitalRoute highlighted reusable pipelines for transforming fragmented operational data into AI-ready data, emphasizing that models and agents depend on reliable signals from the source. Read the case.

Example: a growth team identifies that duplicate leads enter the CRM after in-person events. Instead of merely creating a daily alert, the team redesigns the capture form, defines a deduplication key, establishes validation at the point of entry, and creates a uniqueness SLO for the dataset that feeds campaigns and sales routing.

How to get started without creating data bureaucracy

Adoption can begin with three high-impact assets. Choose a process that already uses automation or AI, a dataset with a history of failures, and a decision with a clear financial or operational consequence. For each asset, define one decision, two or three critical attributes, automated metrics, a simple SLO, and a response protocol.

Do not start with a complete catalog or dozens of indicators. Maturity comes when SLOs begin to guide real choices: blocking a campaign, suspending an automation, prioritizing an integration fix, or informing an agent about confidence limits.

Data, observability, and governance tools help, but they do not replace product discipline. The central question is always the same: what decision does this data enable, and what is the cost of making it with degraded information?

For companies operating multiple sources, processes, and channels, platforms such as Centriu can organize visibility and follow-up routines. Even so, the foundation of reliability is the explicit agreement among those who produce, transform, and consume data.

Data SLOs do not make information perfect. They make risk visible, negotiable, and operable. That is the difference between using data to analyze the past and using it safely to guide systems that act in the present.