Changelog
Nothing is announced before it exists.
This changelog lists released artefacts and published decisions, newest first. HOS AI does not promise a content rhythm before the project has one.
1 October 2026
DraftObserve closes on the evidence of demo environments, and Act opens as a draft.
- HOS 0.1 Observe set out to show that systems can share hotel facts with their sources and authority, and that an early arrival in a room not ready can be detected from them. It now has the HOS Core and HOS Events drafts, the hos command and the SDK, three replayable arrival scenarios, and producers for Mews and Apaleo that keep their facts across restarts, sign their manifests and are trusted only through keys their consumers admit. Both ran read-only against the demo environments of Mews and Apaleo.
- One proof is still open: no hotel has run the scenario yet, and no hotel operator, PMS vendor or integrator has reviewed it. The founder closes Observe on this evidence so that work on Act can start, keeps that proof open, and will publish its results when a pilot hotel brings them. We are looking for partner hotels on Mews or Apaleo.
- Act opens as a draft: commands a person approves, starting with assigning a room, tried in a test environment first. Nothing in HOS writes to a hotel's systems yet, and the mappings remain experimental and unofficial.
1 October 2026
DraftThe pilot producer signs its manifest, and its consumers check it.
- The producer signs its manifest every day and publishes it with its signature and public keys, as HOS Events 0.1 specifies. HOS 0.1 signs the manifest, not each event.
- A consumer processes a producer's facts only once the manifest verifies with keys its own configuration admits. A manifest altered, expired, signed with a key it does not admit or by another producer counts as no manifest, and none of that producer's facts is applied. Tests run a key rotation, then the revocation of the old key.
- Before reading anything, the producer checks it reads the right property: the Mews tokens must open the expected enterprise, and the Apaleo app must have the read scopes it needs. It only ever reads, over HTTPS.
1 October 2026
DraftThe Mews and Apaleo mappings run as a persistent producer.
- A producer for the Observe pilot polls Mews or Apaleo every 2 minutes, read-only, and keeps what it publishes in a database: the HOS id of each PMS entity, what its adapter has told HOS, and every fact once, as first written. A producer that stops, even killed outright, carries on where it was and never publishes a fact twice with another content.
- Systems that receive its facts read them at least once from a position of their own, or as a JSON Lines export kept for 30 days. A synchronisation status says when each property was last read, and calls its facts stale after 10 minutes without a successful poll.
- It ran read-only against Mews's demo enterprise and the sample hotels of an Apaleo developer account. It prepares the Observe pilot; no hotel takes part yet, and the mappings remain experimental and unofficial.
28 September 2026
DraftThe documentation of the hos command and the SDK is complete.
- Seven guides take a reader through each task: validating files, replaying a stream, testing a system that receives HOS facts in any language, checking what a producer publishes, signing and publishing a manifest, running the checks in CI, and building an adapter with the SDK, around a complete example that runs.
- The references describe every command and option, every function of the SDK, the conformance protocol, and each of the 22 rules the tools report, with an example that breaks it and how to fix it. Troubleshooting has an entry for every message of the hos command, and Get help says what to send.
- Every output the pages show is checked against what the tools print, every example runs in the tests, and diagrams and replayable terminals explain the key steps.
26 September 2026
DraftThe hos command and the SDK have their own documentation.
- A first set of pages takes a reader from nothing to a first result: what the two tools do and do not do, the ten ideas behind them in plain language, installing them on Windows, macOS or Linux, and a ten-minute quickstart that validates an event, reads an error and replays an early arrival.
- Read a HOS report explains, for readers who do not write code, what a conformance or producer report says, what it does not prove, and what to ask a vendor.
- Every command is shown for PowerShell, the Command Prompt and macOS or Linux, and every output shown is checked against what the hos command prints. The guides and references follow; their pages say what they will cover.
26 September 2026
DraftThe hos command and the SDK are on npm.
- @hos-ai/cli 0.1.0-alpha.1 gives the hos command. It validates HOS files, replays recorded event streams, runs the three conformance scenarios through an implementation in any language, checks what a producer publishes against its manifest, and signs and verifies manifests. It carries the schemas and the scenarios, so it works offline.
- @hos-ai/sdk 0.1.0-alpha.1 offers the same in TypeScript, in Node or in a browser: types generated from the schemas, validation, the HOS Events processing rules, facts with stable ids, and signed manifests.
- Both are alphas, as HOS 0.1 is a draft, and they are published from GitHub Actions with provenance. Passing the conformance scenarios is a self-check, not a certification.
26 September 2026
DraftProducers sign their manifests.
- HOS Events 0.1 now specifies how a producer signs its manifest: a detached JWS on the manifest's canonical form (RFC 8785), with Ed25519 or ES256, the key's id, when it was signed and when it expires. It is published beside the manifest at /.well-known/hos/manifest.jws, with the producer's public keys at /.well-known/hos/jwks.json.
- A consumer verifies a manifest it retrieves before trusting any declaration in it; a manifest that fails counts as no manifest. Keys rotate: an old key stays published until everything it signed has expired, and a compromised key is removed at once.
- Nine test vectors give the verdict a verifier must reach, from a valid signature to alg none, and a fictional producer shows the three files it serves. The manifest schema drops its reserved signature member: the signature travels beside the manifest.
26 September 2026
DraftThe specification text is published under CC BY 4.0, and the legal pages are complete.
- The HOS Core 0.1 and HOS Events 0.1 drafts can be reused and adapted under CC BY 4.0, with credit. Schemas, examples and conformance files stay under Apache-2.0.
- The legal notice, privacy notice and accessibility statement replace their templates, and terms of use are added. They name the publisher, the host and each provider that processes form data, with its location and transfer safeguard.
- Form submissions are now deleted automatically twelve months after the last exchange, as the privacy notice states.
26 September 2026
DraftThe Apaleo mapping runs against a live account, and a Cloudbeds check is ready.
- Read-only live checks now exist for Apaleo and Cloudbeds, as for Mews. Each fetches what an integration fetches before its first webhook, runs it through the adapter and reports facts by type, schema errors, what a second pass would publish, and today's arrivals as the reference projection sees them. Reports keep no PMS payloads, guest data or credentials.
- Apaleo, against the five sample hotels of a developer account: 740 facts, every one valid HOS 0.1, and none published twice.
- Three arrivals added to the Paris sample hotel read as set up: a clean room ready, a dirty room not ready, and a room under maintenance blocked, with a room-readiness risk raised.
- A live account showed what the documentation did not: Apaleo refuses an OutOfOrder maintenance on a room already assigned to a reservation. The Cloudbeds check has not run on a real property yet.
25 September 2026
DraftThe Mews mapping runs against Mews's live demo.
- A read-only live check runs the Mews adapter against a live Connector API environment. It calls only configuration and getAll operations.
- Against Mews's two public demo enterprises: 689 reservations and 2,584 resources gave 3,485 facts, every one valid HOS 0.1, and none published twice. Every Mews field the adapter reads was present, and every state it met is documented.
- The first runs changed the integration. Dorm stays are assigned to beds, so beds are now units. Accommodation is picked by resource category, because parking and meeting rooms are also sold by the day. And the shared demo tokens are rate-limited, so the check retries.
25 September 2026
DraftHOS, HTNG and OpenTravel: where HOS fits.
- A new page sets HOS beside OpenTravel and HTNG: the question each one answers, the six answers HOS writes into the contract, how the three layers fit together, and where HOS is still behind.
- Every statement about OpenTravel and HTNG is sourced from their public specifications and repositories, listed on the page.
25 September 2026
DraftTwo more arrival scenarios: a room out of order and a late check-out.
- Room out of order: a leak takes the assigned room out of order on the arrival morning. A maintenance system plans the repair, the PMS copies it without being the authority, an older revision syncs late, and the front desk moves the guest. Fourteen deliveries at a property in Lisbon.
- Late check-out: a late check-out is granted in a room already assigned to a same-day arrival. A room attendant's glance is not a check-out, a stale plan is replayed, and the check-out reaches HOS after the dirty status. Fifteen deliveries at a property in Toronto.
- The reference projection now treats a unit another guest still holds as not ready, and raises the risk when that guest is not due to leave before the arrival. A resolved risk says why: unit_reassigned, unit_vacated and departure_before_arrival join the reasons. The early-arrival scenario and its expected outcome are unchanged.
25 September 2026
DraftHOS 0.1 draft: scheduled maintenance windows.
- Core gains a ninth entity, the maintenance window: a planned period when a unit is out of service or cannot be sold, the statuses it imposes, and an optional reason.
- Two unit events: unit.maintenance_scheduled, published again whenever the plan changes, and unit.maintenance_cancelled. The catalogue grows to fifteen types. A plan never changes a unit's current statuses; unit.status_changed does.
- The reference projection raises a room-readiness risk when a window blocks the assigned unit at the time the guest is expected, even without an early arrival. When the window goes, it resolves the risk as unit_available.
- The Mews, Apaleo and Cloudbeds adapters map resource blocks, maintenances and room blocks. Cloudbeds block dates are read as nights, pending confirmation on a live property.
25 September 2026
DraftHOS 0.1 draft: what the PMS mappings showed was missing.
- Two stay events: stay.unit_unassigned releases a unit from a stay, and stay.check_in_reverted makes a stay expected again. The catalogue grows to thirteen types, and the reference projection handles both.
- Envelope: hostimebasis gains modified, for sources that only date an entity's last modification, and hosactor names who made a change, as a pseudonymous, producer-scoped reference.
- Core: a Property declares standard check-in and check-out times for sources that plan stays in days. A reservation for several units yields one Stay per unit, and a producer without a stable guest identity publishes no guest_id.
- stay.expected is due as soon as a stay is committed, and again when its planned times change; its business date is the arrival's. The Mews, Apaleo and Cloudbeds adapters use every addition; the conformance corpus and its expected outcome are unchanged.
25 September 2026
DraftExperimental Mews, Apaleo and Cloudbeds mappings replay the arrival scenario.
- Unofficial reference adapters map Mews Connector API, Apaleo API and Cloudbeds API v1.3 webhooks, and the entities an integration fetches for them, to HOS Events 0.1. They were written from each PMS's published documentation, packages or SDK, and are not endorsed by any of them.
- The PMS deliveries of the arrival scenario are recorded in each PMS's format. Replayed through each adapter, they reach the scenario's expected outcome. Delivery 7, a PMS task, has no counterpart in any of the three; Apaleo and Cloudbeds add the room's occupancy.
- The mappings exposed gaps in HOS 0.1: no event to remove a unit assignment or revert a check-in, no defined moment for stay.expected, no place for the actor of a change, and no way to say that a time is only a last modification. The draft now covers them.
24 September 2026
DraftHOS Core 0.1 realigned and HOS Events 0.1 draft published.
- Core 0.1 now has eight entities, including Tenant, typed external references, namespaced extensions, sensitivity classes and the four-dimension Unit status model (occupancy, housekeeping, maintenance, commercial), each with unknown.
- HOS Events 0.1: the envelope profile, eleven event types in five families, explicit snapshots, and delivery, ordering and replay rules.
- Breaking for the earlier draft: hos-event.schema.json is replaced by core, event-envelope and events schemas; hospropertyid becomes hosproperty, hostimezone becomes hospropertytimezone, and hostenant and hossubjects are required. task.completed becomes housekeeping.task.completed and stay.arrival_signaled becomes a signal in guest.message.received.
- Arrival readiness situations are now a non-normative reference. The conformance scenario grows to thirteen deliveries, adding snapshot recovery and a missing capability, and every event type has an example.
24 September 2026
DraftHOS Core 0.1 draft and the arrival-readiness scenario.
- Readable draft of HOS Core 0.1: entities, event envelope, processing rules and the arrival-readiness projection.
- JSON Schemas for HOS 0.1 events and Event Producer manifests.
- A synthetic conformance scenario of nine deliveries with its expected outcome, and a live replay.