SO–002 · Building

Hospitality data infrastructure for independent and regional hotel groups. A canonical model, an encoded semantic layer, and adapters for the systems that actually feed the operation.

10100
Properties. The target scale.
1
Canonical model. One source of truth.
0
In-house data engineers required.
What it is

The layer underneath
everything else.

Meridian sits one layer below the applications a group already runs — the PMS, the channel manager, the CRM, the revenue management system, the booking engine, the loyalty platform — and provides what those applications cannot: a canonical model for hospitality data, an encoded semantic layer for every metric the group reports against, and adapters for the systems that actually feed the operation.

It is not a BI tool. It is the substrate underneath one. When a group builds a dashboard on top of Meridian, the metrics are consistent because the semantic layer enforces them. When the PMS vendor changes an API, one adapter gets updated and every consumer downstream continues working.

It is not a lakehouse. The lakehouse is primitives sold to organisations with internal data engineering teams. Meridian is finished hospitality intelligence, sold to groups whose competitive advantage does not come from operating data infrastructure.

Not this
A BI tool
Meridian is the substrate underneath a BI tool. Build any dashboard you want on top of it — the metrics will be consistent because the semantic layer enforces them.
Not this either
A data lakehouse
The lakehouse gives you primitives and assumes a data engineering team to assemble them. Meridian is the assembly, already done, for groups that don’t operate that team.
Definitely not this
Another integration platform
Point-to-point integrations multiply and break. Meridian is a canonical model in the middle: every source writes to it through an adapter, every consumer reads from a single interface.
Who it’s for

The groups everyone else
built around.

Independent and regional hotel groups at the ten-to-a-hundred property scale. Mixed branded and unbranded portfolios. Enough operational complexity to justify integrated intelligence, not enough scale to justify an in-house data engineering team.

If a group already operates a thirty-person data engineering function, Meridian is not the right fit. They are better served by horizontal infrastructure they can shape to their idiosyncrasies. Meridian is for everyone else.

Groups that have run a BI initiative and watched it stall at the dashboard layer.
Groups that have tried Snowflake and found it underused — substrate without application.
Groups that have built dashboards in Tableau and watched them drift back into spreadsheets.
Groups whose RevPAR has three definitions inside the same office.
Groups navigating a fourth PMS API change with point-to-point integrations that keep breaking.
Architecture

Three commitments.
One foundation.

Three architectural decisions shape every product choice. They are not features. They are the structural commitments that determine whether the platform survives year two.

01
The canonical model
is hospitality-shaped.
The entities are designed by people who understand that a stay is not a reservation and that a folio is not a payment. The schema is opinionated — it does not adapt to a group’s idiosyncrasies. It provides the shape every group’s data needs to land in.
Properties, reservations, stays
Guests, outlets, channels
Content, signals, rates
Folios, payments, corrections
02
The semantic layer
is encoded once and enforced.
RevPAR is computed by the platform, not by each consumer. Every metric has one canonical implementation which every downstream system reads from. The discipline is structural, not behavioural — the architecture does not allow three numbers to be computed.
RevPAR, ADR, net ADR
Pace, displacement, channel contribution
Segment definitions, stay value
Attach rate, cost per occupied room
03
The platform holds no PII.
Operational data and guest behavioural signals are separated by design. Behavioural signals are aggregated, tokenised, and never linked to identity. Marketing systems that need personally identifiable information connect to the systems that hold it. Meridian does not.
Anonymous guest profiles
Tokenised behavioural signals
Clean GDPR boundary by architecture
No identity linkage in the data layer
Where it stands

Building in 2026.
With design partners.

Meridian is being built in 2026. The canonical layer is in place. The semantic layer and the first source-system adapters are next.

We are currently working with a small number of design partners — hotel groups whose operational reality shapes how the product takes its first commercial form. The partnership is structured: their data, their workflows, and their constraints are what Meridian is being built against, in exchange for early access and a meaningful say in what the first version becomes.

The design partner cohort is small by intention. The groups in it are not beta testers. They are co-authors of a product that will serve groups like them.

For more on the infrastructure argument behind Meridian, read Why Hotel Groups Don’t Need a Data Lakehouse and What Kills Hotel Group BI Projects.

Active development · 2026
SO–002 · Meridian
Build status
Current state of the canonical layer, semantic model, and first adapters.
Canonical schema — hospitality entity model defined
Reference implementation at Valentín Son Bou, Menorca
Semantic layer — KPI encoding in progress
Source adapters — Cloudbeds, Mews, Opera
·
First commercial cohort — design partners
Meridian
Design partner programme

If your group is
navigating this,
the conversation is here.

We are selecting a small number of reference partners for Meridian. Independent hotels and boutique groups only. You provide data access. We build, deploy, and document. No budget required — just genuine interest in what this can actually do for a property like yours.

No pitch deck. No sales call. 30 minutes. Honest conversation.