The Protocol-Native PMS

Every protocol ADAPT works on ends in the same place. An AI agent can discover a room through an MCP server, settle it with terms attached, and file a dispute with a certified arbiter, but the room is assigned, the door code cut, the housekeeper dispatched, and the folio closed inside the property management system. If the PMS does not speak the protocols natively, everything upstream is a message that has to be re-keyed.

In the OTA era (2000–present) the PMS was one box in a chain: hotel, PMS, channel manager, OTA, guest. By 2020, 74% of US hotel bookings flowed through that channel-manager stack, and the PMS learned to speak to the world through a translation layer rather than directly. The layer worked, and it still does. But it was built to push inventory outward to gatekeepers, not to receive a settled, bonded, arbitrable reservation from an agent acting for a guest.

Protocol-native means four things terminate at the PMS rather than beside it. Discovery: the PMS publishes availability, rates, and restrictions from its own canonical record, through MCP, a REST API, and agentic markdown, without an intermediary copy. Settlement: the PMS receives the settlement event — funds cleared, reserve held, schedule attached — and opens the folio from it. Dispute: a filing under ADAPT-DRP pulls its evidence (the listing snapshot at booking, the encoded terms, the access and housekeeping logs) from the PMS, and the arbiter's decision writes back to the same folio. Guest bonding: the guest's trust status — Verified, Bonded, or New — arrives with the reservation and governs deposits, holds, and access rules at arrival. The rest of this article takes each in turn, then follows one reservation from discovery to checkout.

The difference is not a feature list. It is where each responsibility lives, and how many copies of the truth exist while it is being carried out.

The manifesto's complaint is familiar: an OTA reservation delivers a name and an arrival date, and the desk collects the rest awkwardly at check-in. The protocol-native alternative is not a bigger CRM. It is a guest record that belongs to the guest, is shared with the property by consent at booking, and travels with the traveler to the next property.

The proposed Guest Identity & Credentials working group (ADAPT-WG-002) is scoped to exactly this: portable, verifiable guest profiles that are not locked inside a platform account, with privacy-preserving identity for check-in. The trust status from ADAPT-DRP — Verified, Bonded, or New — is the first field in that record, because it is the one that changes what the property does at arrival: waive the incidental hold, require a deposit, or offer the verified-guest rate.

Consent is the design constraint, not an afterthought. The property receives what the guest agrees to share for this stay, retains it under its own obligations (GDPR and CCPA where they apply), and writes back only what the protocol specifies: stay completed, dispute filed or not, outcome. Preferences the guest chooses to carry — high floor, away from the elevator, late arrival — go with them. The PMS is the reader and writer of that record, which is why portability has to be a PMS capability rather than a marketing-platform feature. ExchangePMS lists guest profiles and history among its core capabilities for this reason, and its resident portal serves the same record to long-term tenants.

The clearest test of whether a PMS is protocol-native is what happens to the door. In the legacy stack, access is bolted on at the desk: a keycard cut on arrival, a PIN typed into a lock's admin app, revocation left to a checkout procedure someone may or may not run. In a protocol-native PMS, access is a function of reservation state.

The folio reference listing on this site shows the shape: folio book creates the reservation, and in the same transaction the system reports Door code provisioned 4892# (expires at checkout). The code is generated when settlement clears, remains dormant until check-in time, activates when the guest's identity is confirmed, is extended when a late-checkout charge posts to the folio, and is revoked at the checkout timestamp. Each of those is a reservation event, so each is logged, and the log is admissible evidence in a dispute about whether a guest arrived, when they left, or whether a unit was entered during their stay.

The same coupling handles the hard cases. A Tier 1 habitability dispute under ADAPT-DRP, where an arbiter authorizes an emergency release to fund alternative accommodation, is also an access event: the original code is revoked and a new reservation, if the property has one to offer, issues a new one. A no-show is a code that was never activated. An unpaid balance on a flexible-stay unit is a scheduled revocation the guest can see coming. ExchangePMS auto-provisions PIN codes for every reservation across all four of its modes, from a two-night hotel stay to a twelve-month lease, from one rule set.

Housekeeping is where the fragmented stack fails most quietly. The tasking app learns about a departure when someone tells it, the PMS learns the room is clean when someone tells it, and availability is republished when the channel manager next polls. Each hand-off is a place for a room to sit dirty and unsold or, worse, sold and dirty.

In a protocol-native PMS the reservation events drive the work. A confirmed, settled reservation queues a turnover for the departure date at booking time; the folio listing shows Housekeeping queued turnover · Mar 18 in the same transaction as the door code. Checkout, whether triggered by the guest, the desk, or the code's expiry, moves the unit to dirty and assigns the task. Inspection marks it ready, and readiness republishes availability to every consumer of the ARI record at once. A maintenance finding during turnover opens a work order that blocks the unit until it closes.

The reason to trigger from settlement rather than from the reservation alone is money. A reservation that has not settled is a hold; a reservation that has settled is a commitment the property can staff against. At a mixed-use property the same distinction drives capital work: ExchangePMS rotates roughly ten units at a time through renovation, and a rehab unit returns to inventory the way a hotel unit does, through an inspection event that republishes availability, rather than through a spreadsheet someone remembers to update.

The folio page describes the six layers a property runs — PMS, channel manager, RMS, CRM, housekeeping and maintenance, front desk and access — and the principle that each should map once to a shared vocabulary rather than N times to its neighbors. The same principle applies outward. A protocol-native PMS publishes one record, and each participant in the visitor economy reads the view of it they are entitled to.

• AI agents read availability, rates, restrictions, and policies through the MCP server (tools such as search availability, get rates, create booking), or through agentic markdown at /.well-known/hotel.md when no server is needed. Read operations are public; booking and payment authenticate with OAuth 2.0.
• Bedbanks and wholesalers read the same record through the REST API with net-rate contracts and resale terms encoded, so an event block auto-releases on schedule and rate leakage is detectable (see Bedbanks on Open Rails).
• Certified arbiters read the listing snapshot as it stood at booking, the encoded terms, and the access and housekeeping logs for a disputed reservation, and nothing else. The PMS is the evidence store ADAPT-DRP assumes.
• DMOs read aggregate dispute profiles and event-block commitments, and write the zone rules — local advisor commission, Tourism Development Fund contributions — that the settlement layer applies.
• The property's own desk and residents read the same record through the operator console and the resident portal. There is no second copy for staff.

The point is not that a PMS must build all of these adapters on day one. It is that they must all be adapters over one canonical record the hotel owns, so that a new protocol is a new adapter rather than a new vendor, the argument made at length in Your Hotel Should Speak Every Language.

Read end to end, a protocol-native reservation is a sequence of events, each of which changes the state of a room, a door, a task, or a balance. Here is the chain for a three-night hotel stay, followed by an illustrative log.

1. 1

   Discovery

   An agent queries the MCP server or reads the markdown file. The PMS answers from its canonical ARI record with rates, restrictions, and the policies that will become terms.

2. 2

   Reservation with terms

   The agent confirms. Rate, cancellation window, deposit, dispute reserve, and any zone split are attached to the reservation; the guest's consented profile and trust status arrive with it.

3. 3

   Settlement

   Funds clear on the encoded schedule; the reserve is held to checkout + 48 h; the folio opens from the settlement event. The property now has a commitment it can staff against.

4. 4

   Pre-arrival

   The door code is generated and held dormant; the turnover is queued for the departure date; the profile's preferences pre-assign the unit.

5. 5

   Check-in

   Identity is confirmed; the code activates; the incidental hold is set by trust status. The desk greets a guest it already knows rather than collecting an email address.

6. 6

   In-stay events

   A late-checkout purchase posts to the folio and extends the code. A maintenance issue opens a work order. A dispute filing freezes only the reserve and assigns an arbiter within two hours.

7. 7

   Checkout

   The code is revoked; the unit goes dirty and the turnover task is assigned; the folio closes against the settlement record; the reserve timer starts.

8. 8

   Post-stay

   Inspection republishes availability. At checkout + 48 h, absent a filing, the reserve releases. The guest's portable record gains one completed stay; the property's dispute profile is unchanged.

The reference implementation runs at the Exchange Building, a 19-floor, 200+ unit property at 9 N. Second Street in Downtown Memphis, built in 1910 as the Continental Bank Building and now operated as a hybrid of four revenue modes. ADAPT's founding operator built ExchangePMS because no available system would run all four from one record.

What the case study shows is that the four terminations described above are the same code paths regardless of mode. A lease and a two-night stay both create a reservation with terms, both settle on a schedule, both issue and revoke access, both trigger housekeeping or maintenance, and both are publishable through the MCP server, the REST API, and agentic markdown. The capability list on the workshops page — guest profiles and history, multi-mode units, automated access control, housekeeping workflows, night audit and revenue, OTA channel sync, MCP server publishing, maintenance and facilities, resident portal, local marketplace integration — is one system, not ten integrations.

It also shows the honest limits. OTA channel sync at the Exchange still runs over iCal for some channels, the lowest common denominator the platforms offer; that is an adapter over the canonical record, which is the design intent, but it is also a reminder that protocol-native on the property side does not make the gatekeepers protocol-native on theirs. Operational metrics — occupancy, revenue per unit, dispute rate, settlement latency — are shared with working-group members under NDA and are not reproduced here. The argument this article makes rests on the architecture, which is public, not on performance figures, which are not yet.

ADAPT proposes that the PMS be treated as the protocol's termination point and specified accordingly. The Hospitality Operations Working Group (HO-WG, ADAPT-WG-005) carries the work through ADAPT-HOP, the Hospitality Operations Protocol, and folio, its open reference CLI and MCP server: a shared verb set and schema for availability, rates, reservations, profiles, tasks, access, and settlement, so that each of a property's systems maps once to the protocol.

1. For PMS vendors: implement the four terminations natively — canonical ARI publishing, settlement-event folio opening, ADAPT-DRP evidence export, and trust-status handling at check-in — and expose them through MCP, REST, and /.well-known/hotel.md. The reference implementation informs the vendor integration guidance the register attaches to this article.
2. For operators on Opera, Mews, Cloudbeds, or any incumbent PMS: nothing has to be replaced first. Publish the markdown file, add the MCP adapter, and let the protocol reach the existing system through it, as the FAQ describes. Native termination is the destination, not the entry ticket.
3. For the pilot: run folio in production across the Exchange Building's 200+ units, instrument support load, data quality, dispute rate, and settlement latency, and submit ADAPT-HOP v1.0 for ratification with a published pilot report.

The working group needs PMS and building-OS vendors whose schemas will shape ADAPT-HOP, channel managers and RMS providers who know what a single surface must absorb, multi-unit professional hosts carrying the middleware cost today, settlement specialists, and agent developers who would rather drive one control surface than six integrations. The folio page has the open tracks and the session schedule; the pilot page has the building.