HotelSentinel: Making Inconsistencies in Hotel Listings Visible

One hotel, several channels, different expectations

A hotel is described on its own website and on booking platforms. Room names, amenities, photos and descriptions are not necessarily updated at the same time. Across several hotels, regularly comparing these presentations becomes a substantial task.

The text does not need to be identical everywhere. A platform may use different image formats or translate room names. The useful differences are those that might affect a guest's decision: is a service included, does the displayed photo belong to the relevant room category, or is an important amenity missing from one channel?

My aim is to make these points traceable. A report should show which sources differ and what evidence supports the finding. A difference alone cannot establish which channel is correct or calculate lost revenue. The next step remains a business review by the responsible person.

The architecture: collect, structure, compare

HotelSentinel has three stages with separate responsibilities. Together they form a pipeline; not every stage needs an autonomous AI model.

Collector → Extractor → Reviewer
HTML + images → PlatformData → Score + report

• Collector: Loads the sources through a cloud browser for booking platforms and local Playwright for the hotel website. Image URLs are collected using rules. No business judgement is made at this stage.
• Extractor: An AI Agent turns the slimmed-down HTML into structured JSON containing the hotel name, description, rooms, rating and amenities. A normalizer processes the images and creates a uniform PlatformData object for each channel.
• Reviewer: Compares these objects against twelve criteria. Scoring uses rules without another LLM call and produces a grade, findings and recommendations.
• Core: Holds the shared data contract, snapshot layer and image and text metrics, including pHash for comparing gallery images.

A NestJS backend orchestrates audit cycles around the Python engine. The Angular frontend displays the portfolio and diff history, while webhook alerts report deterioration. This separation helps me trace an unexpected finding: was the source incomplete, the extraction wrong or the scoring rule unsuitable?

Snapshots make scoring repeatable

Live websites change. LLM extraction can also vary between runs or assign information incorrectly. HotelSentinel therefore stores one snapshot per hotel and day: collected HTML, downloaded images and normalized data, including the extraction result. The AI Agent is not called again when that snapshot is rescored.

The more precise rule is: the same snapshot and the same scoring logic with the same parameters produce the same grade. If I change a threshold, I can evaluate the stored state under the new rule without loading the websites again or repeating extraction costs. A changed grade then reflects a scoring change, not necessarily a listing change.

The report's fingerprint helps identify the data used. It does not prove that extraction was correct: a snapshot preserves errors too. Unexpected findings therefore need to be traceable to the stored source for review. Language models producing incorrect or unsupported information is also discussed in the documentation on reducing hallucinations.

Twelve criteria – and what a difference actually means

The reviewer checks twelve criteria in three groups:

• Structure and naming: room names, hotel name and number of categories.
• Photos and media: room photos, gallery photos, photo quality, quality differences across channels and low photo counts.
• Text and ratings: hotel description, room descriptions, review scores and amenities.

Negative points lead to a grade from 1 (critical) to 4 (very good). This summarises the rule-based comparison. Individual findings and the available evidence matter more for decisions than the grade alone. Unreachable platforms need to remain visible in the report; missing data is not proof that an amenity is absent.

This simplified example contains no measured project results:

Observation	What needs checking
Breakfast included versus an extra charge	Same room category, rate and travel dates? Only then can a possible contradiction be assessed.
Parking available versus no information	An information gap, not evidence that there is no parking.
Deluxe Doppelzimmer versus Deluxe Double Room	Possibly a translation of the same category, not an error based on the name alone.

Image similarity is also a signal, not proof of a correct room assignment. Perceptual hashing describes visual similarity; business interpretation needs additional context. (ImageHash: hash behaviour and comparison) A different review score is likewise not sufficient evidence of a misleading listing.

Six decisions that shaped the design

1. Give AI a bounded task. Instead of generating an overall judgement, I use the model to structure information. Scoring rules remain separate, allowing extraction and scoring to be investigated independently.

2. V3 replaces many platform-specific parsers. In V2, custom selectors for each platform needed maintenance after layout changes. V3 uses an AI Agent to extract information from slimmed-down HTML. This reduces that dependency while introducing a different review requirement: does the JSON make sense, and is each important value supported by the source?

3. Freezing helps debugging. A stored state lets me reproduce a finding and compare rules without also dealing with a website that has changed in the meantime. Reproducibility and correctness remain separate requirements.

4. Comparison conditions belong to the audit. Language, locale and travel dates affect the content displayed. A future booking window may expose different rooms but does not guarantee a complete list. When pages fail to load reliably, the report needs a visible data gap. Bounded retries and backoff form part of collection.

5. Not assessable is a useful result. Where the data does not support a clear conclusion, an open review task is more useful than an unsupported negative finding. This applies to business claims too: comparing listings does not produce a defensible revenue or ROI estimate.

6. The report needs to enable a next action. A grade alone says little about what a hotel team should change. Comparison becomes useful when the responsible person can inspect sources side by side, interpret the discrepancy and initiate a targeted correction.

Project facts

• Audience: Hotel groups and portfolio managers
• Timeframe: 2026
• Task: Compare public hotel listings and document points needing review
• Channels: Hotel website, Booking, Expedia / Hotels.com
• Engine: Python, AI Agents for extraction, Playwright, cloud browser, pHash
• Platform: NestJS, Angular, Qdrant

This article describes the project design and my decisions. The example table explains the approach; it is not a client report and contains no invented measurements.

What I learned – and what I want to explore further

Developing HotelSentinel gave me a practical understanding of how AI Agents are built, which tasks they can perform and where their limitations lie. I found the interplay between data extraction, clearly defined tasks and rule-based scoring particularly insightful.

I want to build on this experience. I am interested in adapting agent workflows and their underlying LLMs more closely to specific tasks through more precise prompts, appropriate evaluation methods and task-specific fine-tuning.

My goal is to use AI Agents more reliably and efficiently while systematically examining response quality, runtime and resource requirements. For me, HotelSentinel provides a practical foundation for continuing to develop this knowledge.