Business Capability Model

Status: FROZEN — Foundation v1.0

The platform avoids making industries architectural silos. Verticals compose reusable capabilities.

Business Unit composition rule

Every Business Unit has:

exactly 1 Primary Vertical Preset
+ 0..N Additional Compatible Capabilities

Additional capabilities are not merely UI toggles. Enabling one must pass:

1. compatibility validation;
2. tenant/plan entitlement validation; and
3. billing/commercial validation.

A capability may therefore be technically compatible but unavailable until the tenant purchases/activates the corresponding module or contract entitlement.

Vertical Definitions and capability compatibility rules are platform-governed. Tenants configure approved capabilities and custom fields; they do not define arbitrary executable vertical logic.

Core capability families

Family	Examples
Accommodation	Properties, rooms/units, occupancy, nightly inventory, rate plans, check-in/out
Appointment	Services, staff, rooms, duration, time slots, appointment capacity
Rental	Assets, pickup/return, duration, quantity, deposits, insurance/add-ons
Resource Reservation	Tables, berths, cabanas, venues, tee slots, treatment rooms
Admission/Ticketing	Ticket types, sessions, capacity, passes, QR/admission lifecycle
Experiences	Tours, activities, guides, participant capacity, itineraries, meeting points
Group Excursions	Group leaders, participant classes, transport, meals, activities, documents, group pricing
Events	Venue, packages, attendees, holds, deposits, proposals, vendors, milestones
Food & Beverage	Restaurant/table reservations, menus, seating areas, special occasions
Membership	Tiers, validity, benefits, allowances, renewals, guest rights
Quotes	Requirements, versions, approval, deposits, conversion to booking/order
Scheduling	Resource calendars, conflicts, closures, capacity, overrides
Pricing	Fixed/hour/day/night/person/unit/package/tiered/quote plus modifiers
Commerce	Cart/order/booking/coupon/cancellation/refund orchestration; payment execution remains a Finance/Integration responsibility

Transaction modes

• INSTANT_BOOK — availability + price can be committed immediately.
• REQUEST_TO_BOOK — tenant must accept before confirmation/payment step defined by workflow.
• ENQUIRY_ONLY — lead/conversation without reservation commitment.
• QUOTE_REQUIRED — structured requirements and a versioned proposal precede commitment.
• EXTERNAL_BOOKING — platform presents the offering but routes conversion externally.

Availability model catalog

• ALWAYS_AVAILABLE
• DATE_RANGE
• NIGHTLY_INVENTORY
• TIME_SLOT
• SESSION_CAPACITY
• RESOURCE_SCHEDULE
• EVENT_DATE
• QUANTITY_PER_PERIOD

Pricing model catalog

• FIXED
• PER_HOUR
• PER_DAY
• PER_NIGHT
• PER_PERSON
• PER_ADULT_CHILD_INFANT
• PER_UNIT
• PER_ROOM
• PER_SLOT
• PACKAGE
• TIERED
• QUOTE

Modifiers may include season, date, weekday/weekend, quantity, occupancy, duration, membership, customer type, early-booking, last-minute, promotion and add-ons.

Cross-business-unit commerce

The domain model must permit one tenant-scoped Order to contain lines from multiple Business Units.

Example:

Order
├── Hotel room          -> Hotel BU
├── Airport transfer    -> Vehicle Rental BU
├── Spa treatment       -> Spa BU
└── Yacht charter       -> Yacht Charter BU

The first implementation may expose simpler single-Business-Unit checkout flows. That is an implementation staging decision, not a reason to design Order as single-Business-Unit-only.

Orders never cross Tenant boundaries.

Extensibility rule

Core transactions remain strongly typed. Vertical-specific attributes are schema-controlled and versioned. Custom fields are bounded by supported field types and cannot create executable code.