[Travel & Hotels I] Multi-Source Entity Resolution: Why the Foundation of Intelligent Itinerary Planning Is Unsexy Catalog Normalization

Why Fluent Travel Drafts So Easily Hide Unbookable Conflicts

Imagine a familiar operational scenario: a travel service team connects supplier feeds from multiple wholesalers into a conversational planning assistant and asks it to assemble a multi-city itinerary tailored to a family’s budget, party composition, and transit connections. Within moments, the assistant produces a polished narrative. Yet when human travel consultants attempt to price and lock in the inventory, they discover that the draft easily includes closed or unavailable venues, confuses similarly named properties across different districts, or treats the same cruise vessel listed under different distributor aliases as distinct backup options.

This gap between fluent prose and executable bookings cannot be closed by prompt tuning alone. Reliable itinerary orchestration depends on multi-source catalog deduplication and record linkage as its foundation, followed by constraint-based planning over verified inventory and operating hours. Skipping unglamorous catalog normalization and asking a language model to improvise directly over noisy supplier feeds turns unresolved data conflicts into plausible-sounding operational failures.

From Record Linkage Theory to Multi-Constraint Benchmarks: The Dual Bottleneck

Why is reconciling records across multiple sources fundamentally hard? In their foundational mathematical theory of record linkage, Fellegi and Sunter (1969) formalized the problem of recognizing records in two files that represent identical persons, objects, or events^[1]. Comparing recorded characteristics between a pair of records yields a comparison vector γ, from which a linkage rule chooses among three decisions at stipulated error levels: a link (A1), a non-link (A3), or a “possible link” (A2) when evidence is insufficient to justify either positive disposition^[1]. Those positive dispositions carry corresponding error probabilities: falsely linking unmatched records (μ) and failing to link matched records (λ)^[1]. An optimal linkage rule L(μ, λ, Γ) minimizes the probability P(A2) of falling into the undecided “possible link” region for fixed error levels (μ, λ)^[1]. For system architects, this theorem carries an enduring operational lesson: whenever data noise exists and false-positive or false-negative error rates are bounded, a gray zone (A2) typically remains that automated thresholds cannot safely resolve without further evidence or human review.

Modern data pipelines amplify this challenge. Reviewing end-to-end Entity Resolution (ER) for big data, Christophides et al. (2020) note that ER—identifying different descriptions that refer to the same real-world entity—is critical for data quality and analytical reliability, yet remains difficult even after decades of research^[3]. When real-world applications must satisfy multiple big data dimensions simultaneously—Volume, Velocity, and Variety—methods across the database, semantic Web, and machine learning communities must contend with loose structuredness, extreme diversity, high speed, and large scale in entity descriptions^[3]. Hospitality and travel catalogs sit squarely at this intersection: wholesalers, airlines, cruise lines, and destination guides describe the same properties, cabin categories, and points of interest with incompatible schemas and shifting aliases.

Even when a clean, structured sandbox is provided, assembling valid itineraries under real-world constraints pushes language agents to their limits. Xie et al. (2024) introduced TravelPlanner, a benchmark designed to evaluate language agents on complex travel planning with tools accessing nearly four million data records across 1,225 curated planning intents and reference plans^[2]. Comprehensive evaluations revealed that current language agents are not yet capable of handling such complex planning tasks: even the leading commercial large language model evaluated achieved a success rate of only 0.6%^[2]. Language agents struggled to stay on task, invoke the right tools to gather information, or keep track of multiple constraints simultaneously^[2]. When multi-constraint tracking already operates on such thin margins, feeding an agent unnormalized supplier catalogs makes reliable itinerary generation virtually impossible.

Decoupling Catalog Normalization from Constraint Planning in Architecture

Translating these findings into software architecture requires separating master catalog normalization from itinerary constraint orchestration, with explicit human review gates in each workflow. Across the capability catalog on rlab.works, this separation spans the Intelligence and Agent OS modules, where relevant travel workflows are grounded in source-supported industry data for Travel & hotels.

The upstream layer handles multi-source entity resolution. Within the Intelligence module, the Unify and enrich records (S28) skill pack takes Authorized sources, legacy records and target catalog fields as its initial input contract and progresses through a structured sequence:

• Ingest and stage sources (assisted): Imports multi-channel feeds to produce staged records with provenance and missing-field logs.
• Normalize and resolve entities (assisted): Draws on capabilities such as Canonical geography, hotels and POIs and multi-provider cruise catalog normalization to decompose heterogeneous schemas and emit unified entities, relational details, and aliases.
• Classify and locate gaps (assisted): Aligns records to versioned taxonomies and outputs classification results alongside a checklist of missing facts.
• Investigate and accept facts (human review): Directly addressing the Fellegi-Sunter gray zone (A2), ambiguous linkages and gap-filling facts pause for an assigned reviewer or requesting user; rejected outputs return for revision and do not advance into the master catalog.

In travel and hospitality, S28 is a source-supported industry capability designed to merge destination, hotel, and cruise sailing records across suppliers before enriching missing facts. Its adaptation boundary requires dedicated field contracts for each supplier feed so that conflicts and provenance differences are preserved, while live catalog integration remains to be implemented.

Once catalog entities are resolved, the downstream layer manages constraint-based planning. In the Agent OS module, the Plan and adjust work (S07) skill pack accepts a Natural-language goal, time and resource constraints and executes a sequential loop: Complete the constraints (assisted) to clarify hard requirements and preferences; Gather candidates (assisted) to retrieve provenance-backed options; Plan and compare (assisted), which can leverage versioned itinerary planning and replanning capabilities to produce draft plans and version diffs; Approve changes (human review), where a human selects and locks a plan version; and Refresh execution data (assisted) to update quotes, task states, and pending changes. While S07 is also a source-supported capability for travel—turning travel dates, budgets, and preferences into comparable itineraries—any conflicts surfaced during quote and inventory refreshes require re-confirmation, and an approved plan version does not constitute a completed booking. By contrast, the Check places and routes (S27) skill pack (resolving coordinates, adding weather and timing context, calculating route candidates, and reviewing routes on a map) carries a transferable tag only for logistics and has no travel industry tag; in travel scenarios it serves strictly as a general workflow pattern for address disambiguation and map review, without promising optimal routing or real-time passability.

Architectural honesty requires stating current boundaries clearly: every skill pack on the site is a proposed composition demonstrated with synthetic data and not yet connected to live services. While underlying components reflect working code verified through static source inspection, a source-supported industry label means only that the source repository has an explicit domain association—it makes no claims about customer deployments, production outcomes, or commercial ROI.

Pre-Pilot Checks for Travel and Hospitality Leaders

Before funding an intelligent itinerary planning initiative, a CEO, CDO, or head of operations can apply concrete pre-pilot checks:

• Audit the gray-zone queue in catalog ingestion: Verify whether multi-supplier hotel, cruise, and venue pipelines separate high-confidence matches from ambiguous records requiring human review, while preserving field-level provenance.
• Separate constraint verification from text generation: Confirm that hard constraints—budgets, party rooming rules, and operating windows—are tracked and diffed by versioned state machines rather than left to conversational memory.
• Enforce re-approval on inventory refresh: Ensure that when live quote or availability refreshes conflict with a previously approved itinerary version, the workflow halts and routes the diff back for human confirmation rather than treating a planning draft as a confirmed reservation.