MTK Across Domains
One entitlement protocol, many industry languages.
MTK is not a gift card system, loyalty system, ticketing system, insurance system, or travel booking system. It is a protocol for modelling, evaluating, exercising, delegating, mutating, and reconciling entitlements across domains. A gift card balance, loyalty benefit, event ticket, insurance coverage, and travel reservation may look different at the business level — but they share the same underlying structure: someone issues a right, someone holds or benefits from it, rules govern whether it can be used, and a verified action changes its state. Different industries use different language for the same structural pattern.
Industry vocabulary mapped to MTK primitives
Each card below shows how a familiar industry concept maps onto a canonical MTK primitive.
The domain terms (redeem, claim, check in, board) are translations of the consume primitive —
not alternatives to it. The protocol verb is always consume.
The insurance domain illustrates how domain-specific workflows compose on the canonical 5-state lifecycle (PENDING → ISSUED → ACTIVE → CONSUMED → REVOKED). The claim workflow adds 17 states (draft → triggered → claim_initiated → evidence_submitted → assessed → approved / part_approved / declined → paid / settled → closed / disputed / resolved) as a business-process layer. The canonical lifecycle governs protocol truth; the claim workflow governs the insurance business process. They coexist on the same entity but are architecturally separate. Not every domain requires this depth — simpler domains may map directly onto the 5-state canonical lifecycle.
These examples are illustrative translations, not a complete legal or operational model for each industry. MTK's entitlement model can represent these patterns. Vertical-specific productisation is a separate implementation concern.
The same pattern in different words
Each of the following looks domain-specific, but structurally each is the same operation:
- A gift card is redeemed.
- Loyalty points are spent.
- A ticket is checked in or admitted.
- Insurance coverage is claimed.
- A passenger checks in or boards using a travel right.
The canonical protocol verb for all of these is consume (PSL-002).
The domain-specific terms (redeem, spend, admit, claim, board) are translations — they describe the
same protocol operation in vertical-native language.
Why containers are not truth
Wallets, accounts, bookings, policies, and reservations are often containers. They may display, group, or reference entitlements — but they are not automatically the authoritative source of entitlement truth.
MTK treats entitlement truth as discrete, traceable, and evaluation-driven. A wallet showing a balance, a policy showing coverage, or a PNR showing a booking are presentations. The protocol truth remains with the discrete, issuance-traceable entitlement records and the evaluation engine that governs whether they can be exercised.
An authorisation is a decision record — the outcome of the evaluation process. Authority is the underlying permission, role, or delegated power that enables an actor to request or perform an operation. These are distinct concepts and must not be used interchangeably.
Containers may present aggregated state, but protocol truth must remain discrete, issuance-traceable entitlements. The evaluation engine — not the container — determines whether an entitlement can be exercised.
A carrier (QR code, barcode, token) may reference or transport evidence, but does not determine truth. Reconciliation later aligns provisional or offline actions against authoritative truth.
Canonical lifecycle and domain-specific workflows
Some domains map directly onto the canonical 5-state lifecycle. Others build richer domain-specific workflows on top of it. Both patterns are valid — MTK supports them without losing protocol coherence.
The claim workflow (17 states) governs the insurance business process. The canonical lifecycle governs protocol truth. They coexist on the same entity but are architecturally separate. This is a concrete example of how domain-specific workflows compose on the canonical lifecycle without replacing it.
MTK primitive set
These are the foundational concepts that appear across every domain mapping. Domain-specific terms are translations of these primitives — not independent concepts.
consume (PSL-002). Domain terms (redeem, claim, check in) are translations.Why a shared model matters
A common entitlement model across verticals enables capabilities that domain-specific systems cannot provide in isolation.