Data stewards, record owners, and the business teams accountable for data in systems of record share a common job: keeping data usable, trusted, and understood across the datasets, definitions, and downstream consumers that depend on them. Without the right data steward tools, that accountability turns into a job of chasing teams through Slack, assembling audit evidence by hand, and policing definitions across half a dozen tabs.

This walkthrough follows the data quality part of that work through Soda: triaging the work queue, monitoring data behavior, investigating anomalies, defining contracts, collaborating with data consumers, and approving agent-assisted remediation.

Where Soda Fits in the Data Steward Workflow

At its core, the steward’s job is to keep data healthy and usable: defining terms, tracing lineage, flagging silent failures, monitoring quality rules, making access and retention calls, and translating between technical and business teams.

Soda is an AI-native data quality platform designed to make data governance operational. It gives data stewards direct visibility into how data behaves, detects quality issues automatically, and provides a structured path from detection to resolution.

Soda follows a three-phase loop: find the issue, understand what happened, fix the records that failed. The walkthrough below traces each phase through the surfaces stewards and record owners actually touch: the work queue, the metric monitors, the incident panel, the contracts, the request channel, and the Soda Cleanse Inbox.

A few things are set up before the first morning. Permissions on each dataset decide the steward’s reach: Propose checks to request a contract change, Manage contract to publish one or use Contract Copilot, and Manage incidents to open incidents. Notification rules name each dataset’s owners, so alerts reach the right people. And the Fix steps need the Diagnostics Warehouse to store failed rows, with Soda Cleanse deployed.

Here’s how the data quality part of a steward’s day runs in Soda.

Find: Detect Issues Automatically and Continuously

Triaging the Work Queue: Soda Cloud Dashboards

The day starts in Soda Cloud dashboards (public beta). The overview answers the wide questions first: is data quality health improving, how much of the estate has a contract or metric monitors, and which data sources need attention first. Filtered by data source, dataset, owner, or domain, it narrows to the data the steward is responsible for. The Steward view, built as the start of a shift, turns that into a working queue: which datasets have failing checks, how many rows passed and failed in each, and where anomalies are happening.

Three things sit on a typical morning triage list:

• Anomalies flagged by metric monitoring. Red markers on the metric time series show deviations the automated detection caught overnight. One click opens the detail panel with the historical trend, so the steward can mark the point as expected (feeding the model’s learning loop) or escalate it to an incident.

• Incidents in progress. The steward or a teammate opens an incident from a check or monitor result and assigns a lead. Filtered by lead, status, or severity, the Incidents view lists the ones the steward is working on.

• Requests from data consumers. Analysts and business users can propose a rule change by opening a request on the dataset, and the dataset owner is emailed when one arrives.

From here, the steward picks the items that will shape the day. Smart Alerting decides who hears about what: notification rules send each alert straight to the owners of the affected data, so the steward stops being the one who forwards it.

Stewards don’t have to log in to Soda to follow the results. Check results also show up in the catalog they already use, such as Atlan or Alation, alerts reach them in Slack or Teams, and incidents sync with Jira.

Soda gives stewards two lenses on the same data: rule-based (data contracts encode what “good” looks like in advance) and behavioral (data observability catches anomalies that don’t violate any rule but fall outside the dataset’s normal pattern).

Monitoring Data Behavior: Metric Monitoring

Once the steward onboards a new dataset, baselines and trends are there from the first day, not after weeks of training: Soda backfills past metrics. How far back depends on the monitor and the warehouse; schema changes are tracked from onboarding onward.

Each scan afterwards will add onto that context. The metric monitoring dashboard surfaces deviations or anomalous behavior in the datasets as each scheduled scan completes. Monitors work at two levels.

Dataset monitors:

• Row volume changes

• Data freshness delays

• Schema evolution (added, missing, or changed columns)

Column monitors (these need a time partition column):

• Spikes in missing values

• Increases in duplicates

• Shifts in numeric averages

Here, the steward’s main job is to fit each monitor to how its dataset actually behaves. Changes apply from the next evaluation; past results keep their original verdicts, so a threshold change never rewrites the record an auditor reads.

The three configurations you can use to fine-tune results are:

1. Threshold Strategy: Some datasets require strict oversight of drops, while surges create no real risk. If your metric behaves this way, you enable the lower range and focus only on downward movement.

2. Exclusion Values: Known, harmless readings, such as a row count of zero on a planned maintenance day or a placeholder value that keeps recurring, can look like anomalies. Add that value or range as an exclusion, and Soda leaves it out of anomaly evaluation.

3. Sensitivity: Some datasets behave predictably, and you may want alerts for even the slightest discrepancy. For those, set a tighter alert threshold (lower z-score). Other datasets shift naturally, so a higher z-score broadens the band and highlights only the biggest movements.

Soda handles the pattern recognition while you shape what “important” means for your team.

Defining Expectations: Data Contracts

A data contract is an executable agreement that validates data as it flows. When the data matches the contract, it moves downstream. When it doesn’t, the check fails, and your pipeline acts on that result: it stops the release, or it lets the data through and sends an alert, depending on how strict you want enforcement to be.

Soda’s no-code data contracts let data stewards turn written policies into executable rules.

Schema, freshness, rules, and thresholds all live in the dataset’s contract. Soda verifies the data against the contract on a schedule or inside a pipeline run, and both sides, technical and business, see the same result.

Contract Copilot adds, changes, or removes checks on an existing contract from a plain-English request and shows the diff before it’s applied, so the steward can turn a policy into rules without writing SQL. Compound and conditional rules can still need custom SQL.

The no-code view and the YAML view are the same contract. A steward with Manage contract on a dataset publishes the change directly. With only Propose checks, the steward opens a request instead, and the dataset owner, whether an engineer or a steward, reviews the diff and publishes it. Teams that keep contracts in Git fetch the approved proposal into their repository and commit it.

Understand: Investigate Issues with Full Context

Investigating an Anomaly: Incident Management

Data quality issues arrive from scattered sources: dashboards, Slack threads, ad hoc reports, and pipeline failures. Each one arrives with limited context and threatens to spread to other systems.

Without a single workflow, stewards end up asking “Did this start today?” or “Who touched this table?” and spend more time reconstructing the timeline than resolving the issue.

Soda has a single-window workflow for this entire process. When the anomaly detection model highlights an unusual metric value, you see the signal immediately in red on the time series.

Start on a free account with metric monitoring and alerting. No-code contracts and Contract Copilot start on the Team plan.

One click opens a detail panel with the metric, the values involved, and the historical trend out of which the anomaly has sprung up. If the behavior aligns with known patterns or business activity, you mark the point as expected. The model learns from that feedback, so similar variations stop triggering alerts.

If the point requires deeper investigation, you create an incident directly from the same panel. The incident form opens with the essential fields: title, description, and linked dataset context. Soda records who reported it, when it occurred, and which check or metric triggered it.

The entire chain stays intact, and this structure replaces the ad hoc investigations that usually hide in chats.

You can also continue the workflow in the Incidents tab, where you can assign a lead, define severity, and set the status. Slack, Jira, and Teams integrations extend the workflow further.

Fix: Resolve What Failed

Prioritizing and Remediating Issues: Soda Cleanse

Soda built agentic data cleansing on top of the same platform that powers data contracts and observability. Soda Cleanse is an add-on to Soda Cloud, available in private preview, and runs in your own Kubernetes cluster.

Soda Cleanse picks up the failed records the contract checks catch, proposes a fix wherever the check carries a remediation strategy, and waits for the steward to decide. It works in three steps:

Ingest

After every scan, Soda Cleanse turns each failed value in a failed row into an Issue. How each one gets fixed is set on the check itself, in the data contract, as a remediation strategy:

• Constant: one fixed value for every failed row.

• SQL: a lookup query against your data, such as a reference table.

• LLM: a model proposes a value from your prompt and the failed row, and can consult linked reference data or call tools such as web search.

• Manual: no proposal; the steward enters the value.

Duplicate checks take only the LLM or Manual strategy. Cleanse groups the matching records into one issue, and with LLM, the model picks the record to keep for the steward to confirm.

These failures show up everywhere: variant counterparty names in finance, duplicate accounts in CRM, missing fields in customer master. Different datasets, one strategy per check.

Propose

Once an admin runs Remediate on the dataset, the steward’s Inbox shows each issue with the row’s context, the suggested fix, its confidence score, and a plain-language explanation. Below the confidence threshold set on the check’s remediation strategy, Cleanse proposes no value and the steward enters the fix by hand.

Approve

The steward approves, edits, or skips every proposed fix. Nothing changes without steward sign-off, and every decision lands in the audit trail. Approving doesn’t write anything on its own: approved fixes wait in the Fix Queue until someone clicks Write All, which sends them to the dataset’s fix destination. For warehouse data, that’s a separate fixes table, never the source table, so Cleanse never needs write access to the source. For Salesforce data, Cleanse updates the Salesforce records directly.

From a fixes table, your team decides when corrected values reach the source. Once the row passes a later scan, its issue is marked Outdated. If the row fails again, the issue reopens with its history instead of arriving as a new ticket.

What Changes for the Steward

Here’s what changes in the data quality part of the job.

The data steward workflow shown above isn’t tied to one industry or data maturity level. Any organization with critical data elements and named owners, whether stewards, record owners, or business leads accountable for a domain, will recognize the same pressure points: definitions drifting, incidents piling up in Slack, engineers inheriting governance work they didn’t sign up for, audit evidence assembled by hand.

The data quality part of the steward’s day runs on one loop (find, understand, fix), with an audit trail that’s already written by the time the work is done. No spreadsheet relay, no one-off fix scripts, no audit evidence to reassemble at month-end.

If you’re a data steward, record owner, or business lead tired of being the manual middleman between detection and fix, book a demo to walk through it with your team’s data.

Frequently Asked Questions