DOMAIN-MAP-02 · Ticketing

MTK for Ticketing

Ticketing platforms issue admission rights, enforce time and seat constraints, scan at the gate, support transfer, and settle with venues. MTK maps cleanly here: the booking or wallet is a container, the ticket or admission right is the entitlement, and check-in or admission is the domain translation of the consume primitive.

From festival wristbands to reserved seating to multi-entry passes, the underlying pattern is the same: an organiser issues a right, a holder presents it at the point of entry, rules determine validity, and a verified scan changes the entitlement's state. MTK tracks this as a protocol-governed event, not merely a database flag.

Primitive Mapping

How ticketing concepts map to MTK

The protocol verb is always consume (PSL-002) — check in and admit are domain translations of it.

MTK Primitive	Ticketing Equivalent
Issuer	Event Organiser / Venue / Ticketing Platform
Holder	Ticket Holder / Purchaser
Beneficiary	Attendee
Container	Booking / Wallet
Entitlement	Ticket / Admission Right
Constraint	Event Time / Seat / Zone / Entry Rules
Verification	Barcode / QR / Identity Check
Authorisation	Gate Scan Approval / Admission Decision
Consume / Domain Action	Check In / Admit
Mutation	Ticket Marked Used / State Transition to CONSUMED
Delegation	Ticket Transfer
Settlement	Venue Settlement / Organiser Payout
Reconciliation	Box Office / Platform Reconciliation
Revocation / Suspension	Cancel Ticket / Deny Boarding / Suspend Entry

Protocol Flow

How it works

A canonical ticket admission flow, expressed in protocol-safe language.

01 An event organiser (issuer) creates a booking or wallet (container) and issues ticket entitlements — each representing a discrete admission right for a specific event, time window, and seat or zone.

02 The attendee presents the ticket at the gate. MTK confirms the entitlement's lifecycle_state_canonical is ACTIVE, not CONSUMED, REVOKED, or expired.

03 MTK evaluates constraints: event timing, seat allocation, zone eligibility, and identity checks if required. The gate scan produces a verification credential and an authorisation decision.

04 If authorised, the ticket is consumed (consume primitive). The entitlement transitions to CONSUMED state. Re-entry attempts will fail — the authoritative record is clear.

05 Venue settlement resolves the organiser payout. Reconciliation aligns box office scan counts against platform-issued ticket records.

Protocol Safety

Booking vs ticket: container vs entitlement

In ticketing, the booking confirmation and the ticket are often presented together — but MTK treats them as structurally distinct.

Container vs Entitlement — Ticketing

A booking or wallet is a container. It may group multiple tickets, display order details, and present event information. It is not authoritative protocol truth.

A ticket or admission right is the entitlement. Each ticket is a discrete, protocol-tracked right with its own constraints, lifecycle state, and evaluation record. A booking presenting "3 tickets" does not guarantee any individual ticket is valid, unexpired, or unconsumed — each must be evaluated independently.

Ticket transfer is a delegation pattern: the original holder delegates the admission right to a new beneficiary. The entitlement's protocol identity is preserved; only the authorised actor changes.

Domain Considerations

Ticketing-specific patterns

Time-Bound Admission

Tickets are valid only within a defined time window. MTK's temporal constraint evaluation checks the event date and time against the entitlement's validity window. A ticket presented after event end is not valid — the constraint evaluation fails and no authorisation is issued. Time-based constraints are evaluated at the entitlement level, not inferred from the booking presentation.

Venue and Seat Constraints

Reserved seating, zone restrictions, and entry gate routing are constraints on the entitlement. A ticket for Section A, Row 5, Seat 12 carries those coordinates as constraint data. The evaluation engine checks whether the presented ticket matches the gate's admissible zone, preventing cross-zone entry without a separate entitlement.

Ticket Transfer

Many ticketing platforms allow the original purchaser to transfer a ticket to another person. In MTK, this is a delegation grant: the holder delegates the consumption right to a new beneficiary. The original entitlement record is unchanged. Transfer restrictions (non-transferable events, resale limits) are enforced as constraints on the delegation operation.

Cancel and Revocation

Event cancellations and individual ticket cancellations require immediate entitlement revocation. MTK's revocation primitive transitions the entitlement to REVOKED state, preventing any further consumption attempt. Suspension (temporary hold) is available for cases like disputed fraud before a final decision is made — the entitlement is blocked but not yet permanently cancelled.

Venue Settlement

Ticket sales generate settlement obligations to venues, promoters, and platforms. MTK's settlement primitive records the payout event per consumed ticket. Reconciliation aligns box office scan counts, barcode validation logs, and platform-issued ticket records — ensuring the financial settlement matches the protocol-tracked consumption events.

Illustrative Scope

These examples are illustrative translations, not a complete legal or operational model for ticketing. MTK's entitlement model can represent these patterns. Vertical-specific productisation — including resale regulation, event liability, and distribution platform agreements — is a separate implementation concern.