AI HOSPITALITY ALLIANCE · WORKGROUP 2 · EVENT REQUIREMENTS
Seven delivery requirements, the minimum envelope, capability tiers and seven verification checks.
Overview
Minimum delivery semantics apply to events from systems of record and to downstream consumers. They do not prescribe transport, broker, serialization or the business event dictionary.
Business event schemas and universal retention thresholds are not prescribed.
Download PDF ↗At-least-once delivery is the minimum. Consumers must produce the same outcome when an event is delivered more than once. Do not rely on an exactly-once guarantee across independently operated vendor boundaries; require idempotent consumption and verify end-to-end outcomes. Transport delivery alone does not prevent duplicate charges, messages or work orders.
Events relating to the same reservation, stay, or unit must be consumable in the order the state changes occurred. Ordering across unrelated resources is not required and should not be demanded, because global ordering is rarely offered and is usually a scalability liability.
Consumers must therefore use event time rather than receipt time when reasoning about sequence, and must tolerate a later event arriving before an earlier one across different keys. Workflows that assume global order will misbehave under load, which is exactly when they matter.
Overview of the blueprint sets the test that an incident can be reconstructed across vendors and systems. That test is met or failed at the event envelope. The minimum fields are listed in Minimum event envelope of this annex.
In particular, the correlation identifier must survive the hop between systems. An event that arrives without a correlation identifier terminates the audit trail at the vendor boundary, which is precisely where reconstruction is hardest and most needed.
Requirements: a published schema per event type, a major version identifier carried in the event, additive-only field changes within a major version, a stated deprecation window before a breaking change, and consumers that ignore unknown fields rather than rejecting them.
The consumer obligation matters as much as the publisher obligation. A consumer that rejects unknown fields converts every additive publisher change into an outage.
The publisher states a retention window and offers a documented method to re-request events for a given resource, or for a time range, within that window.
This is the requirement most often missing in practice and the one with the largest operational consequence. Without it, a consumer outage of any duration produces permanent divergence between systems that no automated process will detect and no automated process will repair. The recovery path becomes a human comparing two systems by hand, which is not a recovery path at scale. Plan reliability and assurance lists dependency outage as a condition the implementation must define behavior for. Replay is that behavior.
Undeliverable events land somewhere an operator can see, with a count and a cause. A dead-letter queue, a failed-delivery log, or an equivalent, exposed through an interface the hotel can reach rather than only through vendor support.
A silently dropped event is more dangerous than a failed API call. A failed API call returns an error to a caller who can act on it. A dropped event produces no signal at all, and the first indication is a guest arriving at a room the lock system was never told about.
Some systems will not publish events, and the blueprint should not pretend otherwise. Where an integration falls back to polling, the integration declares its polling interval and the resulting worst-case staleness, and every dependent workflow declares whether it tolerates that staleness.
This converts an unstated assumption into a documented constraint, which is what allows an operator to decide whether a workflow is safe to automate at all.
| Field | Required | Purpose |
|---|---|---|
| Event identifier | Yes | Unique per event. The de-duplication key that makes at-least-once delivery safe under E1. |
| Event type and schema version | Yes | Lets a consumer route and parse without inference. Carries the major version required by E4. |
| Resource type and resource identifier | Yes | The stable identifier of the reservation, stay, unit, guest, or folio affected. Also the ordering key under E2. |
| Event time | Yes | When the state change occurred, not when the message was sent. The basis for sequencing under E2. |
| Publisher identity | Yes | Which system emitted this. Required for the attribution test in Overview of the blueprint. |
| Correlation identifier | Yes | Ties this event to the workflow, guest thread, or originating action that produced it. Carried across vendor boundaries under E3. |
| Property and tenant identifier | Yes | Scopes the event. Without it, a portfolio-shared orchestration layer cannot enforce property-level isolation. |
| Acting principal and agent | Where applicable | Present when the state change was caused by an agent or a staff action rather than a system process. Feeds the audit record. |
| Payload | Yes | The changed state, or a reference sufficient to read it. See the note below. |
| Sequence or version of the resource | Recommended | Lets a consumer detect that it has missed an event, rather than discovering the gap later through divergence. |
Field names are illustrative. Prefer identifiers and change indications with sensitive content read through a permissioned interface; the full-state versus change-only versus reference payload choice still needs explicit workflow policy. Use a resource sequence or version to detect gaps; event timestamps alone do not guarantee correct ordering under clock skew.
| Tier | Capability | Implication |
|---|---|---|
| EV0 | No event support | Declare how and when state changes are discovered. |
| EV1 | Polling only | Declare polling interval, cost and worst-case staleness. |
| EV2 | Push without replay | Document reconciliation or backfill for outages; push alone does not establish recoverability. |
| EV3 | Push with replay and versioned schema | Meet E1–E6 and the stated retention window. This is the target for check-in fan-out without standing manual reconciliation. |
| ID | Procedure | Demonstrated when |
|---|---|---|
| T1 | Deliver the same event to the workflow twice. | One outcome is produced. No duplicate write, message, or task. |
| T2 | Deliver two events for the same reservation in reverse order of event time. | Final state reflects the later event. The workflow does not apply the stale one. |
| T3 | Trace one guest-facing action from origin to final receipt across at least two vendors. | A single correlation identifier appears at every hop. |
| T4 | Publish an event containing a field the consumer does not recognise. | The consumer processes the event and ignores the unknown field. |
| T5 | Disconnect a consumer for the stated replay window, then reconnect. | Every event for the affected resources is recoverable, either by replay or by documented backfill. |
| T6 | Force a delivery failure to a downstream system. | The failure appears in an operator-visible location with a count and a cause, without contacting vendor support. |
| T7 | Ask any system at EV0 or EV1 what its worst-case staleness is. | A documented number exists, and every dependent workflow has been assessed against it. |