Moxy NYC Times Square
Lifestyle hotel
KHDS Synthesis Build 03
Interval House
What happens when the guest's journey changes but the hospitality relationship is still active?
Interval House is a fictional 24-hour transit hospitality institution in Nairobi developed from KHDS Cases #31-40. It explores how journey state, entitlement, capacity, access and recovery can operate as separate but connected parts of one hospitality system.
A valid booking does not automatically mean a service can still be fulfilled in the guest's current state.
01 / Research
The research
Ten institutions tested hospitality across increasingly complex guest states.
Cases #31-40 moved beyond a single property format and examined hotels, lounges, transit hospitality, resorts, retreats, luxury rail, stadium hospitality and airport systems.
The goal was not to copy those institutions. It was to test which hospitality mechanisms survive when the guest relationship crosses different access states, capacities, operators and journey dependencies.
Plaza Premium Lounge Toronto Pearson
Airport lounge
YOTELAIR Istanbul Airport
Airside transit hotel
The Venetian Resort Las Vegas
Integrated resort
Great Wolf Lodge Niagara Falls
Waterpark resort
Disney's Grand Floridian Resort & Spa
Theme-park resort
Esalen Institute
Retreat
Venice Simplon-Orient-Express
Luxury rail
Tottenham Hotspur Stadium
Stadium hospitality
Singapore Changi Airport
Airport hospitality
02 / Findings
What the research taught us
One journey does not mean one relationship, one entitlement or one operating owner.
The strongest recurring pressure was not simply product variety. It was the separation between what a person booked, what they are entitled to, what is currently accessible and what can actually be fulfilled.
One guest can hold several relationships
A person can simultaneously be a room guest, diner, lounge user, transfer passenger or event attendee. Those relationships can have different access, capacity and lifecycle rules.
Entitlement is not the same as fulfilment
A valid reservation, pass or payment may establish entitlement while live capacity, timing, access or another dependency still prevents the service from being fulfilled.
Journey state and service state are different
An external travel change should not automatically invalidate every service inside the hospitality institution. Each relationship needs to be recalculated independently.
One journey can cross multiple owners
Flights, transfers, terminals, hospitality services and external partners can all affect one guest journey without being controlled by one operator.
Departure is not always closure
A guest may physically leave while baggage, billing, recovery, communication or another responsibility remains unresolved.
Reservation valid ≠ journey compatible ≠ service fulfilled.
03 / Product
What we built
A hospitality system that understands what state the guest is in when they try to use what they booked.
My Interval
A state-aware guest dashboard separates journey state from service state and recalculates affected services when something changes.
Business problem
Traditional booking systems often know what was purchased but not whether the guest's current journey state still makes that service usable.
Independent entitlement states
Each service keeps its own eligibility, capacity, time window and access state.
Business problem
Being a hotel guest does not automatically mean access to every lounge, event, wellness service, workspace or restaurant.
Live capacity architecture
Rooms, lounge, showers, workspaces, restaurant, transfers and wellness operate as separate capacity pools.
Business problem
A property can be sold out in one service while still having useful capacity elsewhere.
Recovery Centre
Every unresolved problem receives an owner, current status, next action and human escalation path.
Business problem
Hospitality failures often disappear into vague escalation language such as 'we forwarded your issue.'
Operator recovery queue
The operator view surfaces live demand and ranks recovery cases by consequence, urgency and responsibility.
Business problem
Operational teams can prioritize issues by arrival time rather than actual guest consequence.
04 / Recovery
Operating principle
Recovery is not an exception.
It is part of the product.
When Amara Njeri's fictional inbound flight is delayed by 5 hours and 10 minutes, Interval House does not mark everything as failed. Her room window shortens, lunch requires recovery, the transfer remains compatible and lounge eligibility remains valid.
The system changes only what the disruption actually affects.
05 / Translation
Research to operating system
Every feature exists because a specific failure had to be solved.
Research problemInterval responseReal-property implementation
External journey changesJourney-state recalculationState-aware guest profile and service dependency rules
Valid booking but blocked serviceEntitlement / fulfilment separationIndependent eligibility, access and capacity states
Several active guest relationshipsMy Interval identityGuest, relationship and booking stored as separate objects
Cross-owner service failureNamed recovery ownershipRecovery case, owner, status, next action and deadline
Fragmented operating visibilityOperator recovery dashboardShared operational view across services and handoffs
06 / Commercial system
Why the architecture matters
Preserve. Convert. Serve. Retain.
Better hospitality architecture is not valuable because it is technically sophisticated. It matters when it protects revenue, makes capacity usable and prevents recoverable guest relationships from being lost.
Protect value when plans change.
A disruption does not automatically destroy the entire booking relationship. Usable services can remain active while affected ones are recovered.
Expose capacity that would otherwise remain invisible.
Day rooms, lounge, workspaces, wellness and dining can create useful revenue even when overnight inventory is constrained.
Make responsibility visible.
Named ownership reduces dead-end handoffs and gives staff and guests a clearer understanding of what happens next.
Keep the relationship open until the problem is actually closed.
Post-departure recovery, unresolved dependencies and future travel can remain part of the guest relationship instead of being lost at checkout.
07 / Real property
What Kodawa Labs could implement
A connected hospitality layer around the institution, not another disconnected dashboard.
A real deployment would begin with the property's actual services, capacity rules, technology stack, partner dependencies and recovery responsibilities.
Guest experience
- Intent-first discovery
- Stay and day-room booking
- My Interval dashboard
- Live entitlement visibility
- Recovery Centre
Operations
- Live capacity dashboard
- Recovery ownership
- Consequence-based queue
- Cross-service handoff visibility
- Duty-manager escalation
Data architecture
- Guest
- Relationship
- Booking
- Entitlement
- Journey state
- Service state
- Recovery case
Potential integrations
- GuestOps AI
- ReserveAI for suitable services
- Transfer partners
- PMS / CRM
- Payments and analytics
The goal is not one giant booking object. It is a connected system that preserves the boundaries between guest, relationship, entitlement, capacity, journey and recovery.
08 / Evidence boundary
What Interval House demonstrates
Research can shape architecture without pretending to validate it.
Interval House is a fictional KHDS Track C research synthesis prototype representing Cases #31-40.
It demonstrates:
- translation of research into product architecture;
- journey-state and service-state separation;
- entitlement and capacity modelling;
- named service-recovery ownership;
- guest and operator interaction design.
It is not presented as:
- a live hotel, airport or transit operator;
- a deployed PMS or reservation system;
- a new KHDS validation case;
- proof of representative operational outcomes;
- proof of a specific commercial ROI.
Track C implementation does not independently promote, validate or change confidence for any KHDS research pattern.
Kodawa Labs
Research is useful when it changes what the system understands.
Interval House asks hospitality software to understand more than the transaction. It has to understand the guest's relationship, entitlement, journey state, available capacity and who owns the next action when something fails.
A hospitality system should understand not only what someone booked, but what state they are in when they try to use it.