DEV Community: Martin Tuncaydin

Applying RAG Architectures to Travel Knowledge Bases: A Practitioner's View

Martin Tuncaydin — Mon, 13 Apr 2026 09:01:13 +0000

The Challenge of Travel Domain Knowledge at Scale

I've spent years wrestling with a fundamental problem in travel technology: how do you make decades of accumulated domain knowledge—fare rules, GDS content taxonomies, destination databases, carrier-specific policies—actually accessible when it matters? The traditional approach has been to build ever-more-complex search interfaces, maintain sprawling documentation wikis and rely on subject matter experts who carry institutional knowledge in their heads. Every time.

That model doesn't scale (which surprised me, honestly). I've watched talented engineers spend hours hunting through PDF manuals for obscure fare construction rules. I've seen customer service teams struggle to answer nuanced questions about baggage policies across codeshare agreements. The information exists, but retrieval is the bottleneck.

Retrieval-augmented generation fundamentally changes this equation. Instead of hoping users formulate the right search query or know which documentation section to check, RAG architectures allow us to pose natural language questions and receive contextually grounded answers drawn from our actual knowledge corpus. For travel technology, where precision matters and hallucination can mean financial liability, this isn't just convenient—it's transformative.

Why Travel Content Is Uniquely Suited to RAG

Travel industry knowledge has characteristics that make it an ideal RAG use case, and I've come to appreciate these properties through direct experience:

Highly structured yet narrative-rich. GDS content includes ATPCO fare rules written in semi-structured text, IATA location codes paired with descriptive metadata, and carrier policies that blend regulatory requirements with commercial positioning. This hybrid nature—structured enough for systematic retrieval, narrative enough for semantic understanding—fits perfectly with modern embedding models.

Time-sensitive and versioned. Fare rules change. Alliance partnerships shift. Airport facilities are upgraded. I've learned that effective RAG in travel must handle temporal validity—retrieving the right version of a rule that was active during a specific booking window. This requires metadata tagging at ingestion and careful prompt engineering to specify temporal context.

Multi-modal by nature. Travel content spans text (policies, descriptions), tabular data (fare matrices, schedule tables), and semi-structured formats (XML messages, JSON API responses). I've found that chunking strategies must respect these modalities—you can't treat a fare calculation table the same way you'd chunk a destination guide paragraph.

Domain-specific terminology. The travel industry speaks its own language: PNR, ATPCO, GDS, FQTV, MCT. Standard language models trained on general corpora struggle with this vocabulary. But when you fine-tune embeddings on domain-specific content or use RAG to provide contextual examples, accuracy improves dramatically.

Architectural Patterns I've Applied

Building RAG systems for travel knowledge isn't a single architectural decision—it's a series of design choices that compound. Here's what I've learned works:

Chunking Strategy for Heterogeneous Content

Naive chunking—splitting documents every 512 tokens—fails spectacularly with travel content. I've adopted a content-aware approach:

For fare rule documents, I chunk by rule category (advance purchase, minimum stay, cancellation penalties) rather than arbitrary token counts. Each chunk becomes semantically coherent and retrievable as a complete unit of policy.

Is the investment worth it? In most cases, yes. For GDS reference material, I preserve hierarchical structure. A section on baggage allowances might include multiple sub-policies (cabin class variations, route exceptions, loyalty tier overrides). I embed both the parent section and child sections, creating overlapping context that improves retrieval recall.

For destination content, I chunk by logical topic (climate, entry requirements, local customs, transportation options) and enrich each chunk with metadata: geographic coordinates, relevant travel seasons, language codes. This allows hybrid retrieval—semantic similarity plus metadata filtering.

Embedding Model Selection and Fine-Tuning

I've experimented extensively with embedding models for travel content. Off-the-shelf models like those from OpenAI and Cohere perform adequately, but I've seen measurable improvements from domain adaptation:

Creating a synthetic training set from actual travel queries and their known-good document matches, then fine-tuning a sentence transformer model, has improved retrieval precision by 15-20% in my tests. The model learns that "Can I change my ticket?" should strongly match cancellation and modification policies, not just any mention of tickets.

I've also found value in multi-lingual embeddings for global travel content. A customer asking about visa requirements in German should retrieve the same core information as an English query. Models like multilingual MiniLM or commercial offerings from Cohere handle this well, though I always validate performance in each target language independently.

Retrieval Strategies Beyond Semantic Search

Pure vector similarity isn't enough for travel RAG. I layer multiple retrieval strategies:

Hybrid search combining dense vectors with sparse keyword matching (using BM25 or Elasticsearch) catches exact matches for codes and identifiers. When someone asks about "LHR airport", I want to guarantee retrieval of content tagged with that specific code, not just semantically similar airport descriptions.

Metadata filtering pre-constrains the retrieval space. If a query implies "European destinations", I filter the vector search to only European location codes before ranking by similarity. This prevents irrelevant but semantically similar content from other regions.

Re-ranking with cross-encoders improves precision. After retrieving 20 candidate chunks via vector similarity, I re-rank them using a cross-encoder model that evaluates query-document relevance more deeply. This two-stage approach balances retrieval speed with accuracy.

Prompt Engineering for Travel Domain Accuracy

The prompt is where RAG systems live or die. I've learned that generic "answer based on the context below" prompts produce mediocre results with travel content. Effective prompts must:

Specify the role and constraints. I instruct the model to act as a knowledgeable travel advisor who only uses the provided context and explicitly states when information is incomplete. This reduces hallucination—critical when the output might inform a booking decision.

Provide structured output formats. For fare rule queries, I ask for answers structured as: applicability, restrictions, exceptions, and examples. This consistency helps downstream systems parse and display the information appropriately.

Include few-shot examples. I've found that showing the model 2-3 examples of well-formed travel Q&A pairs dramatically improves output quality. The model learns the expected level of detail and citation style.

Handle ambiguity explicitly. Travel queries are often underspecified: "What's the baggage allowance?" (Which route? Which cabin? Which carrier?) I prompt the model to identify ambiguities and ask clarifying questions rather than making assumptions.

Practical Challenges and Mitigations

Building production RAG systems for travel knowledge has taught me hard lessons:

Version control and auditability. When a fare rule changes, I need to know which version of the rule was active when a specific query was answered. I've implemented content versioning at the chunk level with effective-date metadata and maintain a retrieval audit log that captures which chunks influenced each response.

Latency constraints. Travel bookings are time-sensitive. I've optimised for sub-second retrieval by using approximate nearest neighbour indexes (HNSW via FAISS or Pinecone), caching frequent queries, and pre-computing embeddings for all content at ingestion time rather than query time.

Handling negation and exceptions. Travel rules are full of exceptions: "This fare allows changes except on routes involving Australia except for Qantas-operated segments". Standard retrieval can miss these nuances. I've found that including both the base rule and exception clauses in the same chunk, with clear structural markers, helps the generation model reason through them correctly.

Cost management. Embedding large travel knowledge bases and running inference at scale isn't free. I've reduced costs by batching embedding operations, using smaller models where appropriate (not every query needs GPT-4), and implementing smart caching of both embeddings and generated responses for common questions.

Real-World Application Patterns

I've seen RAG architectures deliver value across several travel use cases:

Internal knowledge assistants for customer service teams—answering complex policy questions without requiring staff to navigate multiple systems or documentation sources. Response time drops from minutes to seconds, and accuracy improves because the model cites specific rule sections.

Fare rule explainability for booking platforms—automatically generating customer-friendly explanations of why certain fares are non-refundable, what change fees apply, or what restrictions govern award ticket redemption. This transparency builds trust and reduces support inquiries.

Destination discovery and planning where RAG systems synthesise information from multiple sources—visa requirements, seasonal weather patterns, local events, transportation options—into coherent, personalised trip planning advice.

GDS command assistance for agents learning reservation systems—providing contextual help with cryptic terminal commands by retrieving relevant examples and syntax from training materials based on natural language questions.

My View on the Future of Travel Knowledge Systems

I believe we're at an inflection point. The travel industry has accumulated vast knowledge assets—regulatory databases, operational procedures, product content, historical performance data—but most of it remains locked in formats designed for human navigation, not machine reasoning.

RAG architectures offer a path forward that doesn't require re-platforming everything. We can wrap existing knowledge bases with retrieval and generation layers, making legacy content newly accessible and useful. The key is treating RAG not as a black box but as an engineering discipline: carefully designed chunking, thoughtful embedding strategies, rigorous prompt engineering, and continuous evaluation against real-world queries.

The most exciting opportunity, in my view, is using RAG to surface insights that span multiple knowledge domains. A question like "What's the optimal routing and fare combination for a round-trip to Southeast Asia in monsoon season with a focus on sustainable tourism?" requires synthesising weather data, routing options, fare rules, and destination sustainability profiles. RAG systems that can orchestrate retrieval across these heterogeneous sources and reason over the combined context represent a genuine leap forward.

I'm not naive about the challenges—hallucination risk, latency constraints, cost management, regulatory compliance. But I've seen enough production deployments now to know that RAG, applied thoughtfully with domain expertise, fundamentally improves how travel knowledge is accessed and applied. The industry's decades of accumulated expertise can finally be made available at the moment of need, in the format that's most useful, without requiring users to become domain experts themselves.

That's a future worth building toward.

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 rag, travel-technology.

Building a Real-Time Travel Data Platform with Apache Kafka and Flink

Martin Tuncaydin — Fri, 10 Apr 2026 09:00:58 +0000

The travel industry operates on razor-thin margins where a seat unsold is revenue lost forever. I've spent years building data platforms that capture booking events, inventory changes and pricing signals as they happen—not hours later in a batch report. The difference between streaming and batch isn't just architectural; it's the difference between reacting to market conditions and discovering them after the opportunity has passed.

Why Real-Time Matters in Travel Distribution

When I first started working with travel data systems, most platforms processed booking confirmations overnight. Revenue managers would arrive in the morning to discover they'd been selling seats at yesterday's prices while competitors adjusted dynamically. Inventory systems would show availability that had already been sold through alternative channels. The disconnect between operational reality and data visibility was costing millions.

Real-time streaming architecture solves this by treating every booking, cancellation, and price change as an event that flows through the system immediately. Apache Kafka has become the de facto standard for this event backbone, not because it's trendy, but because it handles the unique demands of travel data: high throughput during peak booking windows, guaranteed ordering of events for the same inventory item, and the ability to replay historical events when new analytics models need training data.

I've seen platforms processing hundreds of thousands of booking events per hour across dozens of sales channels—direct websites, mobile apps, global distribution systems, metasearch engines, and affiliate networks. Each channel generates its own event stream, and they all need to converge into a coherent view of what's actually happening with inventory and revenue.

Designing Event Streams for Travel Operations

The architecture I've built centres on three primary event streams: booking lifecycle events, inventory state changes, and dynamic pricing signals. Each serves a distinct operational purpose, but they're deeply interconnected.

Booking lifecycle events capture the full journey from search to post-trip feedback. A single booking might generate twenty events: initial search, seat selection, ancillary purchases, payment authorization, confirmation, check-in, boarding, and eventual completion. I structure these events with a common schema that includes correlation identifiers linking all events for a single journey, temporal markers for event time versus processing time, and enrichment metadata that downstream consumers might need.

The schema design matters enormously. I've learned to include not just the state change, but sufficient context for consumers to make decisions without additional lookups. A seat selection event includes not just the new seat assignment, but the previous seat, the passenger profile, the fare class, and the remaining inventory in that cabin. This denormalization feels wasteful until you realize it eliminates hundreds of thousands of database queries during peak processing.

Inventory state changes operate differently because they require strict ordering guarantees. When two booking agents simultaneously try to sell the last seat, the event stream must preserve the exact sequence. I partition Kafka topics by inventory key—typically a combination of flight number, departure date, and cabin class—ensuring all events for the same sellable unit flow through the same partition in order.

Pricing signals represent the most challenging stream because they're both high-volume and latency-sensitive. Fare updates from revenue management systems, competitor price scrapes, demand forecasts, and external factors like fuel costs all feed into pricing models that need to respond within milliseconds. I've implemented event compaction strategies where only the latest price for each route-date-class combination is retained, reducing storage while maintaining accuracy.

Stream Processing with Apache Flink

Kafka stores and transports events, but Apache Flink transforms them into actionable intelligence. I've built Flink pipelines that perform stateful stream processing—maintaining running aggregates, detecting patterns across time windows, and joining multiple event streams in real time.

One of the most valuable patterns I've implemented is continuous revenue calculation. Traditional systems batch-process revenue overnight, but with Flink I maintain a running total that updates with every booking event. The state management is sophisticated: Flink checkpoints ensure exactly-once processing semantics, so even if a processing node fails, revenue calculations remain accurate to the cent.

Time window aggregations reveal patterns invisible in point-in-time snapshots. I've built tumbling windows that calculate booking pace for each departure over rolling fifteen-minute intervals, allowing revenue managers to see acceleration or deceleration in demand. Sliding windows compare current booking curves against historical patterns for the same route and season, triggering alerts when trends diverge quite significantly.

The most complex processing involves multi-stream joins. Combining booking events with inventory snapshots and pricing signals in real time requires careful state management and watermark handling. I use event time semantics rather than processing time, ensuring that late-arriving events are incorporated correctly even if they're delayed by network issues or upstream system problems.

Practical Implementation Considerations

Building this architecture requires more than just deploying Kafka and Flink clusters. I've learned that operational maturity matters as much as the technology choices.

Schema evolution is critical because travel data models change constantly—new ancillary products, additional passenger attributes, enhanced fraud detection fields. I use Confluent Schema Registry with Avro serialization, allowing consumers to handle multiple schema versions gracefully. When a new field is added to booking events, older consumers continue processing while newer ones leverage the additional data.

Monitoring and observability require purpose-built instrumentation. I track not just infrastructure metrics like partition lag and consumer throughput, but business metrics like event-to-database latency, revenue calculation accuracy, and inventory synchronization delays. Grafana dashboards show both technical health and business impact in the same view.

Data quality validation happens in-stream rather than as a separate batch process. I've implemented Flink functions that validate event schemas, check business rule constraints, and quarantine invalid events for manual review. When a booking event arrives with an impossible fare amount or missing required fields, it's flagged immediately rather than corrupting downstream aggregates.

Exactly-once semantics require careful coordination between Kafka producers, Flink processors, and downstream sinks (and I've seen this go wrong more than once). I've used Flink's two-phase commit protocol with transactional producers to ensure that events are processed once and only once, even across system failures. This guarantee is essential for financial calculations where duplicates or losses are unacceptable.

Integration with Legacy Systems

The reality of travel technology is that greenfield implementations are rare. I've integrated streaming platforms with decades-old reservation systems, mainframe inventory hosts, and proprietary distribution networks that were never designed for event-driven architecture.

Change data capture has been my bridge between legacy and modern. Tools like Debezium monitor database transaction logs, converting every insert, update, and delete into Kafka events without modifying the source application. I've captured booking modifications from systems that couldn't be touched, transforming database-centric operations into event streams.

Does this mean avoiding AI entirely? Absolutely not. The challenge is semantic translation. A database update might change three columns atomically, but the business meaning might be three distinct events: a fare change, a seat reassignment, and a service class upgrade. I've built enrichment layers that interpret low-level database changes and emit meaningful business events that downstream systems can consume without understanding database internals.

Backwards compatibility remains essential during transition periods. I've run hybrid architectures where streaming pipelines operate alongside batch processes, gradually shifting workloads as confidence builds. The streaming platform calculates real-time revenue, but the overnight batch still runs for reconciliation until the organization trusts the new approach completely.

Looking Forward

My view is that streaming architecture is not an optional enhancement for travel platforms—it's becoming table stakes. The companies winning on customer experience and operational efficiency are those treating their data as continuous flows rather than periodic snapshots. When inventory, pricing, and customer interactions are visible in real time, the entire organization can respond to market dynamics with agility that batch processing simply cannot match.

The technology has matured to the point where the implementation risk is manageable, especially with managed Kafka and Flink services reducing operational overhead. What remains challenging is the organizational transformation: training teams to think in streams rather than tables, building confidence in eventually consistent architectures, and accepting that real-time accuracy is more valuable than batch perfection.

I believe the next evolution will involve more sophisticated stream processing—machine learning models that train continuously on event streams, complex event processing that detects multi-step patterns in customer behaviour, and federated stream processing across geographic regions. The fundamental architecture of event streams and stream processors will remain, but the intelligence we extract from those streams will become dramatically more sophisticated.

About Martin Tuncaydin

Flight Delay Prediction with Machine Learning: Lessons from Production

Martin Tuncaydin — Wed, 08 Apr 2026 09:01:15 +0000

Flying millions of passengers each year means delays are inevitable—but they don't have to be unpredictable (this took longer than I expected to figure out). Over the past few years, I've spent considerable time building and refining real-time flight delay prediction models, drawing on air traffic control feeds, weather APIs and historical ASDI (Aircraft Situation Display to Industry) data. What started as an academic exercise in feature engineering evolved into a production system that required rethinking how we approach machine learning in the aviation context.

This article shares the lessons I've learned from building, deploying, and maintaining a delay prediction model at scale—one that operates in real time and serves business users who need actionable intelligence, not just statistical accuracy.

Why Flight Delays Are Harder to Predict Than You Think

When I first approached this problem, I assumed delay prediction would follow familiar supervised learning patterns: gather historical data, engineer features, train a gradient boosted model, tune hyperparameters, and deploy. The reality proved far messier.

Flight delays are a confluence of cascading dependencies. A late departure in Denver doesn't just affect that single flight—it ripples through crew schedules, gate availability, connecting passengers, and downstream legs. Weather introduces non-linear complexity: a thunderstorm cell over Atlanta can ground flights three states away due to rerouting and airspace congestion. Mechanical issues, staffing constraints, and seasonal demand patterns layer additional stochasticity onto an already chaotic system.

The challenge isn't just predicting whether a flight will be late; it's predicting how late, with enough lead time to take corrective action, while accounting for factors that haven't materialised yet. This requires more than static historical patterns—it demands real-time data fusion and a deep understanding of aviation operations.

The Data Architecture: Fusing Real-Time Streams with Historical Context

Building a robust delay model required assembling a data architecture that could handle multiple streaming sources while maintaining historical context. I learned quickly that batch-trained models, no matter how sophisticated, couldn't compete with systems that incorporated live operational signals.

Air Traffic Control Feeds

ASDI data provided the backbone of real-time flight tracking. These feeds deliver position reports, altitude, speed, and route information directly from ATC systems. I integrated these streams to detect early indicators of delay: holding patterns, reroutes, speed reductions, and deviations from filed flight plans. A flight circling at 10,000 feet fifteen minutes before scheduled arrival is a clear signal that something has disrupted the arrival sequence.

Processing ATC feeds in real time required careful attention to latency and message ordering. I used Apache Kafka to ingest and buffer position reports, ensuring that downstream feature extraction could handle out-of-order messages and transient network issues. The key was treating each position report not as an isolated data point but as part of a temporal sequence that reveals flight behaviour over time.

Weather APIs and Nowcasting

Weather is the single largest contributor to flight delays, but not all weather data is equally useful. I experimented with multiple sources—METAR reports, TAF forecasts, NEXRAD radar, and commercial weather APIs—before settling on a hybrid approach that combined official aviation weather with high-resolution nowcasting models.

The challenge with weather is temporal resolution. A METAR report updated hourly is useful for planning, but it misses the rapid convective development that can shut down an airport in twenty minutes. I incorporated NEXRAD Level III radar data to detect precipitation intensity and storm movement in near-real time, using these signals as leading indicators of arrival delays and ground stops.

One lesson that took time to internalise: weather at the destination airport is only part of the story. En route weather, particularly over major waypoints and jet routes, affects fuel burn, routing efficiency, and arrival sequencing. I built a spatial feature set that captured weather conditions along projected flight paths, not just at endpoints.

Historical ASDI and Operational Context

Real-time data provides immediacy, but historical ASDI data provides context. I used years of historical flight tracks to build baseline delay distributions for specific routes, times of day, and seasonal patterns. This historical layer allowed the model to distinguish between routine variability and genuine anomalies.

For example, a thirty-minute arrival delay on a Friday evening transatlantic flight might be statistically normal, while the same delay on a Tuesday morning domestic route signals a significant operational issue. Without historical context, the model would treat both scenarios identically.

I stored historical ASDI data in a columnar format optimised for time-series queries, using Apache Parquet on cloud object storage. This allowed rapid lookups of comparable flights and efficient computation of rolling statistics—median delay by route, 95th percentile taxi times, seasonal arrival variability.

Feature Engineering: Beyond Obvious Predictors

The quality of a machine learning model is bounded by the quality of its features. In delay prediction, this means going beyond obvious inputs like scheduled departure time and aircraft type to capture the operational dynamics that actually drive delays.

Temporal and Network Features

I engineered features that captured the temporal and network structure of airline operations. Inbound aircraft delay is one of the strongest predictors of outbound delay—if the plane hasn't arrived yet, it can't depart on time. I built features that tracked inbound flight status, estimated arrival time, and turnaround buffer for every scheduled departure.

Network connectivity also matters. Hub airports experience delay amplification because disruptions propagate through connecting flights. I created features that measured hub congestion, gate availability, and connecting passenger loads, using these as proxies for operational stress.

Airspace and Routing Complexity

Certain routes and airspace sectors are inherently more delay-prone than others. I incorporated features that captured routing complexity: number of waypoints, distance from great circle path, airspace class transitions, and proximity to major traffic flows. Flights that traverse multiple high-density terminal areas or cross oceanic boundaries face different delay profiles than direct overland routes.

I also built features that captured real-time airspace status: active special use airspace, temporary flight restrictions, and flow control programs. These operational constraints often force reroutes and delays that aren't visible in historical data alone.

Airline-Specific Operational Patterns

Different carriers have different operational philosophies. Some airlines build generous buffers into their schedules; others optimise for quick turns. Some prioritise on-time departures even if it means leaving connecting passengers behind; others delay departures to protect connections.

I captured these differences through airline-specific features: average turnaround time by aircraft type, historical on-time performance by route, and schedule padding patterns. These features allowed the model to learn carrier-specific behaviours without explicitly encoding business rules.

Model Selection and the Trade-Off Between Accuracy and Interpretability

I experimented with several modelling approaches—random forests, gradient boosted trees, neural networks—before settling on a gradient boosted decision tree framework using LightGBM. The choice was driven by a combination of predictive performance, training speed, and interpretability.

Neural networks offered marginal accuracy gains on held-out test data, but they struggled with the sparse, irregular nature of real-time operational data. They also provided little insight into why a particular delay was predicted, which made them difficult to trust in production.

Gradient boosted trees, by contrast, handled missing data gracefully, learned non-linear interactions efficiently, and provided feature importance scores that aligned with operational intuition. When the model predicted a significant delay, I could trace the prediction back to specific features—a weather cell over the arrival airport, high hub congestion, a late inbound aircraft—and communicate that reasoning to operations teams.

I trained separate models for different delay horizons: two hours before departure, one hour before departure, and at departure time. This multi-horizon approach allowed users to see how delay predictions evolved as new information became available, and it helped calibrate their confidence in early warnings versus imminent alerts.

Production Deployment: Lessons in Real-Time Inference

Deploying a delay prediction model in production taught me that model accuracy is necessary but not sufficient. Latency, reliability, and explainability matter just as much.

I built the inference pipeline using a microservices architecture, with separate services for data ingestion, feature computation, model serving, and result delivery. This separation of concerns allowed independent scaling and failure isolation—if the weather API went down, the rest of the pipeline could continue operating with cached data.

Model serving itself ran on containerised infrastructure with horizontal auto-scaling. I used REST APIs for synchronous queries and message queues for batch predictions, ensuring that users could request delay forecasts on demand or subscribe to continuous updates.

One challenge I hadn't anticipated was handling model drift. Aviation operations change over time—new routes launch, airports expand, carriers adjust schedules—and a model trained on six-month-old data gradually loses relevance. I implemented automated retraining pipelines that ingested fresh ASDI data weekly, evaluated model performance on recent flights, and promoted new model versions only if they outperformed the incumbent.

Monitoring was equally critical. I tracked not just prediction accuracy but also feature distribution drift, inference latency, and user engagement patterns. When prediction errors spiked, I needed to know whether it was due to data quality issues, operational anomalies, or genuine model degradation.

What I Learned About Operationalising Machine Learning in Aviation

Building a production delay prediction system reinforced several lessons that extend beyond aviation to any real-time ML application.

First, data quality matters more than model complexity. I spent more time debugging data pipelines, handling missing values, and validating feature correctness than I did tuning hyperparameters. A simple model trained on clean, timely data will outperform a sophisticated model trained on stale or incomplete inputs.

Second, interpretability is a feature, not a limitation. Operations teams don't trust black-box predictions. They need to understand why a delay is predicted so they can validate it against their domain expertise and decide whether to act. Feature importance scores, SHAP values, and prediction explanations turned the model from a curiosity into a decision support tool.

Third, real-time systems require end-to-end thinking. It's not enough to train an accurate model—you need to ingest data with low latency, compute features efficiently, serve predictions reliably, and deliver results in a format that users can act on. The entire pipeline must be designed for production from day one.

Finally, domain expertise is irreplaceable. I learned more about delay prediction from conversations with airline dispatchers, air traffic controllers, and airport operations managers than I did from any textbook. Their insights shaped feature engineering, guided model evaluation, and grounded the system in operational reality.

My View on the Future of Predictive Aviation Analytics

Flight delay prediction is just the beginning. The same data architecture and modelling techniques apply to broader aviation challenges: optimising crew scheduling, predicting maintenance needs, forecasting passenger demand, and managing irregular operations.

What excites me most is the potential for predictive models to move upstream from reactive alerting to proactive optimisation. Instead of just predicting delays, we can use these models to inform schedule design, resource allocation, and contingency planning. We can simulate what-if scenarios—how would a weather system moving through the Midwest affect tomorrow's operations?—and adjust plans before disruptions occur.

I believe the future of aviation analytics lies in tighter integration between predictive models and operational decision-making. The goal isn't to replace human judgment but to augment it with timely, accurate, and explainable intelligence. When dispatchers, operations controllers, and revenue managers have access to high-quality delay forecasts, they can make better trade-offs and deliver more reliable service to passengers.

Building this system taught me that machine learning in aviation isn't about achieving perfect accuracy—it's about delivering incremental improvements that compound over millions of flights. Even a modest reduction in delay prediction error translates into better passenger experiences, lower operational costs, and more efficient use of scarce resources. That's the kind of impact that makes the technical challenges worthwhile.

About Martin Tuncaydin

AI-Driven Dynamic Pricing in Hotels: A Data Engineer's Deep Dive into Feature Pipelines

Martin Tuncaydin — Mon, 06 Apr 2026 09:01:01 +0000

AI-Driven Dynamic Pricing in Hotels: A Data Engineer's Deep Dive

Over the past decade, I've watched the hotel industry transform its approach to pricing from static rate cards to sophisticated, AI-driven systems that adjust in real-time. What fascinates me most isn't the machine learning models themselves—it's the data engineering infrastructure that makes them possible. Without robust feature pipelines, even the most elegant algorithm becomes a theoretical exercise.

The Revenue Management Challenge Nobody Talks About

When most people discuss dynamic pricing, they focus on the outcomes: higher RevPAR, better occupancy, competitive positioning. I've learned that the real challenge lies in the unglamorous middle layer—the feature engineering that transforms raw booking data, competitor rates, weather forecasts, and event calendars into signals a model can actually use.

I've seen revenue management systems fail not because the data scientists chose the wrong algorithm, but because the data pipeline couldn't deliver features with low enough latency. A pricing model that takes 30 minutes to recalculate rates is worthless when your competitor just dropped their price and you have a customer actively comparing options on their screen.

The traditional approach to hotel pricing relied on human revenue managers reviewing pickup reports, competitive sets, and historical patterns. I respect that expertise—it's pattern recognition built on years of experience. But human analysis operates on daily or weekly cycles. Modern distribution channels demand sub-second responses.

Building Feature Pipelines That Actually Scale

My approach to feature engineering for dynamic pricing starts with understanding what signals genuinely predict booking behaviour versus what merely correlates by accident. I've built systems where we tracked over 300 potential features, only to discover that 40 of them carried 90% of the predictive power.

The temporal dimension is critical. When I design feature pipelines, I think about features in three time horizons: historical aggregations (last 30 days, same period last year), recent trends (last 24 hours, last week), and real-time signals (current search volume, competitor rate changes in the last hour).

Take a seemingly simple feature like "days until arrival." In my experience, this isn't just a number—it's a proxy for booking urgency that interacts with dozens of other variables. A booking window of seven days means something completely different during peak season versus low season, for a business hotel versus a resort, for a weekday versus weekend stay.

I've implemented streaming architectures using Apache Kafka and Apache Flink to process booking events as they occur. The key insight is that not every feature needs real-time computation. Some features—like historical seasonality patterns or property characteristics—can be pre-computed and cached. Others, like current occupancy or competitor pricing, must be calculated on-demand.

The feature store pattern has become central to my work. Tools like Feast or Tecton allow me to separate feature definition from feature serving, making it possible for data scientists to experiment with new features without waiting for engineering sprints. I can version features, track lineage, and ensure consistency between training and inference environments.

Real-Time Inference Architecture

The jump from batch model training to real-time inference is where many hotel tech projects stumble. I've learned that model serving isn't just about loading a pickled scikit-learn model into a REST API. It's about orchestrating dozens of data sources, handling cache invalidation, managing fallback strategies, and ensuring sub-100-millisecond response times.

My typical architecture separates the inference service into multiple layers. The edge layer handles incoming pricing requests and implements aggressive caching strategies. Most pricing requests can be served from cache because, realistically, rates don't need to change every millisecond—they need to change when market conditions shift meaningfully.

Behind the cache sits the feature assembly layer. This is where I pull together pre-computed features from the feature store, enrich them with real-time signals from streaming systems, and format everything into the exact structure the model expects. I use Redis extensively here, not just for caching but as a high-speed lookup layer for frequently accessed dimensions.

The model inference layer itself runs on containerised infrastructure—typically Kubernetes—with horizontal scaling based on request volume. I've deployed models using TensorFlow Serving, TorchServe, and cloud-native services like Amazon SageMaker and Google Vertex AI. The choice depends on model complexity, latency requirements, and operational maturity of the team maintaining the system.

One pattern I've found particularly effective is shadow deployment. Before fully replacing an existing pricing engine, I run the new model in parallel, logging its recommendations alongside the current system's decisions. This lets me measure performance differences, identify edge cases, and build confidence before making the switch. And that matters.

Feature Engineering for Competitive Intelligence

Competitor pricing data represents one of the most valuable but challenging feature sets. I've integrated with rate shopping platforms that scrape OTA sites, providing near-real-time visibility into how competitors price their inventory. The engineering challenge isn't just ingesting this data—it's making it useful.

Raw competitor rates are noisy. A competitor might show a high rate because they're nearly sold out, or because they've temporarily removed discount codes, or because of a data collection error. I've built systems that normalise these signals, identifying genuine pricing moves versus noise.

The competitive set definition itself becomes a feature. I don't just track absolute competitor rates—I calculate rolling percentiles, detect sudden changes, and model the typical price relationship between properties. If a competitor that normally prices 15% below suddenly jumps to 10% above, that's a signal worth acting on.

I've also incorporated external event data—conferences, concerts, sporting events—as features. The challenge here is geocoding and relevance scoring. Not every event impacts every hotel equally. I use distance calculations, historical booking patterns around similar events, and venue capacity as inputs to weight event impact.

The Feedback Loop That Makes Models Better

What separates a proof-of-concept pricing model from a production system is the feedback infrastructure. I build telemetry into every decision point. When the model recommends a price, I log the features that influenced that decision, the alternative prices considered, and the eventual outcome—did someone book, or did they abandon the search?

This creates a continuous learning loop. I've implemented systems where model performance is monitored hourly, comparing predicted booking probabilities against actual outcomes. When performance degrades, automated alerts trigger investigation. Sometimes it's a data quality issue—a broken integration or a schema change. Other times it's genuine concept drift—market conditions have shifted and the model needs retraining.

A/B testing is essential but tricky in pricing contexts. I can't randomly assign prices to rooms without considering fairness and legal constraints. My approach typically involves geographical segmentation or time-based holdouts, comparing model-driven pricing against rule-based systems or human decisions.

The most valuable feedback comes from revenue management teams themselves. I've learned to build dashboards that expose model reasoning, showing not just what price was recommended but why. This transparency builds trust and surfaces cases where the model misses context that humans understand intuitively.

Handling Edge Cases and Constraints

Real-world pricing systems must respect numerous constraints that pure ML models ignore. Minimum length of stay rules, closed-to-arrival restrictions, group block commitments, corporate negotiated rates—these business rules interact with dynamic pricing in complex ways.

I've built constraint layers that sit between model inference and price publication. The model proposes an optimal price based on predicted demand, and the constraint engine adjusts it to respect business rules. Sometimes this means the published price differs quite significantly from the model's recommendation, which creates a feedback problem—the model never learns from these constrained scenarios.

My solution involves training models that are aware of common constraints, using them as additional features. If a property has a minimum three-night stay rule on weekends, the model should learn that booking patterns differ under that constraint and price accordingly.

Currency handling is another edge case that matters enormously in global hotel distribution. I've dealt with systems pricing in dozens of currencies, managing exchange rate updates, and ensuring price consistency across channels. The engineering challenge is maintaining a single source of truth while respecting local market expectations—a price that converts to €99.87 should probably display as €99.

My View on the Future of Hotel Pricing

I believe we're still in the early stages of AI-driven pricing in hospitality. Most systems today optimise for occupancy and RevPAR, but I see the next generation incorporating longer-term strategic objectives—brand positioning, customer lifetime value, sustainability goals.

The technical infrastructure I build today needs to be flexible enough to accommodate these future requirements. So that means designing feature pipelines that can easily incorporate new signal types, model serving architectures that support multi-objective optimisation, and feedback systems that track outcomes beyond immediate booking revenue.

What excites me most is the potential for personalisation at scale. As privacy regulations evolve and data collection becomes more sophisticated, pricing models can move beyond property-level optimisation toward individual customer value prediction. The engineering challenge—doing this at scale while respecting privacy and maintaining fairness—is exactly the kind of problem I find most compelling.

The hotels that succeed won't necessarily be those with the most advanced algorithms. They'll be those with the most robust data infrastructure, the cleanest feature pipelines, and the tightest feedback loops between models and business outcomes. That's where I focus my energy—building the unsexy but essential foundations that make AI-driven pricing actually work.

About Martin Tuncaydin

Fine-Tuning Open-Source LLMs on Travel Domain Data: A Practitioner's Guide

Martin Tuncaydin — Fri, 03 Apr 2026 09:01:14 +0000

The travel industry speaks a language all its own. When I first began experimenting with large language models for travel technology applications, I quickly discovered that even the most sophisticated general-purpose models stumbled over concepts that any seasoned travel professional would recognise instantly. Terms like "married segments," "open-jaw itineraries," and "minimum connecting time" might as well have been foreign languages to models trained primarily on general web content.

This realisation led me down a path that has become central to my work: fine-tuning open-source LLMs specifically for travel domain expertise. What I've learned is that with the right approach—particularly using parameter-efficient techniques like LoRA adapters—we can transform general-purpose models into genuine travel technology specialists without requiring massive computational resources or astronomical budgets.

Why General-Purpose Models Fall Short in Travel

I've tested dozens of scenarios where off-the-shelf models encounter travel industry queries. The results are consistently underwhelming when domain specificity matters. Ask a vanilla GPT or Claude about the difference between published and private fares, and you'll get a reasonable approximation. But ask it to interpret a fare rule with nested conditions about advance purchase requirements, blackout dates, and penalty structures? The responses become vague, sometimes dangerously incorrect.

The problem isn't intelligence—it's exposure. These models have seen travel content in their training data, but it's a tiny fraction compared to general knowledge. More critically, they haven't been trained on the structured, technical documentation that defines how travel systems actually work: GDS command references, ATPCO fare rule categories, airline merchandising schemas, and the countless abbreviations that pervade every booking flow.

I've found that the gap becomes especially pronounced when dealing with multi-step reasoning over travel data. A model might understand what a fare basis code is, but can it reliably decompose one into its constituent parts—booking class, season indicator, day-of-week restrictions—and then reason about what combination of conditions makes a particular itinerary valid? Rarely, without specialised training.

The Case for Fine-Tuning Over Prompt Engineering

My initial instinct, like many practitioners, was to solve this through increasingly sophisticated prompting. I built elaborate prompt chains that provided examples, defined terminology, and walked models through reasoning steps. Some of these worked reasonably well. But I kept hitting walls.

The fundamental limitation is context window economics. Even with models that support 100K or 200K tokens, stuffing comprehensive travel domain knowledge into every prompt is neither efficient nor scalable. I was burning tokens—and budget—to repeatedly teach the same concepts. Worse, the quality of responses remained inconsistent. The model hadn't truly internalised the domain; it was just better at mimicking it when given extensive scaffolding.

Fine-tuning changes the equation entirely. Instead of renting knowledge for each inference, you're buying it once and embedding it into the model's parameters. The model learns patterns, relationships, and domain-specific reasoning paths that become second nature. I've seen fine-tuned models correctly interpret fare rules with minimal prompting—no examples needed, no terminology refreshers, just direct questions answered with domain-appropriate precision.

LoRA: Making Fine-Tuning Practically Feasible

Traditional fine-tuning of large language models requires updating billions of parameters, which demands enormous computational resources and risks catastrophic forgetting of the model's general capabilities. This is where Low-Rank Adaptation, or LoRA, becomes transformative.

LoRA works by freezing the pre-trained model weights and injecting trainable rank decomposition matrices into each transformer layer. Instead of updating all 7 billion parameters of a Mistral model or 70 billion in Llama 2, you're training a small fraction—often less than 1% of the total parameter count. I've successfully fine-tuned models on single consumer GPUs using LoRA adapters that are only a few hundred megabytes in size.

What makes this particularly elegant for travel applications is the modularity. I can maintain a base Mistral or Llama model and swap in different LoRA adapters depending on the specific travel domain task: one adapter trained on fare rules, another on hotel content standards, another on loyalty programme terminology. The base model's general reasoning capabilities remain intact while each adapter provides targeted domain expertise.

The training process becomes remarkably approachable. I've run successful fine-tuning jobs on fare rule interpretation datasets using a single A100 GPU over a weekend. The LoRA adapters train quickly because there are fewer parameters to update, and they merge back into the base model for inference with negligible overhead. For production deployments, this means you can serve a domain-specialised model with nearly the same latency and throughput as the base model.

Curating Training Data from Travel Systems

The quality of fine-tuning depends entirely on training data quality. This is where my background in travel technology data engineering becomes crucial. The travel industry produces enormous volumes of structured and semi-structured data, but most of it isn't in a format suitable for LLM training.

I've built pipelines that transform GDS documentation, fare rule texts, and booking flow logs into instruction-tuning datasets. The key is creating examples that mirror real-world usage patterns. For fare rules, this means pairing rule texts with questions about applicability: "Can this fare be used for a one-way trip?" "What's the cancellation penalty three days before departure?" "Are weekend stays required?"

One dataset I've developed focuses specifically on GDS command interpretation. Travel agents work with cryptic command syntaxes—strings like "WPNCB*ABC" or "FQ/D15JANJFK/A" that encode complex booking operations. I extracted thousands of these commands from sanitised training logs, paired them with plain-language descriptions, and used them to fine-tune models that can now translate between natural language intent and GDS command syntax bidirectionally.

The ATPCO fare rule categories provide another rich training source. These standardised rule categories—Category 3 for seasonality, Category 5 for advance purchase, Category 16 for penalties—form the backbone of airline pricing. I've created datasets that teach models not just to recognise these categories but to reason about their interactions: how a Category 14 travel date restriction might override a Category 2 day/time rule under specific conditions.

What I've learned is that diversity matters more than volume. A dataset with 5,000 carefully curated examples covering the full range of travel scenarios will outperform 50,000 examples that cluster around common cases. I deliberately include edge cases: unusual fare rule combinations, rare exception conditions, deprecated GDS commands that still appear in legacy systems.

Practical Results and Performance Characteristics

The performance improvements from fine-tuning are both quantitative and qualitative. I measure accuracy on held-out test sets of fare rule interpretation tasks, where fine-tuned Mistral models consistently achieve 85-90% accuracy compared to 60-65% for the base model with careful prompting.

But the qualitative improvements are what truly matter in production use. Fine-tuned models exhibit domain-appropriate confidence calibration. They know what they know. When faced with ambiguous fare rules or incomplete information, they'll acknowledge uncertainty rather than hallucinating plausible-sounding but incorrect answers. This reliability is essential when these models support customer-facing applications or agent assistance tools.

I've also observed interesting emergent behaviours. Models fine-tuned on fare rules begin to generalise across airlines, correctly inferring that similar rule structures probably have similar interpretations even for carriers not explicitly in the training data. They learn the meta-patterns of how travel rules are constructed and applied.

The inference speed advantage over retrieval-augmented generation approaches is significant. RAG systems need to search document stores, retrieve relevant passages, and then condition generation on those retrievals. Fine-tuned models have the knowledge embedded in their parameters—no retrieval step needed. For interactive applications where milliseconds matter, this architectural simplicity is a genuine advantage.

Integration Patterns and Production Considerations

Deploying fine-tuned travel LLMs in production requires thinking carefully about the infrastructure. I've experimented with several patterns. The simplest is running models on dedicated GPU instances using frameworks like vLLM or Text Generation Inference, which handle batching and optimised serving automatically.

For applications with variable load, I've found that serverless GPU platforms work surprisingly well with smaller models like fine-tuned Mistral 7B. The cold start times are acceptable when you're not serving the absolute highest throughput, and the cost savings during quiet periods are substantial.

Model versioning becomes critical when you're iterating on training data and fine-tuning approaches. I maintain a registry of LoRA adapters with metadata about training datasets, hyperparameters, and validation metrics. This lets me A/B test different model versions against real user queries and gradually roll out improvements.

One pattern I've adopted is ensemble serving for high-stakes decisions. When the model needs to interpret a complex fare rule with financial implications, I'll query multiple fine-tuned variants and look for consensus. If they disagree significantly, that's a signal to escalate to human review rather than proceeding with uncertain information.

The Road Ahead: Continuous Learning and Domain Expansion

What excites me most about this approach is its extensibility. The travel industry is constantly evolving—new fare types, new merchandising bundles, new GDS features. Traditional rule-based systems require explicit updates for every change. Fine-tuned LLMs can be retrained on new data relatively quickly, incorporating emerging patterns without redesigning the entire system.

I'm exploring continuous learning pipelines where production usage generates new training examples. When a model encounters a query it handles poorly, that becomes a candidate for inclusion in the next training run. This creates a feedback loop where the model gradually improves its coverage of real-world edge cases.

The techniques I've developed for travel domain fine-tuning generalise to other specialised domains with similar characteristics: technical jargon, complex rules, structured data representations. I've had conversations with practitioners in legal technology, financial services, and healthcare who face analogous challenges. The core insight—that domain expertise can be efficiently embedded via parameter-efficient fine-tuning—applies broadly.

My View on the Future of Domain-Specialised AI

I believe we're entering an era where general-purpose foundation models serve as starting points rather than complete solutions. The real value will come from practitioners who understand both the technical capabilities of these models and the deep domain expertise of their industries. Fine-tuning bridges these worlds.

For travel technology specifically, I see a future where every major travel company maintains its own portfolio of fine-tuned models, each optimised for specific tasks within their operations. The barriers to entry are falling rapidly—you no longer need a dedicated AI research team or massive compute budgets. What you need is quality training data and a clear understanding of which problems actually benefit from this approach.

My experience has taught me that the most powerful applications combine fine-tuned models with traditional travel technology infrastructure. The LLM handles interpretation, ambiguity resolution, and natural language interfaces. The deterministic systems handle transaction processing, inventory management, and compliance enforcement. Each does what it does best.

This isn't about replacing travel technology systems wholesale. It's about augmenting them with capabilities that were previously impractical: natural language querying of fare rules, intelligent assistance for complex booking scenarios, automated interpretation of policy documents. These use cases were always desirable but never quite feasible until now. Full stop.

The travel industry has always been at the forefront of applying technology to solve complex, data-intensive problems. I'm convinced that domain-specialised LLMs represent the next chapter in that story—one where the arcane knowledge that currently lives in the heads of experienced travel professionals and buried in technical documentation becomes accessible through conversational interfaces, powered by models that truly understand the domain they serve.

About Martin Tuncaydin

Graph Databases for Travel: How Martin Tuncaydin Maps Routes, Hubs, and Connections

Martin Tuncaydin — Wed, 01 Apr 2026 09:01:17 +0000

Graph Databases for Travel: How Maps Routes, Hubs and Connections

Over two decades working at the intersection of travel technology and data architecture, I've watched the industry wrestle with a fundamental challenge: how do you model the intricate web of connections that make modern travel possible? Traditional relational databases force us to flatten what is inherently a network problem—flights connecting airports, trains linking stations, buses bridging cities, all woven together into a tapestry of possible journeys.

The answer, I've found, lies in graph databases. Not as a trendy alternative to SQL, but as the natural data structure for representing how the world actually moves.

Why Travel Data Belongs in a Graph

When I first encountered graph databases in the early 2010s, I was skeptical. Another NoSQL movement promising to solve everything? But as I began modeling multi-modal journey planning scenarios, something clicked. The relationship between London Heathrow and Paris Charles de Gaulle isn't just a row in a flights table—it's a weighted edge in a living network, influenced by time, cost, carrier, and a dozen other factors.

In graph terminology, every airport, train station, bus terminal, and ferry port becomes a node. Every possible connection between them becomes an edge. Properties on those edges—duration, price, frequency, carbon footprint—become queryable attributes. Suddenly, questions like "What's the fastest route from Barcelona to Copenhagen with no more than one connection?" transform from complex multi-table joins into elegant graph traversals.

I've worked with datasets containing millions of routes across air, rail, and ground transportation. In a relational model, even with careful indexing, these queries bog down. Graph databases like Neo4j treat relationships as first-class citizens, storing them in a way that makes traversal essentially constant time. The database doesn't reconstruct the network at query time—it already is the network.

Neo4j: The Cypher Advantage

My first production graph deployment used Neo4j, and I chose it for one reason: Cypher. The query language feels like drawing on a whiteboard. When I need to find all routes from Amsterdam to Vienna that connect through major hubs, I can write a query that reads almost like plain English.

The pattern-matching syntax lets me express complex routing logic intuitively. I can specify that I want routes with exactly two segments, where the layover is between 45 minutes and 3 hours, and the total journey time doesn't exceed eight hours. In SQL, this would span multiple CTEs and subqueries. In Cypher, it's a single, readable pattern.

What I particularly value about Neo4j is its ACID compliance. Travel booking isn't just about finding routes—it's about transactional integrity. When a customer books a multi-leg journey, I need guarantees that the entire itinerary gets reserved atomically. Neo4j's transactional model gives me that confidence while maintaining graph traversal performance.

The built-in graph algorithms have proven invaluable. Shortest path algorithms help find the quickest routes. PageRank-style centrality measures identify hub airports that matter most to network connectivity. Community detection reveals natural groupings of destinations that frequently get booked together, informing marketing strategies and partnership opportunities.

I've also appreciated Neo4j's visualization tools during stakeholder presentations. Being able to render the actual network graph—showing how new routes integrate into existing infrastructure—makes strategic discussions far more concrete than spreadsheets ever could.

TigerGraph: Scale and Real-Time Analytics

As my work expanded to global-scale route optimization and real-time pricing scenarios, I encountered TigerGraph. While Neo4j excelled at transactional workloads and medium-scale analytics, TigerGraph brought a different strength: distributed graph processing at massive scale.

TigerGraph's native parallel graph architecture means I can run deep graph analytics across billions of edges without the performance cliff I'd hit with single-server solutions. For travel networks spanning every commercial route globally, with historical data going back years, this matters enormously.

The GSQL query language took some adjustment—it's more procedural than Cypher's declarative style—but it unlocks powerful real-time analytics (a pattern I keep running into). I've built systems that continuously analyze route profitability by modeling not just direct connections but the ripple effects through the entire network. When a carrier adjusts pricing on one route, TigerGraph helps me understand the cascading impact across alternative routing options.

One project that stands out involved dynamic pricing optimization for multi-modal journeys. The graph represented every possible combination of air, rail, and bus segments across Europe. As demand shifted in real-time—say, a major conference announced in Berlin—TigerGraph's streaming graph analytics recalculated optimal pricing across thousands of affected routes in seconds, not hours.

The distributed nature of TigerGraph also proved crucial for geographic redundancy and low-latency access. I could partition the graph so that European route queries hit servers in Frankfurt while Asian queries hit Singapore, all while maintaining a unified global network view.

Multi-Modal Journey Planning: Where Graphs Shine

The real test of any data architecture is how well it solves actual business problems. For multi-modal journey planning, graph databases aren't just better than relational alternatives—they're often the only practical solution.

Consider the problem of finding the most sustainable route from London to Edinburgh. In a graph model, I create nodes for every departure point and arrival point across all transport modes. Edges represent individual journey segments—a train from London King's Cross, a bus from London Victoria, a flight from London Gatwick. Each edge carries properties: duration, cost, and critically, carbon emissions.

Now I can query for routes that minimize carbon footprint, perhaps with constraints on total journey time or cost. The graph database naturally handles the complexity of comparing a direct flight against a train journey against a combination of bus and rail. I'm not joining tables—I'm walking a network.

Layover optimization becomes equally elegant. In traditional systems, ensuring that a train arrival at Paris Gare du Nord allows sufficient time to reach Paris Charles de Gaulle for a flight requires careful temporal logic and distance calculations. In a graph, I model both locations as nodes, add an edge representing the transfer with its duration property, and let the graph algorithms handle the rest.

I've built systems where users specify soft preferences—"I prefer trains to planes," "Avoid overnight layovers," "Maximize time in daylight"—and the graph scoring functions weight edges accordingly. This turns journey planning from a binary optimization problem into a nuanced ranking exercise that reflects real human preferences.

Modeling Hub Dynamics and Network Effects

One of the most fascinating applications I've explored is using graph analytics to understand hub dynamics. In travel networks, not all connections are created equal. Frankfurt, Amsterdam Schiphol, and Dubai International aren't just airports—they're super-connectors whose operational efficiency affects the entire network.

Using graph centrality algorithms, I can quantify hub importance in ways that go beyond simple passenger volume. Betweenness centrality reveals which airports sit on the most shortest paths between other destinations. If that airport faces disruption, the cascading impact ripples through countless itineraries. No exceptions.

I've applied these insights to disruption management. When weather closes an airport, the graph database helps identify which alternative routes exist and what capacity they have. Instead of panicking rebooking agents searching manually, the system automatically proposes viable alternatives based on real network topology.

Community detection algorithms have revealed surprising patterns. I discovered that certain city pairs, despite being geographically distant, formed tight communities of frequent travelers—business corridors that warranted premium service even if raw passenger numbers didn't obviously justify it. The graph saw what aggregated statistics missed.

Temporal graphs add another dimension. By modeling how the network changes throughout the day—when flights depart, when trains run, when buses operate—I can find routes that are theoretically possible but practically unavailable because timing doesn't align. This prevents suggesting itineraries that look good on paper but can't actually be booked.

Practical Considerations and Lessons Learned

Implementing graph databases in production isn't without challenges, and I've learned several hard lessons along the way.

Data modeling requires different thinking. In relational design, I normalize aggressively to reduce redundancy. In graph design, I often denormalize deliberately, storing properties on edges that I might otherwise factor into separate entities. The goal is traversal efficiency, not storage efficiency.

Schema evolution is trickier than I initially appreciated. While graph databases are often marketed as "schema-less," production systems need consistency. I've developed versioning strategies for node and edge types, ensuring that schema changes don't break existing queries or corrupt data.

Performance tuning is different too. Relational database optimization focuses on indexes and query plans. Graph optimization centers on graph topology—minimizing the branching factor of traversals, choosing appropriate starting nodes, and leveraging graph-specific indexes on properties that guide path-finding.

I've also learned that graph databases complement rather than replace relational systems. For transactional booking data, customer profiles, and financial records, PostgreSQL remains my foundation. The graph database handles network analysis and route finding, then hands off to the relational system for the actual booking transaction.

Integration patterns matter enormously. I usually maintain a near-real-time sync from operational systems into the graph, using change data capture to update route availability, pricing, and capacity as they evolve. The graph is a living reflection of the bookable network, not a static snapshot.

The Strategic Value of Network Thinking

What excites me most about graph databases in travel isn't the technology itself—it's the shift in thinking they enable. When you start seeing your business as a network rather than a collection of tables, strategic questions change.

Instead of asking "How many passengers flew this route?" I ask "What role does this route play in the overall network?" Instead of "Which destinations are most popular?" I wonder "Which destinations unlock access to entire regions?"

This network perspective has informed partnership strategies. By modeling codeshare agreements and interline relationships as edges between carrier nodes, I can analyze which partnerships create the most new reachable destination pairs. Some partnerships look insignificant in isolation but become strategically vital when viewed through the network lens.

Revenue management transforms too. Traditional yield management optimizes individual route profitability. Network revenue management, powered by graph analytics, recognizes that a loss-leading route might feed highly profitable onward connections. The graph helps quantify that strategic value.

My View on the Future of Travel Data Architecture

I believe we're still in the early innings of applying graph thinking to travel technology. The industry has barely scratched the surface of what's possible when you model the full complexity of modern travel networks—not just routes, but passenger flows, luggage transfers, crew scheduling, maintenance dependencies, and more.

The convergence of graph databases with machine learning particularly excites me. Graph neural networks can learn patterns in route performance that traditional analytics miss. They can predict disruption cascades, recommend personalized itineraries, and optimize pricing in ways that account for the full network context.

As travel becomes increasingly multi-modal—with micro-mobility, ride-sharing, and autonomous vehicles adding new layers to traditional air-rail-bus networks—graph databases will become not just useful but essential. The complexity will exceed what relational models can tractably handle.

What I've learned through years of building these systems is that the best technology feels inevitable in hindsight. Once you model travel data as a graph, returning to relational tables feels like trying to describe a city using only a list of addresses. The connections are the story. The network is the reality. And graph databases are simply the most honest way to represent it.

About Martin Tuncaydin

Sustainable Travel Tech: Using AI to Reduce Carbon Footprint in Global Travel

Martin Tuncaydin — Mon, 30 Mar 2026 09:00:57 +0000

Sustainable Travel Tech: How I Use AI to Help Reduce the Carbon Footprint of Global Travel

The travel industry contributes roughly 8-11% of global greenhouse gas emissions, and that figure continues to climb as more people take to the skies and roads. I've spent the better part of two decades working at the intersection of travel technology and data engineering, and I believe that we're at an inflection point. The tools we build today will either accelerate environmental damage or become part of the solution.

I've become increasingly focused on how artificial intelligence and machine learning can be deployed not just to optimise revenue or improve customer experience, but to fundamentally reduce the carbon intensity of travel. This isn't about greenwashing or token gestures—it's about using data infrastructure and algorithmic decision-making to make measurable environmental impact at scale.

The Carbon Calculation Challenge: Why Most Flight Emissions Data Is Misleading

When I first started exploring carbon calculators for air travel, I was struck by how wildly inconsistent the numbers were. Two different platforms could show the same London to New York flight with emissions estimates differing by 30% or more. The problem isn't just a lack of data—it's the complexity of the calculation itself.

Aircraft type, load factor, routing, altitude, weather patterns, and even the age of the engines all influence fuel consumption. Most consumer-facing carbon calculators use simplified models based on distance and average aircraft efficiency. I've worked with datasets that include tail-specific fuel burn rates, and the variance between individual aircraft of the same model can be significant.

The breakthrough I've seen in recent years comes from combining multiple data sources: flight tracking APIs, manufacturer specifications, historical load factor patterns, and even real-time meteorological data. Machine learning models can be trained on these diverse inputs to produce far more accurate emissions estimates than traditional distance-based formulas.

I've built prototype models that incorporate features like wind patterns from NOAA datasets, seasonal load factors from airline financial disclosures, and aircraft-specific fuel efficiency curves. The accuracy improvement is substantial—typically within 10-15% of actual reported emissions in our prototype work when validated against airline sustainability reports.

The implications for consumers and corporate travel managers are profound. If you're making decisions based on carbon impact, you need reliable data. I've seen enterprises begin shifting booking behaviour based on emissions comparisons, but only when they trust the underlying calculations.

Green Hotel Scoring: Beyond the Marketing Claims

Hotels have become adept at sustainability marketing, but quantifying actual environmental performance is remarkably difficult. I've spent considerable time developing frameworks for scoring accommodation providers on genuine environmental impact, and it's taught me that most public-facing "green ratings" are nearly worthless.

The challenge is data availability and verification. A hotel might claim LEED certification or participation in a local sustainability programme, but what does that mean in terms of actual carbon emissions per guest night? I've found that the most meaningful metrics are energy consumption per square metre, water usage per occupancy, waste diversion rates, and supply chain transparency.

Machine learning becomes valuable here not for prediction, but for pattern recognition and anomaly detection. I've worked with models that analyse utility data, procurement records, and operational metrics to identify which sustainability claims are backed by actual performance. Natural language processing can parse sustainability reports and cross-reference claims against verifiable data sources.

One approach I've explored involves building composite indices that weight different factors based on regional context. A hotel in a water-stressed region should be evaluated differently on water consumption than one in a temperate climate with abundant rainfall. Energy efficiency matters more in markets with carbon-intensive grids.

I've also looked at using computer vision on satellite imagery to verify claims about renewable energy installations, green spaces, and building modifications. The technology exists to independently audit many sustainability claims without relying solely on self-reported data.

The goal isn't to shame properties with lower scores—it's to create transparency and incentivise genuine improvement. I've seen hotel chains make significant operational changes when presented with data-driven benchmarking against competitors.

Routing Optimisation: The Hidden Lever for Carbon Reduction

This is where I think AI has the most immediate and dramatic potential for reducing travel-related emissions. Every day, millions of journeys are planned with optimisation focused on cost, time, or convenience—but rarely carbon intensity.

I've developed routing models that treat carbon emissions as a first-class constraint, not an afterthought. The mathematics are complex because the optimal route from a carbon perspective often isn't the shortest distance or fastest time. It might involve modal shifts—taking a train for one leg instead of a short-haul flight, or choosing a coach service over a rental car.

Why does this matter? Because the alternative is worse. The data infrastructure required is substantial. You need real-time emissions factors for different transport modes, which vary by region, time of day, and vehicle type. A diesel train in one country might have a vastly different carbon intensity than an electric train in another. Bus occupancy rates affect per-passenger emissions. Even ride-sharing services need to be evaluated based on detour distance and vehicle efficiency.

I've built graph-based models where each edge represents a transport option with multiple weighted attributes: cost, time, comfort, and carbon intensity. Multi-objective optimisation algorithms can then find Pareto-optimal routes that balance these competing factors. The user might be presented with three options: fastest, cheapest, and lowest-carbon, along with the trade-offs between them.

The fascinating part is how often the lowest-carbon option isn't dramatically slower or more expensive. I've found that roughly 40% of business journeys under 500 kilometres could reduce emissions by 60-80% with modal shifts that add less than two hours to journey time. The problem isn't feasibility—it's visibility and default behaviour.

Real-Time Decision Support: Making Carbon Data Actionable

The theoretical framework for sustainable travel optimisation is relatively straightforward. The operational challenge is making it work in real-world booking flows and travel management systems.

I've focused on building decision support tools that integrate carbon data at the point of purchase. This means APIs that can return emissions estimates in milliseconds, not seconds. It means user interfaces that surface environmental impact without adding friction to the booking process.

One pattern I've found effective is progressive disclosure. Show a simple emissions badge on search results, but allow users who care to drill down into methodology and assumptions. Provide context—how does this flight compare to the average for this route? What would the emissions be if you took the train instead?

I've also explored using reinforcement learning to personalise carbon-related recommendations. Some users consistently choose lower-carbon options when presented with the data; others prioritise time or cost. The system can learn individual preferences and highlight options accordingly.

Corporate travel is where this becomes particularly powerful. I've worked with travel management platforms that enforce carbon budgets at the policy level. A booking that exceeds the allocated carbon budget for a trip might require additional approval, just as an expensive ticket would. This creates accountability and encourages behaviour change.

The Data Infrastructure Behind Sustainable Travel Tech

None of this works without robust data pipelines and infrastructure. I've built systems that ingest data from dozens of sources: airline schedules, aircraft registries, emission factor databases, hotel utility reports, transport network APIs, and weather services.

The architecture typically involves a combination of batch processing for historical analysis and stream processing for real-time decision support. I use message queues to handle the volume of booking events, time-series databases for emissions tracking over time, and graph databases for routing optimisation.

Data quality is the persistent challenge. Emissions factors get updated, aircraft get retrofitted, hotels change operational practices. I've implemented validation layers that flag anomalies and trigger manual review. Machine learning models need regular retraining as the underlying data distributions shift.

I've also had to grapple with the ethics of data collection and privacy. Tracking individual travel patterns for carbon accounting raises legitimate concerns. I've worked to build systems that aggregate and anonymise data while still providing meaningful insights for organisational decision-making.

My View on Where This Goes Next

I believe we're on the cusp of a fundamental shift in how travel is evaluated and purchased. Carbon impact will become as important a factor as price and convenience—not because of regulation alone, but because consumers and corporations increasingly demand it.

The technology exists today to make this transition. What's missing is standardisation, data sharing, and integration across the fragmented travel ecosystem. I've seen too many point solutions that work in isolation but can't talk to each other.

My focus going forward is on building open frameworks and advocating for industry-wide data standards. The carbon impact of travel should be calculated consistently, reported transparently, and made available at every decision point. We have the AI tools, the data infrastructure, and the engineering capability. What we need now is collective will and coordinated action.

I'm optimistic because I've seen what's possible when data-driven systems are designed with environmental impact as a core objective. The travel industry can absolutely reduce its carbon footprint while continuing to connect people and cultures. It just requires us to build the right technology and use it wisely.

About Martin Tuncaydin

How Large Language Models Are Reinventing Travel Search

Martin Tuncaydin — Wed, 25 Mar 2026 09:01:05 +0000

For the past two decades, travel search has been defined by filters, facets, and structured queries. You select your dates, choose a destination, set your budget parameters, and wait for a paginated list of results ranked by price or relevance. It's functional, predictable, and fundamentally limited by the rigidity of relational databases and keyword matching.

I've spent years working at the intersection of travel technology and data engineering, and I can say with confidence that we're now witnessing the most significant shift in how travellers discover and book their journeys since the advent of online travel agencies. Large language models aren't just adding a conversational layer to existing search paradigms—they're fundamentally reimagining what travel search can be.

The Limitations of Traditional Travel Search

Traditional travel search engines operate on a simple premise: match structured inputs to structured data. A user specifies "London to Barcelona, 15-17 March, two adults" and the system queries inventory databases, applies filters, and returns matching flights. The same logic applies to hotels, where users filter by star rating, amenities, and neighbourhood.

This approach works adequately for straightforward queries, but it breaks down when intent becomes nuanced. What happens when someone asks, "I want a quiet boutique hotel near good coffee shops but away from tourist crowds"? Or "Find me a three-day itinerary in Lisbon that balances history with contemporary art, and I'm vegetarian"?

Conventional systems can't parse this kind of natural language intent. They require users to translate their desires into database-friendly parameters—a cognitive load that creates friction and often results in suboptimal matches. I've observed countless instances where travellers settle for "good enough" results simply because articulating their true preferences through dropdown menus and checkboxes is too cumbersome.

Real-Time Itinerary Generation Through Contextual Understanding

Large language models excel at understanding context, inferring intent, and synthesising information from disparate sources. When applied to travel search, this capability enables something transformative: real-time itinerary generation that responds to complex, multi-faceted requests.

I've experimented extensively with GPT-4, Claude, and similar models in travel contexts, and the shift is profound. Instead of forcing users to construct their trip piecemeal—flight, then hotel, then activities—LLMs can generate coherent, personalised itineraries in response to conversational prompts.

Consider a query like: "I have four days in Tokyo in late April. I'm interested in architecture, especially brutalist and metabolist buildings, and I want to experience local izakayas rather than tourist restaurants. I prefer staying in neighbourhoods with good public transport access."

An LLM can parse this request, understand the temporal constraint, recognise the architectural preferences, infer a desire for authenticity over convenience, and prioritise transit connectivity. It can then generate an itinerary that routes the user through Shibuya's Nakagin Capsule Tower, Shinjuku's Mode Gakuen Cocoon Tower, and lesser-known brutalist structures in Kagurazaka, while recommending izakayas frequented by locals and suggesting accommodation in areas well-served by the Yamanote Line.

This isn't just keyword matching—it's semantic comprehension. The model understands that "metabolist" relates to a specific architectural movement, that "late April" coincides with the tail end of cherry blossom season, and that "local izakayas" implies an interest in cultural immersion rather than guidebook recommendations.

Semantic Hotel Matching Beyond Star Ratings

Hotel search has long been dominated by crude proxies for quality: star ratings, review scores, and price bands. These metrics provide a baseline, but they fail to capture the subjective dimensions that define a memorable stay.

I've found that LLMs can bridge this gap through semantic matching—analysing unstructured review data, property descriptions, and contextual signals to understand what a hotel actually feels like, not just what category it occupies.

Traditional systems might match a user searching for "romantic hotels in Paris" by filtering for properties tagged as "romantic" or those located in conventionally romantic neighbourhoods like Montmartre. An LLM, by contrast, can interpret hundreds of reviews to identify hotels where guests fairly often mention "intimate", "candlelit dinners", "quiet courtyards", and "charming staff", even if the property isn't explicitly categorised as romantic.

More importantly, LLMs can understand the relational aspect of hotel selection. If a user specifies, "I want a hotel similar to The Hoxton in Amsterdam but in Berlin", the model can analyse the design aesthetic, service philosophy, and guest demographics of The Hoxton, then identify Berlin properties with analogous characteristics—perhaps a boutique hotel in Kreuzberg with industrial-chic interiors, a relaxed lobby bar, and a clientele skewing creative professional.

I've tested this approach using embeddings generated from hotel descriptions and review corpora, then querying those embeddings with natural language prompts. The precision is remarkable. Instead of returning generic four-star properties in central Berlin, the system surfaces hotels that genuinely share the vibe, ethos, and experiential qualities of the reference property.

LLM-Based Price Prediction and Dynamic Optimisation

Pricing in travel is notoriously volatile. Airfares fluctuate based on demand forecasting algorithms, hotel rates shift with occupancy levels, and external factors—conferences, festivals, weather events—introduce unpredictable variance.

I've long been interested in whether LLMs could move beyond pattern recognition to predictive intelligence in pricing contexts. The answer, increasingly, is yes—but not in the way one might initially expect.

LLMs aren't replacing traditional time-series forecasting models or regression algorithms. Instead, they're augmenting them by incorporating unstructured signals that conventional models ignore. A typical flight price prediction model might use historical fare data, seasonality patterns, and booking lead time. An LLM can layer in contextual factors parsed from news articles, social media trends, event calendars, and policy announcements.

Is the investment worth it? In most cases, yes. For instance, if a major music festival is announced in Lisbon six months in advance, an LLM can identify this from unstructured web content, correlate it with historical data showing how similar events impacted hotel pricing in comparable cities, and adjust price predictions accordingly—long before the festival appears in structured event databases.

I've also observed LLMs being used to optimise multi-leg itineraries dynamically. Rather than simply finding the cheapest flight or hotel, they can evaluate trade-offs: "If you fly one day earlier, you save £120 on the flight, but hotel prices are £80 higher, however you gain an extra day to visit the Calouste Gulbenkian Museum, which aligns with your stated interest in Art Nouveau."

This kind of contextual optimisation requires understanding not just prices, but preferences, priorities, and the subjective value of time—capabilities that LLMs are uniquely positioned to deliver.

Challenges and Considerations in Implementation

Despite the potential, integrating LLMs into travel search isn't without complexity. The models are probabilistic, not deterministic—they can generate plausible-sounding but factually incorrect recommendations, a phenomenon known as hallucination. I've seen instances where an LLM confidently recommends a "charming bistro in Le Marais" that doesn't exist, or suggests a hotel that closed two years prior. No exceptions.

Mitigating this requires grounding LLM outputs in verified data sources. Retrieval-augmented generation, where the model queries a curated database before generating a response, is one approach I've found effective. Another is using LLMs primarily for intent understanding and semantic matching, then validating recommendations against real-time inventory and availability APIs.

Latency is another consideration. Generating a multi-day itinerary with personalised recommendations can take several seconds, which feels slow in an era where users expect sub-second search results. Optimising inference speed—through model distillation, caching frequent queries, or hybrid architectures that blend LLM reasoning with fast database lookups—is essential for production-grade systems.

There's also the question of transparency. When a traditional search engine ranks hotels by price, the logic is explicit. When an LLM recommends a property based on semantic similarity to user preferences, the reasoning is opaque. I believe users deserve insight into why they're seeing certain recommendations, which means building explainability layers that surface the key factors influencing each suggestion.

My View on Where This Is Heading

I've been fortunate to work in travel technology long enough to witness several paradigm shifts—from call centre bookings to online agencies, from desktop web to mobile-first experiences. The shift toward LLM-powered search feels more profound than any of these.

What excites me most isn't the technology itself, but what it enables: a return to the essence of travel planning as a creative, exploratory process rather than a transactional task. Before the internet, travellers consulted guidebooks, spoke with knowledgeable agents, and pieced together journeys through research and serendipity. The web made booking efficient but stripped away much of the discovery.

LLMs have the potential to restore that exploratory dimension while retaining the convenience of digital search. They can act as knowledgeable guides, interpreting vague aspirations ("I want to feel like I've stepped back in time") into concrete recommendations, surfacing connections between places and experiences that rigid filters would never reveal.

I believe we're moving toward a future where travel search is conversational, contextual, and genuinely intelligent—not in the sense of replacing human judgement, but in augmenting it with capabilities that make discovering the right journey feel effortless and inspiring. The technical challenges are real, but the trajectory is clear. We're reinventing travel search, and I'm excited to be part of that transformation.

About Martin Tuncaydin

Data Quality at Scale: Building Trust in Airline Schedule Data Pipelines

Martin Tuncaydin — Mon, 23 Mar 2026 16:38:55 +0000

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

Conversational AI in Online Travel Agencies: Beyond Traditional Chatbots

Martin Tuncaydin — Mon, 23 Mar 2026 09:01:13 +0000

Conversational AI in Online Travel Agencies — Beyond Chatbots

I've watched the travel industry's relationship with conversational AI evolve dramatically over the past few years. What started as rudimentary FAQ bots has transformed into something far more sophisticated — and far more useful. The difference between a traditional chatbot and what I now call a "trip-planning agent" is not incremental. It's categorical.

Most online travel agencies deployed their first chatbots with modest ambitions: answer common questions, deflect simple support queries, maybe help users find a booking confirmation. These systems operated within tightly scripted flows, recognising a handful of intents and returning canned responses. They were helpful, but fundamentally limited. They couldn't reason, they couldn't improvise and they certainly couldn't plan a multi-city European itinerary based on a vague description of what someone wanted to experience.

That era is ending. The emergence of large language models with tool-calling capabilities has opened a different paradigm entirely — one where conversational interfaces can actually do things, not just talk about them.

From Intent Recognition to Orchestration

Traditional chatbot architecture relied on intent classification. A user typed "I need to change my flight," the system identified the "modify_booking" intent, and triggered a predefined flow. This worked reasonably well for narrow, repetitive tasks. But travel planning is rarely narrow or repetitive.

When I help someone plan a trip, the conversation meanders. They mention they want beaches but also culture. They're flexible on dates but have a hard budget. They're travelling with a toddler, which changes everything. A rule-based system would collapse under this ambiguity. A tool-calling LLM, by contrast, can hold context across dozens of conversational turns, reason about trade-offs, and invoke the right APIs at the right moments.

Why does this matter? Because the alternative is worse. The technical shift here is profound. Instead of mapping utterances to intents, I'm now thinking about LLMs as orchestration engines. They maintain conversational state, interpret natural language with genuine nuance, and decide when to call functions — whether that's querying flight availability, checking hotel inventory, or pulling up visa requirements for a specific passport and destination pair.

Frameworks like LangChain and Semantic Kernel have made this pattern accessible, but the real breakthrough is architectural. I'm no longer building conversation trees. I'm building tool libraries and letting the model determine the execution path.

The Anatomy of a Trip-Planning Agent

A true trip-planning agent needs several components working in concert. First, it needs access to live data sources. Static knowledge bases don't cut it when flight prices shift hourly and hotel availability changes by the minute. But this means integrating with GDS systems, aggregator APIs, and supplier-direct feeds.

Second, it needs a memory layer. I've found that maintaining both short-term conversational context and long-term user preferences is essential. If someone mentions they're vegetarian or that they hate early morning flights, that information should persist across sessions. Vector databases like Pinecone or Weaviate excel here, allowing semantic retrieval of past preferences and interactions.

Third, it needs a decision-making framework. When a user says "find me something romantic in Southern Europe under two thousand pounds," the agent has to decompose that into searchable parameters, rank options against implied criteria, and present choices that feel considered rather than arbitrary. This is where prompt engineering and fine-tuning become critical. I've spent considerable time crafting system prompts that guide models toward travel-specific reasoning patterns.

Fourth, and perhaps most importantly, it needs transactional capability. An agent that can only recommend but not book is still just a sophisticated brochure. Tool-calling LLMs can invoke booking APIs, handle payment flows, and confirm reservations — all while maintaining the conversational thread. The user experience becomes seamless: "Book the second option" actually books it.

Multi-Modal Interaction and the Future Interface

I'm increasingly convinced that text-only interfaces are a transitional state. The most compelling trip-planning experiences I've prototyped involve images, maps, and voice alongside text. When someone asks "show me beachfront hotels in Crete," they want to see photos, not read descriptions. When they're comparing two properties, a map view showing proximity to attractions matters more than a paragraph about location.

Modern LLMs are becoming genuinely multi-modal. GPT-4 Vision, Gemini, and Claude can interpret images. They can analyse a photo someone took last year and suggest similar destinations. They can look at a screenshot of a hotel listing from a competitor and find equivalent or better options. They can generate itineraries that include visual references — not just "visit the Acropolis" but an image of what they'll see.

Voice interaction is similarly transformative. I've tested agents that handle entire trip-planning sessions through natural speech. The latency is now low enough that it feels conversational rather than clunky. For hands-free scenarios — someone planning a trip while commuting or cooking — this changes accessibility fundamentally.

The interface implication is that online travel agencies need to think beyond chat widgets. The agent should be omnichannel: available in-app, on the web, through voice assistants, even integrated into messaging platforms like WhatsApp or Telegram. The conversation should follow the user, maintaining continuity regardless of where they engage.

Guardrails, Hallucinations, and Trust

For all their capability, LLMs remain probabilistic systems. They sometimes hallucinate details — inventing hotel amenities that don't exist or citing flight times that are incorrect. In travel, where accuracy directly impacts customer experience and safety, this is not acceptable.

I've learned that guardrails are non-negotiable. Every factual claim an agent makes should be grounded in retrieved data, not generated from the model's parametric memory. When the agent states a flight departs at fourteen hundred hours, that information must come from a live API call, not from what the model "thinks" is typical.

This requires a layered architecture. The LLM handles natural language understanding and orchestration, but factual retrieval happens through deterministic code paths. Tools return structured data. The model formats and contextualises that data, but it doesn't invent it.

I also implement explicit confirmation steps for high-stakes actions. Before an agent charges a credit card or finalises a non-refundable booking, it summarises the transaction and asks for explicit user approval. This isn't just good UX; it's a necessary failsafe against edge-case errors.

Trust is earned slowly and lost instantly. A single booking error caused by a hallucinated detail can undo months of positive interactions. I approach agent design with the assumption that mistakes will happen, and I engineer systems to catch them before they reach the user.

Personalisation Without Surveillance

One of the tensions I navigate constantly is between personalisation and privacy. A truly helpful trip-planning agent should know my preferences, my budget patterns, my travel history. But users are rightly wary of systems that know too much or use their data in opaque ways.

My approach is to make data usage transparent and user-controlled. If an agent remembers that I prefer aisle seats, it should tell me it's using that information and offer an easy way to override or delete it. Preference storage should be opt-in, not default. And critically, data should never be shared or sold to third parties without explicit consent.

European GDPR frameworks have set a high bar here, and I think that's appropriate. I design agents that can function perfectly well with zero stored preferences — they just become more helpful over time if the user chooses to share context. The personalisation layer should feel like a concierge service, not surveillance capitalism.

There's also a technical dimension: local processing and federated learning can keep sensitive data on-device while still enabling personalisation. I'm watching developments in this space closely, particularly for mobile applications where users expect both convenience and privacy.

The Human-Agent Partnership

Despite everything I've described, I don't believe conversational AI will replace human travel advisors — at least not entirely. What I've observed is that the best experiences emerge from human-agent partnership.

For straightforward bookings — a weekend city break, a familiar route, a hotel chain someone knows — an agent can handle everything autonomously. But for complex itineraries, unusual requests, or situations requiring judgment and empathy, human expertise remains invaluable. A bereaved family rearranging travel plans. A honeymoon with very specific cultural requirements. A business traveller navigating visa complications across multiple jurisdictions.

In these cases, the agent becomes a tool that augments the human advisor. It handles the mechanical work — checking availability, comparing prices, managing booking logistics — freeing the human to focus on the parts that require emotional intelligence and creative problem-solving.

I envision a tiered model: self-service agents for routine needs, escalation to human advisors for complexity, and hybrid workflows where both collaborate. The agent might draft an itinerary that a human advisor refines. Or a human might start a conversation that the agent completes. The boundary should be fluid and invisible to the user.

My View on What Comes Next

I believe we're at an inflection point. The technology to build genuinely useful trip-planning agents exists today. The APIs are mature, the models are capable, the infrastructure is available. What's missing is widespread implementation and the cultural shift required to trust these systems with meaningful tasks.

Over the next two years, I expect to see online travel agencies move decisively beyond FAQ bots toward full-service agents. The competitive pressure will be immense. Users who experience a truly capable agent won't tolerate regression to static forms and endless dropdown menus.

But success requires more than deploying an LLM with some API integrations. It requires thoughtful design, rigorous testing, transparent data practices, and a genuine commitment to user benefit over engagement metrics. I've seen too many implementations prioritise flashiness over utility, and they fail quickly.

The opportunity is enormous. Travel planning is cognitively demanding, time-consuming, and often stressful. An agent that reduces that friction while increasing confidence and delight has real value. I'm optimistic about where this technology is heading, but I'm also mindful of the work required to get it right.

The future of online travel isn't chatbots. It's intelligent, trustworthy agents that understand what you want, find what you need, and handle the complexity so you can focus on the experience itself. That's the standard I'm building toward, and I think the industry will follow.

About Martin Tuncaydin

Agentic AI Workflows: Transforming Corporate Travel Management with Multi-Agent Systems

Martin Tuncaydin — Fri, 20 Mar 2026 09:01:35 +0000

Agentic AI Workflows: Reimagining Corporate Travel Management Through Multi-Agent Systems

I've spent the better part of two decades watching corporate travel management evolve from phone calls and faxed itineraries to self-service portals and mobile apps. Yet for all the digitisation we've achieved, the fundamental workflow remains frustratingly manual. Travellers submit requests, approvers click buttons, travel managers chase exceptions, and when disruptions hit, everyone scrambles.

The emergence of large language models has opened a genuinely new chapter. I'm not talking about chatbots that answer FAQs or virtual assistants that book flights through conversation. I'm talking about agentic AI systems—autonomous software agents that can perceive their environment, make decisions, take actions, and coordinate with other agents to accomplish complex goals without constant human oversight.

In corporate travel management, this means moving from systems that require humans to orchestrate every step to systems where intelligent agents negotiate fares, route approval requests, monitor flight status, and autonomously rebook disruptions according to policy and traveller preference. I've been experimenting with these architectures, and the implications are profound.

The Limitations of Traditional Workflow Automation

Before diving into what agentic systems can do, it's worth understanding why traditional automation falls short in corporate travel. Most travel management platforms today use rule-based workflows: if a booking exceeds a threshold, route it to a manager; if a flight is cancelled, send an alert. These rules are brittle and context-blind.

When I analyse failed travel bookings, the pattern is clear. A traveller needs to attend a conference in Singapore next month. The policy allows business class for flights over eight hours, but the system flags the booking because the fare is 15% above the market average. The approval goes to a manager who has no context on fare volatility for that route. Meanwhile, prices climb another 10% while the request sits in a queue.

Or consider disruption management. A flight cancels, and the system sends an email notification. The traveller must then navigate rebooking options, check policy compliance, potentially seek approval for a higher fare, and coordinate with colleagues affected by the delay. Every step requires human judgment and manual intervention.

Traditional automation handles deterministic processes well—tasks with fixed inputs, clear rules, and predictable outputs. Corporate travel is anything but deterministic. Fares fluctuate constantly, policies have exceptions, traveller preferences vary, and external events create endless edge cases. This is precisely where agentic AI shines.

Multi-Agent Architecture: Specialisation and Coordination

The key insight behind agentic workflows is that complex business processes are better handled by multiple specialised agents working together than by a single monolithic system. In my experimental architectures, I usually deploy several distinct agent types, each with specific capabilities and responsibilities.

A fare negotiation agent continuously monitors pricing across multiple sources—GDS systems, airline APIs, aggregator platforms—and uses pattern recognition to identify optimal booking windows. Unlike a human analyst who might check prices a few times, this agent processes thousands of fare updates daily, building a probabilistic model of when to buy.

An approval routing agent understands organisational hierarchy, delegation rules, and approval thresholds. More importantly, it understands context. When routing a request, it considers the urgency of travel, the approver's current workload, historical approval patterns, and whether similar requests have been approved recently. If the primary approver is travelling, it automatically escalates to a delegate without waiting for a timeout.

A policy compliance agent interprets travel policy documents—which are rarely structured data—and applies them to specific booking scenarios. I've found that fine-tuning a language model on policy documents and historical approval decisions creates an agent that can handle nuanced questions: Is this hotel acceptable given the conference location? Does this upgrade qualify as reasonable given the overnight layover?

A disruption response agent monitors flight status, weather patterns, and airport operations in real-time. When a delay or cancellation occurs, it doesn't just notify the traveller—it evaluates rebooking options, checks policy compliance, considers the traveller's subsequent commitments (by accessing calendar data with permission), and can autonomously rebook if the alternative meets predefined criteria.

The orchestration layer coordinates these agents. When a booking request arrives, the orchestration layer determines which agents need to be involved, in what sequence, and how their outputs should be combined. This is where frameworks like LangGraph and AutoGen prove valuable—they provide patterns for agent communication, state management, and error handling.

Real-World Scenarios: From Theory to Practice

Let me walk through a scenario I've prototyped extensively. A consultant needs to travel from London to New York for a three-day client engagement starting on Monday. She submits the request on Wednesday afternoon.

The fare negotiation agent immediately begins monitoring prices for relevant flights. It identifies that fares typically drop slightly on Thursday morning for this route and booking window, but climb sharply by Friday. It places a provisional hold (where possible) and continues monitoring.

The policy compliance agent reviews the request against company guidelines. The outbound flight is fine, but the return flight arrives late Friday evening, and the traveller has selected business class. The agent flags that the policy requires overnight stays to justify business class on transatlantic routes, but recognises this is a common exception for Friday returns. It annotates the request with this context.

The approval routing agent determines that standard approval is required because the fare exceeds £800. However, it notices that the traveller's manager approved three similar bookings in the past month without modification. It escalates the request with a confidence score suggesting approval is likely.

Meanwhile, the fare negotiation agent detects that Thursday morning prices have dropped 8% as predicted. It alerts the orchestration layer, which accelerates the approval process by flagging the time-sensitivity to the manager.

The manager receives a rich approval request: the booking details, the policy context, the fare trend analysis, and the confidence score. She approves with one click. The booking completes at the optimal price point.

On Monday morning, a winter storm hits New York. The disruption response agent detects that the traveller's Wednesday return flight has a 70% likelihood of delay based on weather forecasts and historical patterns. It proactively identifies an alternative Tuesday evening flight that would still meet the client commitment and stay within policy. It sends the traveller a notification: "Your Wednesday return flight is likely to be disrupted. I've found an alternative Tuesday evening option that saves £120 and avoids the storm. Shall I rebook?"

The traveller approves via mobile. The agent handles the rebooking, updates the calendar, notifies the client of the adjusted schedule, and files the necessary documentation. What would have been a stressful morning of phone calls and uncertainty becomes a seamless adjustment.

Technical Considerations: Context, Memory, and Trust

Building these systems requires solving several hard problems. Context management is paramount. An agent making rebooking decisions needs to understand not just the flight details, but the purpose of travel, downstream commitments, traveller preferences, and organisational priorities. I've found that maintaining a rich context graph—linking bookings to projects, travellers to teams, trips to business objectives—is essential.

Memory systems allow agents to learn from past interactions. When a fare negotiation agent observes that a particular route has volatile pricing on Thursdays, it adjusts its strategy. When a policy compliance agent sees that certain exceptions are routinely approved, it gains confidence in flagging them as low-risk. Vector databases like Pinecone and Weaviate work well for storing and retrieving these learned patterns.

Trust and explainability are non-negotiable in corporate contexts. When an agent autonomously rebooks a flight, the traveller needs to understand why. I instrument every agent action with a reasoning trace—the inputs considered, the decision logic applied, the alternatives evaluated. These traces are stored and can be reviewed if questions arise.

Human oversight remains critical. I design agentic workflows with multiple intervention points. For routine decisions within well-understood parameters, agents act autonomously. For edge cases or high-stakes decisions, agents make recommendations and humans approve. The goal isn't to eliminate human judgment but to eliminate tedious manual work and surface decisions to humans with rich context.

The Economic Case: Efficiency, Savings, and Experience

The business value of agentic workflows extends beyond automation metrics. Yes, reducing manual processing time matters, but the more significant impacts are subtler.

Fare optimisation compounds quickly. If an agent improves booking timing by even 5% on average, that translates to substantial savings at scale. I've modelled scenarios where organisations with 10,000 annual trips save mid-six figures through better timing alone, before considering negotiated rates or alternative routing.

Policy compliance improves because agents apply rules consistently and completely. Human reviewers miss exceptions, apply policies inconsistently, or lack the time to investigate thoroughly. Agents review every booking with the same rigour.

Disruption costs drop dramatically. The average cost of a missed flight—rebooking fees, fare differences, lost productivity, hotel changes—easily exceeds £500 per incident. Autonomous rebooking that happens in minutes rather than hours prevents cascading failures and reduces stress.

Traveller experience transforms from adversarial to supportive. Instead of fighting with a booking tool and waiting for approvals, travellers interact with an intelligent assistant that understands their needs, anticipates problems, and handles complexity on their behalf.

Integration Challenges: Legacy Systems and Data Silos

I'd be remiss not to address the integration reality. Most organisations have a complex ecosystem of travel management tools, expense systems, HR platforms, and GDS connections. Building agentic workflows requires connecting to all of them.

APIs are the foundation. Modern travel platforms expose reasonably comprehensive APIs, though coverage varies. I've had success using tools like Amadeus APIs for flight data, Sabre APIs for booking management, and various hotel aggregator APIs. The challenge is often authentication, rate limiting, and error handling rather than functionality gaps.

Legacy system integration is messier. Many corporate travel systems were built before APIs were standard practice. Screen scraping and RPA tools like UiPath can bridge gaps, though they're brittle. Where possible, I advocate for upgrading platforms that enable proper integration.

Data normalisation is tedious but essential. Flight data from different sources uses different formats, codes, and conventions. Building a unified data model that agents can work with requires significant upfront effort and ongoing maintenance.

Governance and Control: Policy, Privacy, and Compliance

Deploying autonomous agents in corporate environments raises governance questions. Who's accountable when an agent makes a poor decision? How do we ensure agents respect privacy? What controls prevent misuse?

I've developed a governance framework that addresses these concerns. Every agent operates within a defined scope of authority. The fare negotiation agent can analyse prices but cannot commit to bookings above certain thresholds without approval. The disruption response agent can rebook within policy but must escalate exceptions.

Audit trails capture every agent action, decision, and reasoning trace. These logs are immutable and retained according to data retention policies. If a question arises about why a particular booking was made, we can reconstruct the complete decision chain.

Privacy controls are embedded in the architecture. Agents access personal data on a need-to-know basis. The fare negotiation agent doesn't need to know who's travelling, only the route and dates. The policy compliance agent needs role and seniority information but not personal details. Access is logged and monitored.

Compliance with regulations like GDPR requires careful design. Traveller data is processed lawfully, minimised, and protected. Agents explain their decisions in plain language, giving travellers visibility into how their data is used. Consent mechanisms are clear and granular.

The Path Forward: Incremental Adoption and Continuous Learning

I don't advocate replacing existing systems overnight with agentic workflows. The practical path is incremental adoption, starting with high-value, low-risk use cases.

Fare monitoring and recommendations is a natural starting point. An agent that analyses prices and suggests optimal booking times delivers value without requiring autonomous action. It builds trust and demonstrates capability.

Policy pre-screening comes next. An agent that reviews bookings for compliance and flags issues before they reach human approvers saves time without taking control. Approvers can see the agent's reasoning and override if needed.

Simple disruption alerts follow. An agent that monitors flights and notifies travellers of delays or cancellations provides value even without autonomous rebooking. Over time, as trust builds, you enable autonomous rebooking for low-stakes scenarios—short delays, similar alternatives, within-policy options.

Continuous learning is essential. These agents improve through feedback loops. When a human overrides an agent recommendation, that becomes training data. When an agent's fare prediction proves accurate, confidence scores adjust. The system gets smarter with use.

My Perspective: A Fundamental Shift in How We Build Software

I've built enough travel systems to recognise that agentic workflows represent more than an incremental improvement. They're a different paradigm for how we architect software.

Traditional systems encode business logic in code—functions, classes, rules engines. Changing the logic requires deploying new code. Agentic systems encode goals and constraints, then let language models figure out how to achieve those goals within the constraints. The logic is emergent, not hard-coded.

This flexibility comes with tradeoffs. Emergent behaviour is harder to test comprehensively. Agents can surprise us with creative solutions—sometimes brilliant, sometimes problematic. But in domains like corporate travel where the problem space is vast and constantly changing, the flexibility outweighs the risks.

I believe we're in the early stages of a transition that will take years to fully unfold. The technology is maturing rapidly—models are more capable, frameworks are more robust, best practices are emerging. But organisational readiness varies widely. Some companies are ready to experiment aggressively; others need to see more proof points.

What excites me most is the potential to eliminate entire categories of frustrating work. Not the strategic, creative, meaningful work, but the tedious, repetitive, context-switching work that drains energy and adds little value. Checking prices, filling forms, routing approvals, handling routine exceptions—these tasks don't require human intelligence; they require them because we haven't had better alternatives.

Agentic AI gives us that alternative. It lets us build systems that are genuinely helpful, that anticipate needs, that handle complexity gracefully, that learn from experience. In corporate travel management, this translates to faster bookings, lower costs, fewer disruptions, and dramatically better experiences for everyone involved.

The future of corporate travel isn't about building more sophisticated booking portals. It's about deploying intelligent agents that handle travel management on our behalf, leaving us free to focus on the actual purpose of travel: building relationships, closing deals, sharing knowledge, and moving business forward. That future is closer than most people realise, and I'm committed to helping bring it into reality.

About Martin Tuncaydin

The Modern Travel Data Stack in 2025: How Leading OTAs Build Their Analytics Foundation

Martin Tuncaydin — Wed, 18 Mar 2026 09:01:11 +0000

The Modern Travel Data Stack in 2025: How Leading OTAs Build Their Analytics Foundation

The travel industry has always been data-intensive, but the sheer volume and velocity of information flowing through modern booking platforms has reached unprecedented levels. Every search, click, abandonment, booking, and review generates data points that, when properly harnessed, can transform how we understand customer behaviour, optimise pricing, and forecast demand. Yet I've watched countless travel platforms struggle with fragmented systems, inconsistent metrics, and analytics teams spending more time wrangling data than deriving insights.

Over the past few years, I've seen a clear pattern emerge among the most sophisticated online travel agencies: they've converged on a remarkably similar data architecture. This isn't coincidence—it's the result of hard-won lessons about what actually works at scale. The modern travel data stack has matured into something both powerful and surprisingly standardised, built around a core set of technologies that solve real problems rather than chase hype.

The Warehouse-First Philosophy

I've become convinced that the most fundamental shift in travel analytics isn't about any single tool—it's about inverting the traditional data flow. The old approach treated the warehouse as a final destination, a place where data went to retire after serving its operational purpose. The modern approach recognises the warehouse as the central nervous system of the entire analytics ecosystem.

Cloud-native warehouses — Snowflake, BigQuery, and Databricks among them — have emerged as the dominant choices for this role. The separation of compute and storage solves a problem that plagued travel platforms for years: the unpredictable spikes in analytical workload. During flash sales, marketing campaign launches, or competitive pricing analysis, you need massive compute capacity. During quiet periods, you don't want to pay for idle resources. This elasticity maps perfectly to the cyclical nature of travel demand.

What I find particularly valuable is the handling of semi-structured data in modern cloud warehouses. Travel platforms deal constantly with JSON from APIs, nested XML from legacy GDS systems, and unstructured content from reviews and customer service logs. The ability to query these directly without extensive preprocessing has collapsed what used to be weeks-long data onboarding projects into hours.

Features like zero-copy cloning have transformed how I think about environments. Creating perfect replicas of production data for analytics experimentation, without duplicating storage costs, means teams can test hypotheses fearlessly. I've seen this single capability accelerate innovation cycles by months.

Ingestion Without the Infrastructure Burden

Why does this matter? Because the alternative is worse. The proliferation of data sources in travel is relentless. You're pulling from booking engines, payment gateways, customer review platforms, flight status APIs, weather services, competitive intelligence tools, CRM systems, email marketing platforms, and dozens of niche providers. Building and maintaining custom connectors for each source used to consume entire engineering teams.

Airbyte has fundamentally changed this equation. The open-source connector catalogue covers most major travel data sources, and when you need something custom, the connector development kit makes it manageable. I've watched teams reduce their data ingestion maintenance burden by 80% by consolidating on this platform.

What resonates with me most is the incremental sync capability. Travel data grows fast—millions of searches daily, hundreds of thousands of bookings, constant inventory updates. Full refreshes become prohibitively expensive. Airbyte's change data capture mechanisms ensure you're only moving what's changed, dramatically reducing both pipeline runtime and warehouse compute costs.

The normalisation layer deserves mention too. Different booking sources structure the same conceptual data differently—dates in varying formats, currency codes with inconsistent precision, passenger names following different conventions. Having this standardisation happen during ingestion, before data hits the warehouse, keeps the downstream transformation layer cleaner and more maintainable.

Transformation as Code

This is where I've seen the most profound cultural shift. dbt has transformed data transformation from a dark art practiced by specialised SQL wizards into an engineering discipline with proper version control, testing, documentation, and collaboration patterns.

The mental model is elegantly simple: write SQL select statements, define dependencies between models, and let dbt handle the orchestration (not a popular view, but an accurate one). But the implications are profound. I've watched analysts who could write SQL but couldn't deploy it to production become fully autonomous contributors, shipping models from development to production without engineering bottlenecks.

The testing framework catches issues that used to surface only when executives questioned dashboard numbers. Uniqueness tests on booking IDs, non-null checks on critical fields, referential integrity between fact and dimension tables—these automated checks create trust in the data that manual validation never could.

Documentation generated directly from the code means it stays current. I can't overstate how valuable this is in travel, where business logic complexity is extreme. Why does this revenue metric exclude certain booking types? What's the definition of a "completed trip" versus a "booked trip"? When documentation lives alongside the transformation code, these questions get answered immediately.

The incremental materialisation strategy has been a game-changer for large fact tables. In travel, you're often dealing with hundreds of millions of booking events, billions of search records. Rebuilding these tables from scratch nightly is wasteful. dbt's incremental models let you process only new or changed records, reducing transformation time from hours to minutes.

The Layered Warehouse Architecture

The most successful implementations I've observed follow a consistent layering pattern. Raw data lands in a staging area, exactly as received from source systems. This preserves the original state for audit and debugging purposes.

The next layer applies standardisation and light cleaning—timezone normalisation, currency conversion, deduplication. This is where data from disparate sources gets shaped into consistent formats.

The core business logic layer is where domain expertise crystallises into dimensional models. Customer dimensions, product hierarchies, temporal dimensions, booking facts, search facts, revenue facts—this is the semantic layer that business users understand. Getting these models right requires deep travel industry knowledge. What constitutes a "session"? How do you attribute revenue when bookings can be modified multiple times? When does a search become abandoned versus in-progress?

The final presentation layer creates aggregates and metrics optimised for specific use cases—executive dashboards, operational reports, data science features. This layer trades storage for query performance, pre-computing expensive calculations.

Real-Time and Batch in Harmony

One pattern I'm seeing increasingly is the hybrid architecture that combines batch processing for heavy analytical workloads with streaming for operational use cases. The warehouse remains the source of truth for historical analysis, but streaming pipelines feed low-latency dashboards for inventory management, fraud detection, and dynamic pricing.

Tools like Apache Kafka handle the real-time event streams, but the key insight is that these streams often land in the same cloud warehouse, just via a different path. This architectural choice prevents the fragmentation that plagued earlier attempts at real-time analytics, where streaming and batch systems created conflicting versions of truth.

The Orchestration Question

I've watched many teams underestimate the complexity of dependency management as their data platform grows. When you have hundreds of dbt models, dozens of ingestion pipelines, and various downstream consumption patterns, coordinating execution order becomes non-trivial.

Some teams use dbt Cloud's native scheduling. Others prefer Airflow for more complex orchestration needs, particularly when coordinating data pipelines with operational workflows like triggering email campaigns or updating recommendation engines. Prefect has gained traction for its modern approach to workflow management. And that matters.

The right choice depends on your specific complexity profile, but the principle is universal: explicit dependency declaration and automated orchestration prevent the fragile, manually coordinated workflows that break at the worst possible times.

Observability and Data Quality

The final piece of the modern stack is continuous monitoring. As data platforms become mission-critical—powering pricing algorithms, fraud detection, personalisation engines—data quality issues translate directly to revenue impact.

Tools like Monte Carlo and Great Expectations provide automated anomaly detection, freshness monitoring, and quality metrics. When your daily booking load suddenly drops by 30%, you need to know within minutes whether it's a real market shift or a broken pipeline. When revenue metrics drift from expected ranges, is it a calculation error or a genuine business change?

I've found that embedding these checks throughout the pipeline—at ingestion, transformation, and consumption layers—creates defence in depth. A single layer of quality checks catches some issues. Multiple layers catch nearly everything before it reaches decision-makers.

My View on Where This Goes Next

The convergence around modern cloud warehouses, dbt, and Airbyte isn't ending innovation—it's creating a stable foundation that lets teams focus on higher-value problems. I'm watching the frontier move toward semantic layers that make data truly self-service, machine learning operations that deploy models as reliably as we now deploy dbt models, and real-time capabilities that handle streaming as elegantly as we handle batch.

What excites me most is seeing analytics teams in travel shift from infrastructure maintenance to strategic insight generation. When your data platform is built on these modern primitives, you spend less time debugging pipeline failures and more time answering questions like: How do search patterns predict booking propensity? What inventory mix maximises both conversion and margin? Which customer segments respond to which messaging?

The tools have matured. The patterns have been validated at scale. The question now isn't whether to adopt this stack—it's how quickly you can migrate to it and start capturing the competitive advantage that high-quality, accessible data provides. In an industry as dynamic and competitive as travel, that advantage compounds daily.

About Martin Tuncaydin