On 28 August the Lodging Domain Tech Council filed the first UCP capability that does not live under shopping. PR #780 introduces dev.ucp.lodging.booking and a cancellation-policy extension — 32 files, roughly 4,900 added lines, both transports, filed on behalf of the whole council against the charter that created it.
It is still open. Nothing here is live, nothing is final, and the review is where the interesting part is happening. But this is the first time a UCP vertical has produced a spec instead of a roadmap, and it is worth reading closely.
The PR's own motivation section opens like this:
A bookable lodging unit is not a simple SKU.
We have made that argument at some length. It is more useful coming from the council.
The room that August built
UCP v2026-08-25 moved the payment constructs out of shopping/ and into the cross-vertical common/ group, and pulled shared primitives into common/types/. We described that at the time as the room being made for the Food and Lodging councils. This PR is the first vertical actually moving in, with a new top-level lodging/ schema group alongside shopping/ and common/.
You can see the refactor paying for itself in the file list. The PR adds one new shared primitive — common/types/date_interval — and otherwise reaches into common/ rather than duplicating. The four payment capabilities that shipped in August wire straight onto lodging booking: dev.ucp.common.payment.terms, .split_payments, .authentication and .ap2_mandate. A deposit schedule on a hotel booking is the same construct as a deposit schedule on a retail order, which is the entire point of having moved payment out of shopping in the first place.
That is what a well-timed refactor looks like three days later.
Four things a reservation does that a cart doesn't
The capability is built around four dynamics the PR argues retail checkout does not model.
A room rate is a compound binding, not a SKU. A bookable unit binds four things at once: the physical room category (room_details), the commercial rate plan (rate_plan), a date interval (itinerary), and an occupancy configuration. Retail has one identifier; lodging has four dimensions that must agree. The spec expresses this as a room_rates[] array where each entry carries all four, with an id like rt_luxury_queen__rp_avg_base_rate that makes the compound explicit.
The buyer is often not the guest. The capability separates booker — the legal contracting and paying party — from a flat guests[] pool, with guest_assignments[] mapping specific guests to specific rooms under primary_guest or additional_guest roles. Corporate travel, proxy bookings, family reservations and multi-room stays all stop being edge cases the moment that separation exists in the schema rather than in a comment field.
There is a quiet privacy decision inside it, too: guest IDs are generated by the platform, in the platform's namespace, so guest records can be referenced structurally before any personal data is transmitted. The example shows a second guest with a name and no contact details at all.
Discovery has to survive into the session. Rates found upstream during search are passed in as minimal keys, and the business then authoritatively validates availability and expands the response with titles, capacity limits, calculated totals and policy terms. Inventory authority, pricing and Merchant of Record responsibility stay with the business. That division is doing real work — it is the difference between an agent quoting a price and an agent being told a price by the party that has to honour it.
Cancellation terms have to be answerable without scraping. Which is where the review gets interesting.
"Is it refundable?" and "what will it cost me?" are different questions
The cancellation extension decorates the core policies[] primitive with a tri-state classification — refundable, partially_refundable, non_refundable — plus a human-readable description and a link to the property's policy document.
The PR is explicit about the goal: platforms should be able to answer buyer questions such as "Is this refundable?" and "What is the penalty cutoff?" deterministically, "without scraping or parsing external web pages." That framing is itself notable. A standards body writing down that the current answer is scraping is a standards body describing the problem accurately.
On 31 August a contributor raised the gap in review, and it is a precise one. The tri-state classification answers the first question. The second question — the cutoff, the timezone anchor, the sequence of penalty windows, the financial outcome, the no-show consequence — remains entirely inside the free-text description. The PR's own example, "cancel before July 10 for full refund; cancellations between July 10 and July 14 incur a one-night penalty," still requires a platform to parse English before it can tell a buyer what cancelling on the 12th actually costs. And refundability is itself time-dependent: the structured object states a classification without stating the instant at which it was evaluated.
What makes the review comment worth reading rather than just noting is that it arrives with evidence. The contributor validated a tiered, anchor-relative policy shape against roughly forty real cancellation policies across lodging, ticketing and services, found that the recurring deterministic core is an anchor plus ordered tiers with outcomes expressed as percentages, fixed fees or unit deductions like "one night", and published an executable schema, an evaluator and test vectors — raised separately as discussion #776. Two incremental options are on the table: keep v1 classification-only and track structured deadlines as a follow-up, or add an optional structured schedule alongside refundability while keeping the description as the universal fallback.
That is the shape of the whole machine-readability question in one thread. A classification is cheap to declare and easy to get right. A penalty schedule is expensive to declare and is the thing a buyer actually needs. Which one a spec requires determines whether "structured cancellation policy" means an agent can compute your refund, or only that it can repeat an adjective back to you.
What the first version deliberately doesn't do
Two exclusions are stated plainly, and both matter for anyone planning against this.
Upstream lodging search and discovery is out of scope — the capability starts once you have a rate to book. And post-purchase reservation management is out of scope: modifications, cancellations and check-in are deferred to future order extensions.
That second one is worth sitting with. Booking a hotel room is the short part of the relationship. Moving the dates, adding a night, changing the guest name, cancelling within the penalty window — that is where a reservation actually lives, and where the cancellation policy stops being a disclosure and becomes a calculation. The first version specifies the purchase and leaves the life of the booking to a later phase. Perfectly reasonable for a v1; just not the whole job, and the PR does not pretend otherwise.
The checklist also shows tests not yet added and Python models not yet regenerated, which is a normal state for a large capability PR in its first week of review.
Where this lands for us
We have written about this vertical from the outside for months — what a room booking needs that a cart doesn't, how it looks from the hotelier's side, how it compares to NDC, and the council forming three weeks ago. Charter in June, council in August, capability filed in review by the end of the month. That is a fast sequence for a standards body, and it is the first vertical to complete it.
What happens next is the part we measure. A capability in review is a declaration of intent; an implementation in the wild is an observation. Between those two sits the gap this whole business exists to watch — and lodging is about to become new ground on that map, with distributors, hotel groups and property systems all landing at different speeds against a spec that is still moving.
We will report it the way we report everything: from the public record, the same way for every business, as it ships.
About UCP Checker
UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.
Sources
- PR #780 — Introduce Lodging Booking Capability and Cancellation Policy Extension
- Issue #543 — Lodging Domain Tech Council charter
- Discussion #776 — Corpus-validated cancellation policy type for
policies[] - UCP v2026-08-25 release
- Related coverage: Lodging gets a technical council · The lodging charter and roadmap · What UCP for Lodging needs to handle · A hotelier's guide to agentic booking · UCP vs NDC · The v2026-08-25 spec update · UCP for Lodging vertical guide