Identify the entities
Name the real business objects the records describe.
AI HOSPITALITY ALLIANCE · WORKGROUP 4 · IMPLEMENTATION GUIDE
AI-Ready Hospitality Data Framework
How to turn fragmented hotel data into identifiable, traceable, quality-controlled records that AI systems can use and people can explain.
Includes free, reusable tools for each repeatable part of the workflow.
SegmentSMB / independent
Enterprise
Vendor
Enterprise
Vendor
AudienceOwners, general managers, operations and commercial leaders, buyers, data engineers, architects, product teams, and integrators
Operating levelProperty teams define local sources and owners; corporate teams define shared keys, rules, and reusable controls
GUIDE
What this guide does
Build a usable data foundation before adding AI on top of it.
Hospitality teams often use different terms for the same kind of thing. One system may say “room,” another “suite,” and another “penthouse,” while each may attach the term to a sellable category, a physical unit, or a marketing description. The goal is not to force every source system to use identical words. It is to preserve each source term while mapping it to a shared entity, meaning, and relationship so that every system can interpret it consistently.
Hospitality data is usually distributed across property-management, reservation, customer, content, distribution, revenue, service, and other systems. The same organization, property, Room Type, Room, guest, or reservation may have different identifiers and values in each system. A value can be present and still be unsafe to use because its owner, age, source, meaning, or relationship to another record is unclear.
Business data alone is not enough. A usable foundation connects business data such as organizations, properties, and products; customer data such as guests and contact points; operational data such as stays, room status, and service activity; and performance data used to understand outcomes. Entity mapping establishes what each record describes. Context alignment shows how those records relate and which functions depend on them. Together, they reduce repeated reconciliation between teams and help an agent map a user’s intent to the correct internal data and operation.
This guide gives hotel operators and technical implementers one sequence for turning those records into a reusable foundation. It answers three questions: What data must exist? Which relationships must be explicit? What must be checked before a record is used? It then provides the keys, data states, lineage fields, cleaning workflow, quality-rule types, operating measures, and reusable files needed to apply that sequence.
Entity-first sequence
Build uniformity outward from the entities.
Use this sequence before choosing a technical representation or exposing it for downstream use.
Describe them uniformly
Map different source terms to shared meanings while retaining the original values.
Map relationships and functions
Show how the entities connect and what each connection supports.
Map related groups
Bring connected entities together without collapsing distinct identities or roles.
Build outward
Extend the same language, keys, relationships, and controls to additional domains.
Read the numbered steps in order for a new implementation. Start with one property and the Room/Room Type example so the boundary is understandable. Preserve the exact source records, map them into a canonical shape, record evidence and trust state, apply the quality gate, and produce one current foundation record for each stable entity key. Once the result can be traced and reproduced, extend the same controls to the other six data domains.
The outcome is not a single database product or public-web vocabulary. It is a versioned operating method: each material fact can be traced to a source record; each important relationship is explicit; each current value has a state; and each promotion decision can be explained. Semantic layers, knowledge graphs, retrieval systems, structured markup, and AI applications can then consume that foundation without redefining basic identity and quality controls for every use case.
AWS describes a strong data foundation as use-case-led, connected, context-rich, owned, observable, and adaptable. In this guide, that perspective is applied through named owners, freshness expectations, known limitations, feedback routing, and product-health monitoring. It does not replace the hospitality entity model, the five record-level rule types, or the names of the three layers used here.
What does the data mean?
Define the business meaning, entity, field, and original value.
Who owns it?
Name the source owner and the person or team responsible for conflicts.
How fresh must it be?
Set the freshness expectation for the specific use.
What are its limitations?
Record known gaps, coverage limits, and unresolved dependencies.
What depends on it?
Name the decisions, workflows, and AI uses that consume it.
Result
Every entity can be identified. Every material relationship is explicit. Every material fact carries a state and evidence that communicate how far it can be trusted.
01
Start with one property
Prove the method on a bounded, understandable data set.
Begin with one property, one Room Type, one physical Room, the source systems that describe them, and one intended use. Room is useful as the first test because it is more atomic than Guest or Reservation and exposes a common modeling error: a sellable Room Type is not the same entity as an individual physical Room.
Lineage
The evidence record
Lineage documents what happened to any field: which entity it belongs to, where it came from, what evidence was compared, who or what acted, when it happened, and which state resulted.
Room / Room Type
The first subject
Room and Room Type are the bounded entities used to prove that the lineage, identity, relationship, state, and quality controls work together. “Lineage plus Room” means applying the evidence method to this first subject—not treating lineage as part of the Room entity.
- 01Scope
Set the boundary
Name the property, Room Type, Room, source systems, intended use, and owners.
- 02Source register
Inventory the source records
Capture source keys, timestamps, original values, and known overlaps or contradictions.
- 03Conformed records
Map the entities and fields
Separate Property, Room Type, and Room; preserve source values while producing the canonical shape.
- 04Quality evidence
Apply state, lineage, and rules
Compare evidence, classify each material fact, and run the quality gate.
- 05Foundation record
Promote and explain
Create the current foundation output only when the record meets the configured outcome.
CONCEPT
Three data layers
Preserve the source, resolve the meaning, then promote the usable record.
Landed, Conformed, and Foundation keep raw evidence, record-level history, and current usable records separate. Promotion between them is controlled so that cleaning does not erase the source and every downstream use does not have to repeat identity resolution and basic quality work.
Source fidelity
Landed
Source payloads exactly as received, separated by source, with arrival time and a durable reference. Failed records and reruns remain traceable.
Canonical shape
Conformed
One row per record version, shaped by entity. Original values and history remain intact; keys and relationships are resolved where possible.
Current data product
Foundation
One current row per entity key, with resolved relationships, data state, lineage, and a quality-gate result. CONFLICTING and DEPRECATED records remain outside this layer.
How this relates to bronze, silver, and gold:
AWS uses the common medallion terms bronze, silver, and gold. Bronze resembles Landed, and silver resembles Conformed. Gold is usually use-case-specific or aggregated; it is not the same as the Foundation defined here, which is a reusable current record designed to support multiple uses.
What comes next: semantic layers, knowledge graphs, context graphs, retrieval indexes, structured markup, and agent-protocol packaging read from the Foundation. They are downstream outputs, not replacements for the Foundation controls.
02
Define the data model
Begin with seven core hospitality data domains.
These seven domains are the minimum entity set needed to support meaningful hospitality questions across systems. They are not a complete inventory of every record a hotel may manage. Use the larger candidate workbook when a use case requires additional entities, but do not expand the model until each added entity has a purpose, owner, key, relationships, and control fields.
The wider reference inventory contains 58 internal and 40 digital entities. Its crosswalk has 21 distinct mapped digital targets and 24 structural/discovery entries, with five appearing in both lists: 21 + 24 − 5 = 40. The lists describe overlapping roles, not separate catalogues. LocationFeatureSpecification via hasAmenityFeature is a nested feature structure, not an additional catalogue entity. The five ldb: concepts are candidate extensions, not standard vocabulary. Validate them for the intended implementation.
Organization
The business role behind the hotel, such as a brand, management company, ownership group, franchisee, or independent operator. It remains distinct from the physical property.
Property
The operating hotel, its identifiers, its relationship to one or more organizations, and the tenancy boundary for property-level facts.
Space / Room
The sellable Room Type and the individual physical Room, modeled separately and linked with stable identifiers.
Rate / Product
Rate plans and codes, property and Room Type binding, amount and currency, validity dates, policy, refundability, length-of-stay limits, source, state, and lineage.
Guest
The person, modeled independently of the booker, payer, loyalty member, or reservation. A dining, spa, event, or service activity may originate a Guest record even when no stay exists.
Reservation / Stay
The booking, guest, property, Room Type and assigned Room relationships, scheduled and actual dates, status, cancellation, source, state, and lineage.
Activity
Concrete operational records such as service requests, housekeeping tasks, spa appointments, event bookings, and guest communications—not one catch-all activity table.
Common record shape
Give every entity three blocks.
Assigned key, source-scoped keys, property/organization tenancy, and external identifier crosswalks where used.
The business attributes that describe the entity, with original values retained where normalization occurs.
Source of record, data state, lineage reference, schema version, freshness class, timestamps, and quality-gate outcome.
JSONReusable download
Seven-Domain Machine-Readable Schema
- What it is
- A seven-domain JSON Schema bundle: 12 concrete record profiles, two grouping definitions and four shared definitions. SpaceRoom selects RoomType or Room; Activity selects five concrete activity profiles.
- When to use it
- Use it when engineers need a parseable starting point for validation or technology-specific schema generation.
- What you enter or decide
- Select the profiles needed for the use, map local source fields, preserve the original names and values, and decide which optional fields the implementation requires.
- What it produces
- A machine-readable implementation profile covering all seven core domains.
This package contains field contracts, not sample records or an answer key. Validate it against the local technology stack before treating it as a production contract.
Download JSON ↓XLSMReusable download
Candidate Hospitality Entity Inventory
- What it is
- A broader inventory of internal and digital entities, cleanliness controls, graph classifications, Room material, crosswalks, a guest lifecycle example, and 50 candidate relationship edges.
- When to use it
- Use it after the seven-domain foundation is understood, when a specific use requires more detailed entities or relationships.
- What you enter or decide
- Select only the relevant candidates; then validate their names, fields, keys, cardinalities, owners, source-of-record assignments, and storage recommendations.
- What it produces
- A bounded entity-and-relationship scope for a later implementation release.
This is a candidate inventory, not a universal canonical model. External vocabulary and graph classifications must be checked for the intended use.
Download XLSM ↓XLSMReusable download
Expanded Digital Entity Schema Workbook
- What it is
- A detailed reference workbook containing the data-state taxonomy, source-attribution standard, lineage schema, Room and Room Type schema, Organization and Property identifier schema, accessibility and amenity dictionaries, readiness tools, minimum entity set, expanded internal and digital entity inventories, identifier reference, and Schema.org crosswalk.
- When to use it
- Use it after the seven-domain foundation is understood, when a data or architecture team needs the underlying detailed schemas, inventories, examples, crosswalks, and reference proposals in one workbook.
- What you enter or decide
- Select the entities and fields relevant to the implementation; then validate local names, keys, relationships, source-of-record decisions, controlled values, and any external-vocabulary or identifier assumptions before adoption.
- What it produces
- A detailed source reference for defining or extending a hospitality entity model and documenting implementation decisions.
Reference workbook. Its appendices include broader working material, and its external vocabulary, identifier, accessibility, and mapping content must be verified before normative use.
Download XLSM ↓03
Resolve identity and relationships
Use assigned foundation keys and preserve every identifier that helps explain a match.
A hotel, the company that owns it, the company that manages it, and the brand it operates under are different entities. Systems often use different codes for each. The foundation therefore uses stable assigned keys for its own records and stores source-scoped or external identifiers in a crosswalk instead of treating any one external identifier as a universal master key.
One Property may have multiple Organization relationships:
A Property can be associated at the same time with an ownership group, management company, brand or franchisor, franchisee, or independent operating entity. Keep each Organization distinct and record the role it plays in relation to the Property; do not collapse these parties into one company record or assume the brand identifies the owner or operator. If the implementation uses one operating Organization as the primary tenancy link, preserve the other ownership, management, and brand associations as separate explicit relationships.
01Store namespace plus value.
An identifier without its scheme, issuer, or source is ambiguous.
02Keep tenancy with the record.
Organization and Property context travel with every key and fact.
03Prefer deterministic resolution.
Exact source keys and verified identifiers resolve records; name, address, or domain similarity produces a candidate for review.
04Retain unresolved identifiers.
Do not silently drop a value that cannot yet be mapped. Record the ambiguity and its age.
Capture at ingestion
Keep the context that is difficult to reconstruct later.
- source system and source record identifier
- capture time and ingestion time
- capture channel
- original currency, locale, and unit
- original rate or product code
- property and organization identifier on every row
Classify the fields
Do not confuse facts, events, links, calculations, and summaries.
A fact about the entity, such as a Room Type occupancy limit.
A fact captured on an event, such as the rate booked on a reservation.
A reference to another entity, not a copied text value.
A calculated value with an explicit rule; do not store it as an unexplained entity fact.
A summary over records or time, kept separate from the current entity record.
Minimum relationships
Make the links required by common hospitality workflows explicit.
Organization → PropertyProperty → Room TypeRoom Type → RoomProperty → Rate / ProductGuest → Contact PointGuest → ReservationReservation → StayActivity → Reservation or another named parent
Survivorship:
Declare source precedence per attribute, not only per entity. Use the domain-owned or point-of-capture source where that is explicit, define a fallback, retain the losing values in history, and record every merge so it can be reversed. Probabilistic matching may propose a candidate; it must not silently become a resolved identity.
XLSXReusable download
Global Organization and Property Identifier Reference
- What it is
- An informative list of possible organization- and property-level identifier schemes across global and regional contexts, plus a crosswalk structure for storing them.
- When to use it
- Use it when the same business or property appears under different codes across internal, distribution, benchmarking, contract, tax, registry, OTA, domain, or GDS records.
- What you enter or decide
- For each selected identifier, verify its scheme, issuer, jurisdiction, current coverage, format, hierarchy behavior, access method, licensing, source, and verification date.
- What it produces
- A crosswalk that connects source-scoped identifiers to assigned Organization and Property foundation keys.
No listed external identifier—including DUNS, LEI, IATA, OTA, benchmarking, GDS, tax, or registry identifiers—is a universal golden key. Coverage and operational claims require current verification before adoption.
Download XLSX ↓04
Record trust and lineage
Cleaning means resolving a fact—not merely making it present or well formatted.
A value may look clean and still be old, unsupported, attached to the wrong entity, or contradicted by another source. The four data states communicate the evidence condition of the fact. The quality-gate outcome—pass, load with warning, or quarantine—communicates what the processing workflow does with the record. These are separate axes, and lineage supplies the evidence trail for actual state changes.
StateMeaningTreatment
VERIFIEDConfirmed against an authoritative source or independent corroborating evidence, with no unresolved contradiction.May be used as a settled fact within the defined implementation use.
UNVERIFIEDPresent but not yet checked sufficiently.May enter a foundation profile only when it remains clearly labeled and is not presented as settled fact.
CONFLICTINGCredible sources disagree, or a record match is ambiguous.Keep in the conformed layer and route to an accountable owner for resolution.
DEPRECATEDSuperseded by a newer verified value or otherwise no longer current.Keep as history for lineage and rollback; do not publish as the current fact.
Keep state and outcome separate:
A domain or enum failure changes the quality-gate outcome to warning or quarantine according to severity; it does not change data_state by itself. CONFLICTING is reserved for credible source disagreement or an ambiguous record match. A record can therefore be UNVERIFIED and quarantined at the same time.
Source attribution
Apply five rules to every material fact.
- 01
A fact has one declared authoritative source of record at a time.
- 02
Every fact carries both
source_typeand a specificsource_id. - 03
A disagreement is recorded as a conflict rather than silently resolved.
- 04
Evidence points to an independently checkable URL, document, checksum, or record.
- 05
Open-web signals are evidence to compare, not automatic truth.
Minimum lineage entry
Record the field, action, actor, source, evidence, state, and time.
entry_identity_typeentity_idfield_pathactionactor_typeactor_iddata_statesource_typesource_idevidence_referencecompared_toconflict_referenceoccurred_atrecorded_atschema_versionpurposeaccess_classconfidence_methodField lifecycle
guest.phoneA phone number can be captured as UNVERIFIED, become CONFLICTING when a second source supplies a different value, and later become VERIFIED after confirmation. Each transition is a new lineage event; the original values and evidence remain available.
Field lifecycle: domain failure (does not change state)
room_type.operational_statusA Room Type’s operational_status is captured from the PMS as CLOSED_FOR_RENOVATION, outside the approved enum of ACTIVE, INACTIVE, UNDER_RENOVATION, and DECOMMISSIONED. The domain rule fails and the record is quarantined with the reason “operational_status not in controlled vocabulary.” The field remains UNVERIFIED. No lineage entry is created because the state did not change; the quarantine is logged as a quality-gate event. After correction to UNDER_RENOVATION and successful validation, the normal UNVERIFIED-to-VERIFIED transition creates the lineage entry.
JSONReusable download
Lineage, Room, and Room Type Field Contract
- What it is
- A machine-readable field contract for the lineage entry and the two pilot entities, including required fields, descriptions, and controlled values.
- When to use it
- Use it when implementing validators, mappings, interfaces, or schema documentation for the first pilot.
- What you enter or decide
- Map local source fields to the contract and decide how assigned identifiers, source references, evidence references, and state transitions will be generated.
- What it produces
- A technology-neutral implementation contract for lineage, Room Type, and Room fields.
CSVReusable download
Lineage, Room, and Room Type Data Dictionary
- What it is
- A flat, filterable version of the same field definitions, required flags, descriptions, and controlled values.
- When to use it
- Use it for mapping workshops, data-catalog import, field review, or requirements exchange where a spreadsheet-like file is easier than JSON.
- What you enter or decide
- Add local source fields, mappings, owners, and implementation decisions in the receiving tool; preserve this source dictionary as the reference.
- What it produces
- A reviewed field-mapping list for the pilot.
JSONReusable download
Room Type Conformance Fixtures
- What it is
- Four behavioral Room Type scenarios with partial inputs and expected data state, quality-gate outcome, lineage behavior, and quality-gate logging: a clean pass, a domain failure, a genuine source conflict, and a plausibility warning.
- When to use it
- Use it after implementing the Room Type contract to confirm PASS, WARNING, and QUARANTINE outcomes and to verify that invalid values, plausibility flags, and source disagreements affect state and processing differently.
- What you enter or decide
- Combine each scenario with complete baseline RoomType and Property records, source observations and your verification/mapping steps; compare the state, gate outcome and logging with the expected result. Do not submit these partial inputs directly as complete schema-valid records.
- What it produces
- A comparison of the expected behavioral outcomes. A complete baseline dataset and executable test runner have not been supplied.
05
Clean and promote
Move every record through the same explainable sequence.
The workflow combines source preservation, identity, state, lineage, quality rules, resolution, and promotion. It applies to a batch pipeline, an API ingestion path, or a manual reconciliation process as long as the evidence and outcomes are retained.
- 01
Identify and place
Determine the entity type, organization/property tenancy, source system, source record identifier, capture time, and ingestion time. A record that cannot be placed cannot be reconciled safely.
- 02
Ingest and land
Retain the source payload exactly as received with arrival time and a durable source reference. Keep failed records and reruns traceable.
- 03
Normalize and conform
Convert values to the canonical entity shape while retaining original codes, units, locale, currency, source history, and one row per record version.
- 04
Validate
Apply key-presence, referential, domain, temporal, and plausibility rules. Also check source/evidence fields and property tenancy.
- 05
Compare
Compare authoritative and corroborating sources using declared source precedence. Record the comparison instead of silently selecting a value.
- 06
Classify
Assign VERIFIED, UNVERIFIED, CONFLICTING, or DEPRECATED from the evidence condition. Create a lineage entry when the state changes; record a rule failure that leaves state unchanged in the quality-gate log instead.
- 07
Resolve
Route ambiguous matches and conflicting facts to the named owner. Retain competing values and the rule or evidence used to resolve them.
- 08
Approve and promote
Apply the configured outcome: pass, load with warning, or quarantine. Promotion creates the current foundation record without deleting conformed history.
- 09
Publish
Expose the versioned foundation view for the defined implementation use. Never expose a conflict as settled truth.
- 10
Monitor
Measure freshness, warnings, quarantine volume and age, unresolved identifiers, source changes, and recurring conflicts on a declared cadence.
- 11
Deprecate
Mark a superseded fact DEPRECATED and preserve its lineage. Handle any separately applicable retention or deletion decision outside this data-cleaning workflow.
Outcome 01Pass
The record meets the configured requirements and can be promoted.
Outcome 02Load with warning
The record remains usable for the defined purpose while the issue is recorded and counted.
Outcome 03Quarantine
The record is held back with a named owner, review cadence, reason, and age.
Promotion must be reproducible:
There is one current row per entity key; rerunning the same input is idempotent; the latest eligible record wins; and any tie is resolved by a declared rule. The conformed history remains available.
06
Run the Room pilot
Keep the sellable Room Type separate from the physical Room.
A Room Type describes what can be sold; a Room identifies the physical unit that may later be assigned. Mixing them produces duplicate inventory, incorrect accessibility or amenity claims, and unreliable downstream answers. The pilot demonstrates the distinction and applies shared lineage and quality controls to both entities.
Sellable category
Room Type
room_type_id— stable keyproperty_id— property bindingname— guest-facing canonical namecategory— required controlled room-type categoryoccupancy_max— maximum adult occupancyaccessibility_features— controlled accessibility references such as roll-in shower, hearing accessibility, visual alarm, grab bars, and lowered fixturesverification_method— required when accessibility features are presentamenities— controlled amenity references such as bed configuration, view, balcony, kitchenette, minibar, soaking tub, and fireplacemarketing_content— localized descriptions, photos, and language variantsoperational_status— current sellability statussource_of_record— authoritative source referencedata_state— current evidence conditionlineage_entries— material field-level change references
Physical unit
Room
room_id— stable keyproperty_id— property bindingroom_type_id— required relationshipunit_label— internal unit labelfloor_or_zone— floor or zoneoperational_status— physical operational statusaccessibility_features— unit-level accessibility exceptions or additionsverification_method— required when accessibility features are presentsource_of_record— authoritative source referencedata_state— current evidence conditionlineage_entries— material field-level change references
Accessibility facts
Use controlled claims and record how each claim was verified.
The Room and Room Type accessibility_features field references a shared dictionary rather than free text. The current enum contains WHEELCHAIR_ACCESSIBLE_ROOM, WHEELCHAIR_ACCESSIBLE_BATH, ROLL_IN_SHOWER, GRAB_BARS, LOWERED_FIXTURES, HEARING_ACCESSIBLE, and VISUAL_ALARM. Keep specific claims separate—for example, do not collapse ROLL_IN_SHOWER into the broader WHEELCHAIR_ACCESSIBLE_BATH value.
When accessibility features are present, record verification_method as SELF_REPORTED, THIRD_PARTY_AUDITED, or ADA_SURVEY_ON_FILE. The dictionary also flags SERVICE_ANIMAL_ACCOMMODATING as a proposed addition, not an approved current enum value, and distinguishes it from a general pet-friendly policy. The cited compliance references are descriptive prompts; verify the applicable local requirements before normative use.
Digital accessibility attributes
Describe the feature, its relevance and its evidence.
The digital AccessibilityFeature reference adds four attributes. hasCategory classifies a feature as MOBILITY, HEARING, VISION, COGNITIVE, POLICY or GOVERNANCE. VISION and COGNITIVE extend category coverage; they do not invent new approved Room/RoomType feature values. hasBookingCriticality records BLOCKING, STRONG_PREFERENCE or NICE_TO_HAVE, so booking logic can distinguish a necessary feature from a preference.
hasDimensions holds quantitative evidence for the claim. Supplied measurements are examples, not legal thresholds. hasNamespacedId identifies the feature in a named namespace so systems can link the same concept instead of deduplicating by label. The namespace example is illustrative, not a declaration of an approved standard namespace.
Use these attributes in the digital feature reference, alongside the Room/RoomType accessibility values and their conditional verification_method. They are not four additional mandatory Room/RoomType fields. The Expanded Digital Entity Schema ↓, Candidate Entity Inventory ↓ and Master Workbook ↓ contain the attribute definitions and examples.
!
Entity boundary
Do not copy a higher-level statement into a lower-level fact.
A Property amenity is not automatically a Room amenity. Room Type marketing content is not an individual Room fact. An Organization identifier does not automatically identify a Property. Preserve the entity that owns the fact and the evidence behind it.
Public vocabulary crosswalk:
Keep the internal foundation model separate from Schema.org. A Room Type may map descriptively to HotelRoom; an individual physical Room has no equivalent defined in this crosswalk. Physical accessibility features are represented through amenity-feature structures, and every Property should use the LodgingBusiness subtype that actually matches it rather than mapping every property to Hotel.
What to extend next
After the Room pilot, extend the same controls to Organization and Property identity and location, then to Rate/Product records needed to support availability, rate, and the canonical direct-booking link. Use the intended AI question to set the order of later domains.
XLSXReusable download
Room, Room Type, and Lineage Pilot Workbook
- What it is
- A focused implementation workbook containing the four states, source-attribution rules, lineage schema, Room and Room Type schemas, accessibility and amenity dictionaries, the descriptive Schema.org crosswalk, and the record-level readiness checklist.
- When to use it
- Use it to run the first Room/Room Type mapping and to review how state and lineage apply to concrete hospitality entities.
- What you enter or decide
- Map local source fields and values; assign stable keys and relationships; record source, evidence, state, rule results, and implementation decisions.
- What it produces
- A documented Room/Room Type mapping, lineage design, and record-level quality review.
The accessibility and Schema.org tabs are descriptive references. Validate applicable accessibility requirements and current Schema.org definitions before using them as normative requirements.
Download XLSX ↓EXAMPLE
Worked example
Reconciling an externally discovered property fact.
During the Room pilot, an external search can reveal a property-level fact that affects the surrounding inventory context—for example, a stated room count. This does not make the claim verified. The example below shows how discovery, entity mapping, comparison, validation, and lineage fit together.
01
Discover and preserve the evidence
The open-web view lists eight discovered signals for the Georgian Court Hotel. Preserve the claim, source URL or reference, time of discovery, and search context. A search result is evidence to compare—not automatically the source of truth.
02
Map, compare, classify, and record lineage
The mapping view places schema:numberOfRooms = 180 on the Property record, defines the validation check, records the evidence reference, and shows the downstream usefulness of a resolved fact. If authoritative and corroborating sources agree, the fact may become VERIFIED. If credible sources disagree, it becomes CONFLICTING until the named owner resolves it.
Reproducibility limit:
These screenshots are explanatory illustrations. The underlying structured input records, comparison results, and expected output were not supplied, so this example is not a conformance test fixture. If those records become available, the same sequence can be packaged as a reusable pilot-results test.
07
Operate quality controls
Treat quality as versioned rules plus an owned operating process.
A quality rule is not only a written expectation. It has a stable identifier, the entity and target fields, one of five core rule types, a declarative pass expression, severity, the action on failure, a version, and an active status. A failed rule creates a quality-gate log entry. It creates a lineage entry only when the field’s data state changes. The operating process also needs an owner, a warning and quarantine path, a review cadence, and measurements that show whether the data product remains healthy.
Key presence
The identifiers needed to place the record exist.
Property identifier, entity identifier, and source identifier are present.Usually quarantineReferential
Every reference resolves to an existing parent in the same tenancy.
The reservation property exists, and the Room Type belongs to that property.Usually quarantineDomain
Controlled vocabularies are respected.
Operational status is one of the permitted values.Quarantine or warningTemporal
Dates and events are internally coherent.
Arrival is not after departure; an attributed activity falls within the relevant stay.Usually quarantinePlausibility
Values fall within a credible range rather than being merely possible.
Nights, occupancy, and rate are within the expected bounds defined for the use.Usually warningRule configuration
Keep each rule inspectable and versioned.
rule_identitytarget_fieldsrule_typepass_expressionseverityaction_on_failversionactiveRecord-level rules
Decide what happens to each record.
The five rule types determine whether a record passes, loads with a warning, or is quarantined.
Product health
Monitor the data over time.
Track completeness, accuracy, timeliness, and consistency, along with missing-value spikes, anomalies, source drift, and recurring conflicts.
Ownership
Make issues actionable.
Assign the owner, freshness expectation, severity, response path, quarantine review cadence, known limitation, and feedback route.
Conformance measures
Measure whether the controls are operating.
Key completenessIdentity-resolution rateAge of unresolved candidatesOrphan rateCross-tenancy leakageQuarantine rate and ageWarning densitySurvivorship coverageAttribute-classification coverageFreshnessControl-block completeness
Operational thresholds:
Define freshness limits, warning treatment, quarantine age, review cadence, and promotion gates for the use case and operating segment. The material does not support universal numeric thresholds. The explicit exception is cross-tenancy leakage, where the acceptable target is zero.
JSONReusable download
Room Type Quality Rules
- What it is
- A machine-readable Room Type rule set with eight rules covering key presence, referential integrity, domain values, temporal order, and plausibility. Each rule records its severity, version, pass condition, and action on failure.
- When to use it
- Use it when configuring or implementing the Room Type validation gate, together with the conformance fixtures that show the expected results for specific inputs.
- What you enter or decide
- Load or translate the rule identifiers, target fields, pass conditions, severity, and on-failure behavior into the validation engine; then compare results with the supplied fixtures.
- What it produces
- A versioned Room Type quality-gate configuration in which severity determines WARNING or QUARANTINE and the quality-gate outcome remains separate from data state.
XLSXReusable download
Readiness and Data Quality Workbook
- What it is
- A record-level readiness checklist plus 24 operational evidence-based questions and a separate out-of-scope consent handoff for an operator, implementation team, or prospective technology provider.
- When to use it
- Use the checklist during the quality gate and the self-assessment before expanding an implementation or buying a solution.
- What you enter or decide
- Record each rule result and action; answer each readiness question Yes or No and attach evidence. Do not replace evidence with a composite score.
- What it produces
- A record-level issue log and an evidence-backed list of data-foundation gaps.
XLSXReusable download
How to Get AI Data Ready — Master Workbook
- What it is
- A single consolidated workbook combining the guide’s core schemas and reusable tools — merged, deduplicated, and organized into one file, with a front-matter guide tab, the full entity schemas, controlled vocabularies, fillable pilot and readiness templates, and the complete reference inventories.
- When to use it
- Use it when a team wants one file to work from instead of managing multiple separate downloads, or as a single leave-behind reference for someone who needs the full picture without piecing it together themselves.
- What you enter or decide
- Nothing to configure to start — read the Guide tab for the recommended reading order, then use the fillable (highlighted) cells in the Pilot Template, AI-Readiness Checklist, and 25-Question Self-Assessment tabs to record your own data.
- What it produces
- A single-file reference and working tool covering all seven core domains, the four data states, the eleven-step cleaning workflow, and every schema and controlled vocabulary in this guide.
This is a convenience format, not a replacement for the standalone downloads — if you only need one domain, the individual file will be lighter to work with.
Download XLSX ↓08
Implement or procure
Require the same evidence whether the capability is built or bought.
An SMB or independent property may begin with a smaller source set and combine responsibilities. An enterprise may operate shared rules, identifiers, and conformance reporting centrally while property teams remain responsible for local source meaning and issue resolution. The scale differs; the evidence requirements do not.
Property / SMB path
Begin with the highest-value boundary.
- Name one accountable owner
- Choose one property and one use
- Inventory only the systems in that boundary
- Use the Room pilot workbook and checklist
- Record conflicts and operating limits before expansion
Corporate / enterprise path
Separate shared controls from local decisions.
- Define common entity keys and contracts
- Operate versioned rules and measures centrally
- Preserve property tenancy in every record
- Assign domain and property-level issue owners
- Publish reusable foundation outputs by use
Technology provider / integrator
Make the implementation inspectable.
- Expose source mappings and original values
- Show identity and relationship rules
- Retain state transitions and lineage
- Keep warnings and held records diagnosable
- Version schemas, rules, and outputs
Evidence expected from every path
Entity list and ownersSource and key mapRelationship rulesState and lineageRule configurationWarnings and quarantineConformance measuresVersioned foundation output
Maturity path
Advance only when the evidence for the level exists.
- 0Fragmented
Records are source-bound and identities are not controlled.
- 1Identified
Stable entity keys and source keys are defined.
- 2Related
Required relationships and identity-resolution rules are explicit.
- 3Governed
State, lineage, survivorship, rules, warnings, and quarantine are operated.
- 4Foundation ready
A current, reproducible foundation output is available for the defined use.
CHECK
Assess readiness
Use 24 operational questions to locate the gaps before expanding.
The self-assessment groups 24 operational yes/no questions around the same three requirements as the foundation: nine questions about the data and identifiers that must exist, eight about relationships and resolution rules, and seven about the quality gate and repeatable operation. Record evidence for each answer; the workbook does not create an unsupported aggregate score.
What data must exist?
Entities and owners, controlled primary keys, tenancy binding, source-system keys, external identifiers, source references, separate capture and ingestion time, original values, and one-to-many contact points.
What relationships must be clear?
Organization/Property separation, Room Type/Room separation, attribute classification, derived-value rules, explicit identity rules, held ambiguous matches, reversible merges, and source precedence.
What must be checked?
Versioned rule configuration, critical failures held back, diagnosable quarantine, named review ownership, oldest unresolved age, idempotent reprocessing, and protection from older records overwriting newer ones.
The consent-by-channel-and-type question is a separate governance handoff, not one of the 24 operational assessment requirements. Privacy and permitted-use decisions remain outside scope. Use Yes/No answers with evidence, an owner and follow-up; do not calculate a composite score.
Use the Readiness and Data Quality Workbook ↓ to answer the questions and record evidence.
Recommended implementation check
Select a small export from one property and one source system. Map its identifiers and fields, run the rules, compare expected and actual outcomes, review warnings and quarantined records, and record what changed. Repeat with a second source only after the first record can be explained from the source payload to the foundation output.
SCOPE
Scope and limitations
Know what this guide does not decide for you.
The guide supplies a data-foundation method and reusable implementation materials. It does not replace organization-specific decisions or the authoritative sources that govern a jurisdiction, vendor, property type, or technical environment.
Privacy and permitted use
Privacy and permitted-use decisions are outside this guide. Apply the organization’s governance, contractual, and legal processes separately.
Numeric thresholds
Define operational thresholds for the actual use and segment. This guide names what to measure but does not prescribe unsupported universal numbers.
External identifiers
The identifier workbook is informative. Verify coverage, format, issuer, hierarchy, access, licensing, and suitability before adoption.
Accessibility and public vocabulary
The accessibility and Schema.org mappings are descriptive references. Check current authoritative requirements and definitions before normative use.
Conformance fixtures
The four supplied Room Type fixtures cover a clean PASS, a plausibility WARNING with state unchanged, a domain-failure QUARANTINE with state unchanged, and a genuine source conflict that becomes CONFLICTING and is QUARANTINED. These are behavioral scenarios, not complete standalone records. A runnable end-to-end package still needs complete baseline records, referenced Property data, source-observation mapping and a test runner. These have not been supplied. The eight rule conditions are specifications to implement, not an included validation engine.
Technology choice
The method does not require a particular cloud, PMS, database, graph store, integration product, or AI model.
NOTE
Regulatory note
Operational guidance, not legal advice.
This standard is operational guidance, not legal advice. The European Commission states that Article 50 transparency obligations apply from August 2, 2026, and current AI-literacy obligations and enforcement timelines should be checked against official guidance for each organization. Lineage can support evidence, but it does not by itself establish legal compliance. See the European Commission Article 50 guidelines and AI literacy Q&A.
PEOPLE
Contributors
People whose substantive inputs shaped this guide.
The customer-readiness constraint that many hospitality organizations need a usable foundational data layer before advanced schemas or machine-discovery outcomes, keeping the framework practical for teams starting from that baseline.
The expanded hospitality entity inventory; internal-to-public vocabulary crosswalk; separate accessibility and amenity dictionaries; connection of business, customer, operational, and performance data; and the requirement for data that machines can interpret consistently.
The lineage-first, atomic-first sequence; Room and Room Type as the first bounded pilot; and the requirement for fully defined enums rather than field names alone.
The entity-first five-step introduction and uniform-language analogy; data-state taxonomy and criteria; source-attribution and evidence-lineage standards; the distinction between data state and quality-gate outcome; four Room Type conformance fixtures and the Room Type quality-rule configuration; the Georgian Court forensic-audit example; and prioritization of the facts with the greatest AI citation exposure.
Workgroup direction and synthesis; the shared cleaning-blueprint and dictionary objective; the operator-facing implementation sequence; and the guide and reusable-materials publication structure.
The three-layer data-foundation structure; seven-entity minimum; lineage and capture-now fields; five quality-rule types; maturity path; and 25-question readiness assessment.
The end-to-end framing from data definition through database implementation and discovery; the connection between user intent and internal operations; the accessibility dictionary and verification methods; the digital feature attributes hasCategory, hasBookingCriticality, hasDimensions and hasNamespacedId, including vision and cognitive categories; and the proposed service-animal accommodation gap.
Organization and Property identity fields; the global business-identifier reference; the DUNS-first enrichment sequence; and regional identifier considerations for cross-system entity resolution.
SOURCES
External resources
External sources used in this guide.
- AWS — Build strong data foundations for agentic analytics and intelligent agentsIndustry and vendor perspective used for the use-case-led context, ownership, freshness, limitations, feedback, observability, data-quality dimensions, and medallion-layer comparison. Accessed August 24, 2026.Open reference ↗
- European Commission — Article 50 transparency guidelinesOfficial guidance used in the regulatory note. Accessed August 29, 2026.Open reference ↗
- European Commission — AI literacy Q&AOfficial guidance used in the regulatory note. Accessed August 29, 2026.Open reference ↗
- W3C PROV-O: The PROV OntologyOfficial standard used as background for interoperable provenance concepts. This guide does not claim PROV-O conformance. Accessed August 29, 2026.Open reference ↗
- ISO 3166 country codesOfficial reference for country and jurisdiction normalization. Accessed August 29, 2026.Open reference ↗
- Schema.org LodgingBusiness, Hotel, HotelRoom, and LocationFeatureSpecificationPublic vocabulary used by the descriptive mapping in the Room pilot workbook. It is kept separate from the internal foundation model. Accessed August 29, 2026.LodgingBusiness ↗Hotel ↗HotelRoom ↗LocationFeatureSpecification ↗