Every data leader has heard some version of the same complaint: the revenue figure in the executive dashboard does not match the one finance reports, so nobody believes either. Once trust erodes, people export data to spreadsheets, rebuild their own versions of the truth and quietly ignore the platform the organization spent years building. In 2026 the stakes are higher, because the same data now feeds AI assistants, forecasting models and agents that act on it. Errors that a human analyst might have caught are repeated confidently and at scale.
Gartner put the risk bluntly in early 2025: in a survey of 1,203 data management leaders, 63% said their organizations either lacked or were unsure they had the right data management practices for AI, and Gartner predicted that through 2026 organizations will abandon 60% of AI projects unsupported by AI-ready data. The good news is that trust can be rebuilt within a focused quarter, provided you stop trying to fix everything and instead fix the data that matters most, visibly and measurably. This article lays out a 90-day plan you can adapt, with deliverables for each phase, the roles involved and the metrics that prove progress.
Why Data Trust Breaks Down
The causes are rarely exotic. In most organizations, the same handful of problems account for the bulk of incidents:
- No clear ownership. Issues bounce between source system teams, data engineers and analysts because nobody is accountable for a dataset end to end.
- Silent upstream changes. Applications change schemas, codes or business logic without telling downstream consumers, and pipelines either break or, worse, keep running with wrong results.
- Conflicting definitions. “Active customer,” “net revenue” or “churn” mean different things in different reports, so numbers disagree even when the data is technically correct.
- Silent failures and staleness. Jobs fail or load partial data, and a stale dashboard looks exactly like a fresh one.
- Scattered, low-value checks. Where tests exist, they are spread across scripts, nobody reviews the results and failures are not tied to business impact.
A credible program must address ownership, definitions, prevention and detection together. Buying an observability tool without the other three typically produces more alerts, not more trust. Tools matter, and we cover them in data observability in 2026 and AI-assisted data quality, but they work only on top of the operating basics this plan establishes.
Principles That Keep the Plan Focused
- Scope by business impact. Start with one or two high-visibility domains, such as revenue reporting or customer data, and their critical data elements. Ten well-governed metrics beat a thousand unmonitored tables.
- Make quality visible. Publish scores and incident status where consumers can see them. Visibility builds trust faster than private fixes.
- Prevent at the source where possible. Every issue caught at entry or at the producer boundary is cheaper than one caught in a dashboard.
- Treat data issues like production incidents. Use severity levels, owners, response targets and post-incident reviews, just as software teams do.
- Encode rules as code. Quality rules, contracts and service levels should live in version control, be reviewed like code and run automatically.
Who is involved, and how much time it takes
The plan works with a small core team rather than a large program office. Expect the data steward and lead data engineer to spend most of their time on the program, the business owner to commit a few hours a week for definitions, prioritization and sign-off, and producing application teams to join for contract and root-cause discussions. The executive sponsor’s role is to clear obstacles, especially when a fix requires a source system team to change its backlog, and to attend the day-30, day-60 and day-90 checkpoints. Keeping the team small is deliberate: it forces prioritization and makes accountability obvious.
Budget for tooling only where it removes clear manual effort. Many organizations already own a transformation framework with testing support, a catalog and a monitoring stack; the first quarter is usually better spent wiring those together around the critical data elements than evaluating new platforms.
Trust is not restored by a cleanup project. It is restored when consumers can see that critical data is owned, tested, monitored and fixed quickly when it breaks.
Days 1–30: Focus, Ownership and Baseline
The first month is about choosing where to fight and establishing who is accountable. Resist the temptation to start writing tests on day one.
Week 1: Pick the domain and assemble the team
Select one domain where distrust is visible and the business impact is clear: for example, the monthly revenue and bookings reporting that the leadership team reviews. Appoint an executive sponsor, a business data owner who is accountable for the domain, a data steward who handles definitions and day-to-day issues, and a lead data engineer. Agree on a simple charter: what is in scope, what success looks like at day 90 and how the team will report progress.
Week 2: Identify critical data elements
Work backward from the decisions and reports that matter. List the 10 to 25 metrics and fields that drive them, such as booking amount, booking date, customer identifier, product code, currency and region. For each, trace lineage from the dashboard back to the source system, so you know every table, transformation and team it passes through.
Week 3: Agree on definitions
Run short working sessions with finance, sales operations and analytics to define each metric in business terms and in logic: what counts, what is excluded, which timestamp applies and which source is authoritative. Record definitions in the business glossary or catalog and, ideally, in a semantic layer so dashboards and AI tools use the same logic. Disagreements surfaced here are not a problem; they are the root cause of most “the numbers do not match” complaints.
Week 4: Measure the baseline
Profile the critical data elements across standard quality dimensions: completeness, validity, uniqueness, consistency across systems, timeliness and accuracy against a trusted reference. Log the incidents users reported in the last quarter and estimate their impact. The output is a baseline scorecard and a ranked list of the top issues, which will be uncomfortable but gives the program something concrete to improve.
Day 30 deliverables
- Named owners and stewards for the domain and its critical data elements
- Approved definitions for the in-scope metrics, published in the catalog
- End-to-end lineage for each critical data element
- Baseline quality scorecard and a prioritized issue backlog
- Agreed day-90 targets, for example quality scores, freshness and incident response times
Days 31–60: Prevent and Detect
With focus and ownership in place, the second month builds the controls that stop bad data and catch what slips through.
Data contracts at the producer boundary
For each source feeding the domain, agree on a data contract with the producing team that specifies schema, semantics, quality expectations and service levels such as freshness and availability. Open standards make contracts portable and machine-checkable. The Open Data Contract Standard, now hosted under the Linux Foundation’s LF AI & Data, released version 3.1.0 in December 2025, adding relationships between properties and the ability to schedule SLA checks for latency, retention, availability, frequency and completeness alongside quality rules. Start with the two or three sources responsible for most incidents and add schema checks to the producers’ deployment pipelines so breaking changes are caught before release. Our article on data contracts and ODCS goes deeper.
Tests in the pipeline
Encode quality rules as automated tests that run with every pipeline execution. In dbt, for example, the documentation describes data tests as queries that return failing rows, with built-in generic tests for uniqueness, non-null values, accepted values and referential relationships, plus singular tests for custom business rules. Severity can be set to warn or error, thresholds can be configured, and failing rows can be stored for investigation. A practical starting set for each critical table includes:
- Primary key uniqueness and non-null checks on every model, as dbt recommends
- Referential integrity between facts and key dimensions, such as bookings to customers and products
- Accepted values for status codes, currencies and regions
- Business rules, for example booking amounts are positive and booking dates are not in the future
- Reconciliation checks that compare row counts and control totals with the source system
- Freshness checks on sources, with thresholds tied to the reporting schedule
Decide which failures block downstream processing and which only warn. Blocking a revenue table because a single optional field is null erodes trust as surely as bad data does.
Monitoring for the unknowns
Rules catch the problems you anticipate. Add monitoring for volume, freshness, schema changes and distribution shifts on critical tables to catch the ones you do not. Route alerts to the owning team’s channel, not a shared inbox, and tune thresholds during this month to keep noise low.
Fix the top issues at the root
Work the prioritized backlog from month one. For each issue, fix the cause rather than patching the symptom downstream: add validation in the source application, correct a reference data mapping, or change a transformation. Communicate each fix to the affected consumers, which is one of the most effective trust-building actions available.
Days 61–90: Operationalize and Prove
The final month turns controls into routine operations and makes improvement visible.
Incident management
Define severity levels based on business impact, response and resolution targets, and a simple workflow: detect, acknowledge, communicate to consumers, resolve, review. Display a status indicator on key dashboards, so users know when data is delayed or under investigation rather than discovering it themselves. Run blameless reviews for high-severity incidents and track recurring causes.
Quality scorecards
Publish a scorecard for the domain showing quality by dimension for each critical data element, freshness against service levels, open incidents and trends since the baseline. Keep it simple enough for business owners to read in a minute, and link each score to the rules behind it for those who want detail.
Governance rhythm
Set up a short monthly data quality review with the owner, steward and engineering lead, covering scores, incidents, contract changes and the backlog. Add a quarterly review with the sponsor to decide on scope expansion. Make sure definition changes follow a simple approval process, so metric logic does not drift again.
AI readiness check
If the domain feeds AI use cases, extend the controls to what those systems consume. Gartner’s guidance on AI-ready data emphasizes aligning data to specific use cases, making metadata active, preparing pipelines for both training and live feeds, and continuously testing and monitoring. In practice, that means confirming that definitions and quality signals are exposed as metadata an assistant or agent can read, that freshness service levels match how the AI feature is used, and that known gaps are documented rather than hidden.
Day 90 deliverables
- Data contracts in place for the highest-risk sources, with automated schema checks
- Automated tests and monitoring covering all critical data elements
- An incident process with severity levels, owners and dashboard status indicators
- A published scorecard showing improvement against the baseline
- A recurring governance rhythm and a plan for the next domain
Metrics That Prove Trust Is Returning
Choose a small set of measures and report them consistently:
- Quality score for critical data elements, by dimension, against the baseline
- Freshness service level attainment, the share of loads delivered on time
- Incidents detected by the data team versus reported by users; the goal is for most issues to be caught before consumers notice
- Mean time to detect and resolve high-severity incidents
- Contract coverage of sources feeding the domain
- Adoption signals, such as dashboard usage and a decline in shadow spreadsheets or reconciliation requests
Worked Example: Revenue Reporting at a Subscription Business
Picture a hypothetical subscription software company where the board pack and the sales dashboard show different monthly recurring revenue figures. In the first month, the team discovers three definitions of recurring revenue in use, two of which count trial conversions differently, and lineage reveals that one dashboard reads from a stale copy of the billing data. Finance is named business owner, a revenue operations analyst becomes steward, and a single definition is approved and implemented in the semantic layer.
In the second month, the billing team agrees on a data contract covering plan codes, currency and invoice status, with a schema check in its release pipeline. Data tests verify subscription uniqueness, valid plan codes and positive amounts, and a daily reconciliation compares invoice totals between billing and the warehouse. Monitoring flags a sudden drop in invoice volume one morning, which turns out to be a failed export caught before the weekly sales meeting.
By day 90, both dashboards read the same governed metric, a status badge shows data freshness, and the scorecard shows clear improvement on the baseline. Most incidents are now detected by the data team rather than by sales leaders. The next domain, customer master data, is chosen for the following quarter using the same playbook.
Pitfalls to Avoid
- Boiling the ocean. Enterprise-wide programs without a beachhead domain rarely show results within a year.
- Tool first, ownership later. Monitoring without owners produces ignored alerts.
- Hundreds of low-value tests. Too many trivial checks create noise and alert fatigue; focus on rules tied to business impact.
- Fixing downstream only. Patching data in the warehouse without fixing the source guarantees recurrence.
- Hiding problems. Consumers forgive known, communicated issues far more readily than surprises.
- Stopping at day 90. The first domain proves the model; trust across the organization comes from repeating it domain by domain.
Conclusion: Earn Trust One Domain at a Time
Rebuilding trust in data is less about technology than about focus and discipline. Choose the domain where distrust is most visible, name owners, agree on definitions, put contracts and tests where errors originate, monitor for the unexpected and run quality like a production service with visible scores and fast incident response. Ninety days is enough to prove the model in one domain and show measurable improvement. Repeat it, and the organization gains something no new platform can deliver on its own: data people are willing to stake decisions, and AI systems, on.
How Hanoi Technology Can Help
Hanoi Technology helps teams run focused data quality programs, from critical data element mapping and data contracts to automated testing, monitoring and managed data operations.