HOS AIHOS AI
HOS 0.1 · Draft · Positioning

HOS, HTNG and OpenTravel

They carry the messages. HOS makes the facts trustworthy.

OpenTravel and HTNG have spent more than twenty years getting hotel systems to talk: rates to channels, bookings to the PMS, check-ins to door locks. HOS builds on that work. It answers the question their messages leave to every project: when systems disagree about a room or a stay, what is true, who says so, and can a person or an AI agent act on it?

Three standards, three questions

Each one answers a different question. Only one answers the last.

Since 1999 · OpenTravel Alliance

OpenTravel

“Can I sell and book this room?”

Built for
Shopping, availability, rates and reservations between travel systems: GDS, CRS, channel managers, booking engines and the PMS.
Shape
The OTA XML message suite, published since 2001. Since 2018, a 2.0 object model that also produces JSON Schema and REST contracts.

Since 2002 · now part of AHLA

HTNG

“How does this system plug into the PMS?”

Built for
Interfaces between hotel systems: check-in notices to locks, phones and TVs, folio postings, payments, event subscriptions, and HTNG Express for light PMS integrations.
Shape
Web-service interfaces built on OpenTravel's message conventions, WS-Eventing subscriptions, and JSON APIs for HTNG Express.

Since 2026 · 0.1 draft

HOS

“What is true about this stay and this room, and who says so?”

Built for
Operational facts that every system on a property shares, for the staff and the AI agents who act on them.
Shape
CloudEvents facts with provenance, producer manifests that declare authority, replay rules, and a public conformance corpus.

The gap, in HTNG's own words

The industry has already named the problem.

HTNG Express exists because operations systems wait too long for basic data from the PMS. Its README, in HTNG's official repository, puts it plainly:

“Vendors need to learn basic information about who is in the room, understand the state of the room, and potentially post charges.”
HTNG Express README, github.com/HTNG/htng-express
“The result is that timelines are extensive for very basic needs, and innovation is stifled for the industry.”
HTNG Express README, github.com/HTNG/htng-express

HTNG Express makes that data quicker to fetch from one PMS. HOS makes it trustworthy across all of them: who is in the room and what state it is in, as facts with a source, a time and a declared authority, for every system on the property at once.

One room, two answers

When the front office and housekeeping disagree, who wins?

HTNG Express's example room carries two occupancy statuses: one from the front office, one from housekeeping. Hotels run a discrepancy report for the rooms where they differ. Every system that reads both has to pick one, and each vendor picks for itself.

HTNG Express · example room, verbatim
{
  "room_number": "1000",
  "room_type_code": "KNSM",
  "maid_id": "0",
  "status_service_requested": "MAKE_UP_ROOM",
  "is_inventoried": true,
  "status_front_office_occupancy": "OCCUPIED",
  "status_housekeeping_occupancy": "OCCUPIED",
  "status_housekeeping_cleaning": "INSPECTED",
  "status_inventory": "NONE"
}

Two views of occupancy, side by side. Which one is right is left to the reader.

HOS 0.1 · the manifests decide
{
  "urn:hos:pms:demo": {
    "type": "unit.status_changed",
    "dimensions": ["occupancy", "commercial"],
    "authoritative": true
  },
  "urn:hos:housekeeping:demo": {
    "type": "unit.status_changed",
    "dimensions": ["occupancy"],
    "authoritative": false,
    "note": "Room attendants report what they see; the PMS is the occupancy authority."
  }
}

One authority for occupancy at this property. The other view is still recorded, marked not authoritative.

See it happen. In the late check-out scenario, a room attendant finds the room empty and reports it vacant. HOS records it and keeps the room held: an empty room is not a checked-out guest. The risk resolves only when the PMS, the declared authority, records the departure.

Built into the contract

Six answers every integration renegotiates. HOS writes them down once.

A message says what its sender believes. HOS adds what a receiver needs to rely on it, in the same way for every producer. Each answer can be replayed in the live demo.

01

Who is right

Each producer's manifest declares what it is the authority for, per property, event type and unit status dimension. One authority at most. Every other value is kept and shown as a conflict, never merged away.

Early arrival · delivery 9

02

What to ignore

Undeclared means denied. A producer can only publish what its manifest declares for that property, so a system cannot quietly start deciding what it was never trusted with.

Early arrival · delivery 7

03

When it happened

Every fact says when it occurred and when it was recorded, whether that time is exact or only a last modification, and which property time zone and business date it belongs to.

Late check-out · deliveries 10–11

04

Twice, late or missed

Delivery is at least once. Duplicates are dropped on source and id, the latest occurrence wins whatever the delivery order, and each producer declares how far back it can replay and whether it sends snapshots after an outage.

Room out of order · delivery 10

05

What stays out

Data objects are closed. Guests are pseudonymous ids. Names, contact details, payment data and message content never enter HOS; a message becomes a signal, such as an expected arrival time.

Early arrival · delivery 10

06

Whether an implementation is right

Three public scenarios, 42 deliveries, and the exact dispositions, readiness and situations an implementation must reproduce. Anyone can replay them through their own implementation today.

The conformance corpus

The contrast is by design, not a defect: a booking needs the guest’s profile and a payment guarantee, so OpenTravel’s reservation notification can carry both, and HTNG Express’s example reservation has fields for the guest’s name, phone and email, for the systems that contact the guest. An operational fact does not need any of it, so HOS leaves it where it is.

Better together

Three layers. HOS adds the one that was missing.

HOS does not replace distribution or device interfaces, and it never sends a booking or cuts a key. It sits beside them and turns what they do into facts everyone can trust.

  1. 1Sell and book

    Channels, GDS, CRS and booking engines exchange availability, rates and reservations with the PMS.

    OpenTravel

  2. 2Plug in

    The PMS feeds locks, phones, TVs, POS, payments and guest apps through agreed interfaces.

    HTNG

  3. 3Observe and trust

    Every system publishes what happened, with its source and authority. Staff and agents read one traceable picture.

    HOS

Keep their identifiers

A HOS reservation keeps the confirmation numbers other systems issued as typed external references: who issued them, what kind they are, and whether they were verified.

Publish from what you have

A system that already receives an HTNG check-in notice or an OpenTravel reservation notification can publish the matching HOS fact, as HOS's experimental adapters already do from Mews, Apaleo and Cloudbeds payloads.

Rip nothing out

Your channel manager, CRS and door locks keep their interfaces. HOS 0.1 observes; controlled action comes later, and only with a declared authority and human approval.

Where HOS is behind

Credit where it is due.

OpenTravel and HTNG have more than two decades of adoption, published releases and production integrations behind them. HOS 0.1 is a draft. Its scenarios are synthetic, its three PMS mappings are unofficial, no implementation is certified, and no producer publishes a signed manifest yet.

HOS covers the operations around a stay: reservations, stays, rooms, housekeeping, maintenance and guest signals. It has no rates, availability, folio or payment messages, and none is planned. That is OpenTravel’s and HTNG’s ground, and they hold it well. HOS earns its place only if it makes their messages more useful.

Proof, not promises

Don't take our word for it. Replay it.

Every claim this page makes about HOS is backed by a published file you can run through your own implementation.

Sources

What this page relies on.

HOS AI is not affiliated with the OpenTravel Alliance, HTNG or the American Hotel & Lodging Association. Their names describe their public specifications; this page is our reading of them, checked on 25 September 2026.