I've spent years watching travel technology teams struggle with a fundamental paradox: the more data we collect, the less confident we become in its accuracy. Airline schedules, fare feeds, availability snapshots—these datasets power billions in revenue, yet I've seen major platforms make critical business decisions based on data they couldn't truly trust.
The challenge isn't just technical. It's organisational, cultural and deeply human. When a schedule change affects 50,000 passengers, or when fare data drifts silently out of sync, the consequences ripple through customer experience, operational efficiency, and ultimately, brand reputation. I've learned that data quality at scale isn't about perfection—it's about building systematic trust in imperfect systems.
Why Traditional Data Quality Approaches Fail in Travel
Early in my career, I believed that rigorous schema validation and comprehensive unit tests would solve data quality problems. I was wrong. Travel data is uniquely chaotic. Airlines update schedules constantly. Airport codes change. Fare rules contradict each other across distribution channels. The IATA standards we rely on are interpreted differently by every carrier.
Traditional quality assurance treats data as static. You define expected formats, validate inputs, and reject anything that doesn't conform. But airline schedule data is dynamic and context-dependent. A flight number that's valid today might be retired tomorrow. A route that seems impossible—say, a direct connection between two cities with no historical precedent—might actually represent a new seasonal service.
I've watched teams spend months building custom validation frameworks, only to see them become maintenance nightmares. Rules proliferate. Edge cases multiply. The validation layer becomes more complex than the data pipeline itself. Meanwhile, subtle quality issues—gradual drift in availability accuracy, systematic biases in fare calculations—slip through undetected because nobody thought to test for them.
The fundamental problem is that we've been asking the wrong question. Instead of "Is this data valid?", we should ask "Can we trust this data to support the decisions we're making?"
The Great Expectations Revolution
When I first encountered Great Expectations, I was sceptical. Another data validation library? We had dozens already. But its philosophy was different, and it fundamentally changed how I think about quality assurance in data pipelines.
Great Expectations shifts the conversation from validation to expectation. Rather than defining rigid rules, you declare what you expect your data to look like—and the framework helps you discover when reality diverges from expectation. It's a subtle distinction, but profound in practice.
For airline schedule data, this matters enormously. I don't need to know every possible valid flight number format across 300 airlines. Instead, I declare expectations: flight numbers should follow patterns consistent with historical data, departure times should fall within reasonable ranges, aircraft types should match the routes they're assigned to. When something unusual appears—not necessarily invalid, just unexpected—the system flags it for review.
The real power emerges when you treat expectations as living documentation. Every expectation becomes a test, yes, but also a specification of what "normal" means for your data. When I onboard a new team member, they can read through our expectation suites and understand not just the technical schema, but the business logic and domain knowledge embedded in our quality checks.
I've built expectation suites that validate airline schedule feeds across dozens of dimensions: temporal consistency, referential integrity between related tables, statistical distributions of fare prices, even semantic coherence in marketing descriptions. Each expectation captures a lesson learned from past quality incidents. The suite becomes institutional memory, encoded in executable form.
Monte Carlo and the Observability Paradigm
Great Expectations solved my pipeline-level quality problems, but it left a gap. What happens after data lands in the warehouse? How do I know if a dashboard that looked fine yesterday is now showing stale data? How do I detect when a critical metric suddenly stops updating?
This is where data observability platforms like Monte Carlo changed my thinking entirely. Rather than treating quality as something you enforce at ingestion, observability treats it as something you monitor continuously across the entire data estate.
I think of it as the difference between airport security and air traffic control. Great Expectations is like security—you check everything thoroughly as it enters the system. Monte Carlo is like air traffic control—you watch everything that's already in flight, looking for anomalies, delays, and potential collisions.
The observability approach uses machine learning to establish baselines for normal behaviour. How often does this table update? What's the typical row count? What's the usual distribution of values in this column? Once baselines are established, the system alerts you when something deviates quite significantly.
For travel platforms, this catches an entire class of issues that traditional validation misses. A fare feed might be technically valid but systematically biased toward higher prices. A schedule update might arrive on time but contain fewer routes than expected. An availability snapshot might have correct formats but show suspiciously uniform capacity across all flights.
I've used Monte Carlo to monitor data freshness across hundreds of tables, ensuring that schedule updates propagate through our entire platform within SLA windows. I've set up anomaly detection on key business metrics—booking conversion rates, average fare calculations, inventory accuracy—that alert me when something shifts unexpectedly, even if all the underlying data passes validation.
The combination of Great Expectations and Monte Carlo creates a comprehensive quality framework. Expectations ensure that data entering your pipelines meets known standards. Observability ensures that data already in your systems remains trustworthy over time.
Building Trust Through Transparency
The most important lesson I've learned about data quality isn't technical—it's cultural. Quality frameworks only work when teams trust them, and trust only develops through transparency.
I've made a practice of exposing quality metrics directly to the business teams who depend on our data. Not buried in technical monitoring dashboards, but presented in language they understand. "Schedule data is 99.7% complete today" means something to a product manager. "Fare accuracy has drifted 2% below baseline this week" triggers the right conversations with commercial teams.
This transparency works both ways (and the data bears this out). When data quality issues occur—and they always do—I've learned to communicate them proactively. Not with excuses or technical jargon, but with clear impact assessments and remediation plans. "Yesterday's schedule update affected 3,200 bookings. We've identified the root cause and implemented additional validation. Affected customers will be notified within 24 hours."
I've also found that involving domain experts in defining expectations dramatically improves quality outcomes. Revenue management teams know what fare patterns should look like. Operations teams understand schedule constraints. Customer service teams spot inconsistencies that slip past technical validation. Their expertise, encoded as expectations, becomes a force multiplier for the entire engineering organisation.
Scaling Quality Across Distributed Teams
As travel platforms grow, data quality becomes a distributed challenge. You're not maintaining one pipeline—you're orchestrating dozens of teams, each building their own data products, each with their own quality requirements.
I've seen this scale problem break quality programs entirely. Central data teams try to impose uniform standards, but they can't keep up with the pace of product development. Individual teams build their own quality checks, but they're inconsistent and often duplicative. Quality becomes everyone's responsibility, which in practice means it's no one's priority.
The solution I've converged on is federated ownership with centralised tooling. Each team owns quality for their own data products, but everyone uses the same frameworks and patterns. Great Expectations provides the common vocabulary. Monte Carlo provides the shared observability layer. Central platform teams provide the infrastructure and best practices, but product teams make the actual quality decisions.
This requires treating quality tooling as a product itself. I've built self-service interfaces for defining expectations, templates for common validation patterns, automated reports that highlight quality trends across teams. The goal is to make doing the right thing easier than cutting corners.
I've also learned that incentives matter enormously. When quality metrics are visible and tied to team objectives, behaviour changes. When quality incidents trigger blameless postmortems that focus on systemic improvements rather than individual fault, teams engage constructively. When senior leadership asks about data quality in business reviews, it signals that quality isn't just an engineering concern—it's a business imperative.
The Future of Quality in Travel Data
Looking ahead, I see data quality evolving from reactive validation to proactive prediction. Machine learning models that predict quality issues before they occur. Automated remediation that fixes common problems without human intervention. Quality metrics that adapt dynamically to changing business contexts.
I'm particularly excited about the intersection of quality and lineage. Understanding not just whether data is accurate, but tracing exactly how it flowed through complex pipelines to reach its final form. When a quality issue emerges, lineage lets you work backwards to find the root cause—and forward to identify all downstream impacts.
I'm also watching developments in semantic quality checks—validations that understand business logic, not just technical formats. Checking that fare rules are internally consistent. Verifying that schedule changes make operational sense. Detecting when marketing copy contradicts availability data. These higher-order validations require domain knowledge that's difficult to encode, but I believe they represent the next frontier in quality assurance.
My View on Quality as Competitive Advantage
I've come to believe that data quality is the most underappreciated competitive advantage in travel technology. Everyone focuses on feature velocity, infrastructure scale, or algorithmic sophistication. But none of that matters if your data isn't trustworthy.
The platforms that win in travel are those that make better decisions faster. Better decisions require better data. Better data requires systematic quality assurance. It's not glamorous work—there's no viral blog post about incremental improvements to validation coverage—but it's foundational.
I've seen firsthand how quality programs transform organisational capability. Teams move faster because they trust their data. Product decisions improve because they're based on reliable insights. Customer experience stabilises because systems behave predictably. Technical debt decreases because quality issues are caught early, before they cascade into architectural problems.
Building trust in data at scale is hard work. It requires sustained investment, cultural change, and technical sophistication. But for travel platforms operating in increasingly complex and competitive markets, it's not optional. The question isn't whether to invest in quality—it's whether you're investing enough, soon enough, to stay ahead.
About Martin Tuncaydin
Martin Tuncaydin is an AI and Data executive in the travel industry, with deep expertise spanning machine learning, data engineering, and the application of emerging AI technologies across travel platforms. Follow Martin Tuncaydin for more insights on data quality, airline technology.
Top comments (0)