One hotel. Three truths. No borrowed identity.
Tamga is real. Tamaga Hotel is not. This demonstration shows how Tamaga Hospitality can connect destination knowledge, rooms, direct booking and structured data without borrowing another property’s identity.
Tamga is real. Tamaga Hotel is not. The hotel was created to demonstrate how Tamaga Hospitality can connect destination content, rooms, direct booking, customer relationships, structured data and daily hotel knowledge without inventing a real business or borrowing another property’s identity.
Three names, three different entities
The names are related. Their legal and operational identities are not.
Tamga
A real village on the south shore of Issyk-Kul.
Tamaga Hotel
The fictional ten-room property shown throughout this website.
Tamaga Hospitality
The real Drupal-based hospitality product being demonstrated.
Fictional boundary
What has been invented
The following are fictional:
- the hotel;
- its architecture;
- its rooms;
- its hosts and guests;
- its address;
- its offers and prices;
- its availability;
- its policies;
- its meal service;
- its reservations;
- its relationship history.
The hotel has no star rating, reviews, awards, historic founder or listing on an OTA.
What is real
The broader geography is real.
The implementation principles are real:
- Drupal;
- Schema.org Blueprints;
- BEE Hotel and Commerce;
- semantic content relationships;
- multilingual publishing;
- direct-booking workflows;
- structured policies and services;
- CRM contact and relationship management;
- Guest Memory;
- workflow automation;
- schema and channel previews.
Why use a fictional hotel?
A fictional property allows the product to demonstrate a complete hospitality system without:
- misrepresenting a real hotel;
- exposing real guest information;
- borrowing real reviews;
- creating fake availability for an existing business;
- forcing one pilot property to represent every target use case.
It also allows the demo to include the operational specificity of a real small hotel: four room types, ten physical rooms, families, access, meals, offers, arrivals, providers, press and returning-guest context.
Operational safeguards
What the booking flow does
The booking route creates a test reservation only.
It does not:
- reserve physical accommodation;
- collect real payment;
- send a valid travel confirmation;
- create a claim against a real hotel.
Confirmation pages and messages are marked [DEMO].
Search and structured data
The immersive hotel environment should not create a false public hotel entity.
Hotel, room and Offer mappings can be inspected through the demo’s entity and channel previews, while crawlable output remains controlled.
No fake address, coordinates, review score or real-world availability should be supplied to hotel-search services.
For hotel owners
What hotel owners are meant to see
The demo is not asking every property to look like Tamaga Hotel.
It is showing that the knowledge already held by a small hotel can become:
- attractive public content;
- a coherent booking journey;
- structured data;
- reusable guest communication;
- a relationship history;
- an owned digital asset.
Return to the hotel or continue to Tamaga Hospitality on the main product website.
Explore the demonstration
Choose a safe guest journey or an inspection layer.
Safe guest scenario
Try the test booking journey from a guest’s point of view.
Channel Lens
Inspect the demonstration’s controlled public representations.
Host Lens
Reveal the sources behind the guest-facing hotel homepage.
This page explains what is real, what is fictional and what the Tamaga Hospitality demonstration is designed to prove.