DOMAIN-MAP-02 · Insurance

MTK for Insurance

Insurance products issue coverage rights within a policy, evaluate claims against policy terms and exclusions, route claims through an approval workflow, and settle with policyholders via payout. MTK maps onto this: the policy is a container, coverage is the entitlement, and claiming is the domain translation of the consume primitive.

Insurance is also the domain where MTK's dual-state model is most visible. The canonical 5-state lifecycle governs protocol truth; a richer claim workflow layer governs the insurance business process. Both are now structurally represented in the OpenAPI schema — this is not an annotation or a workaround, it is schema truth as of STATE-SPLIT-01B and LIFECYCLE-RESP-01.

Primitive Mapping

How insurance concepts map to MTK

The protocol verb is always consume (PSL-002) — claim is a domain translation of it. Authorisation is the claim approval decision, not the claim itself.

MTK Primitive	Insurance Equivalent
Issuer	Insurer
Holder	Policyholder
Beneficiary	Insured Party / Named Driver / Named Beneficiary
Container	Policy
Entitlement	Coverage
Constraint	Policy Terms / Exclusions / Coverage Limits
Verification	Evidence / Documentation / Identity Check
Authorisation	Claim Approval / Coverage Decision
Consume / Domain Action	Claim (coverage is claimed)
Mutation	Claim State Updated / Coverage Drawn Down
Delegation	Named Driver / Named Beneficiary / Power of Attorney
Settlement	Insurer Payout
Reconciliation	Claim Audit / Reinsurance Recovery
Revocation / Suspension	Cancel / Suspend Cover

ENUM-RATION-01 · Dual-State Model

The dual-state system: canonical lifecycle and claim workflow

Insurance is the domain where MTK's dual-state architecture is most clearly visible. Following ENUM-RATION-01, STATE-SPLIT-01B, and LIFECYCLE-RESP-01, there are now two structurally distinct state systems on an insurance entitlement, both represented in the OpenAPI schema.

This is not an annotation or a warning about a legacy inconsistency. It is current schema truth.

lifecycle_state_canonical (CanonicalLifecycleState) — Protocol truth

PENDING→ ISSUED→ ACTIVE→ CONSUMED→ REVOKED

This is the canonical protocol lifecycle: 5 UPPERCASE values. It governs protocol truth — whether a coverage entitlement has been issued, is active, has been consumed, or has been revoked. This field is lifecycle_state_canonical on the Entitlement schema (CanonicalLifecycleState). It is the authoritative field for protocol decisions.

state (ClaimWorkflowState) — Insurance business process

draft→ triggered→ claim_initiated→ evidence_submitted→ assessed→ approved part_approved declined→ paid settled→ closed disputed resolved

This is the insurance claim workflow: 17 lowercase values. It governs the insurance business process — from first notice of loss through assessment, approval, and payout. This field is state on the Entitlement schema (ClaimWorkflowState). It tracks the domain-level claim process; it does not replace or override lifecycle_state_canonical.

How They Coexist

The canonical lifecycle and the claim workflow coexist on the same entity but are architecturally separate concerns. A coverage entitlement can be ACTIVE (canonical lifecycle) while simultaneously in evidence_submitted state (claim workflow). They do not conflict — they serve different purposes.

The claim workflow composes on top of the canonical lifecycle. When the claim reaches settled and the coverage is fully drawn, the canonical lifecycle transitions to CONSUMED. The workflow layer governs the business process; the canonical layer governs protocol truth.

Not every domain requires this depth. Simpler domains — gift cards, ticketing — map directly onto the 5-state canonical lifecycle without a separate workflow layer. Insurance needs the richer workflow because claims involve multi-party assessment, evidence collection, and regulatory obligations before consumption can be recorded.

Protocol Flow

How it works

A canonical insurance claim flow, expressed in protocol-safe language.

01 An insurer (issuer) creates a policy (container) and issues coverage entitlements — each representing a discrete insured risk with its own terms, limits, and constraints.

02 An insured event occurs. The policyholder initiates a claim. The claim workflow state advances through claim_initiated → evidence_submitted → assessed. MTK tracks these transitions against the coverage entitlement.

03 MTK evaluates coverage constraints: policy terms, exclusions, coverage limits, and identity of the insured party. Evidence (documentation, assessor reports) is submitted as verification input. The authorisation decision is the coverage approval.

04 If coverage is authorised, the entitlement is consumed (consume primitive, domain translation: coverage is claimed). The coverage entitlement state mutates. The claim workflow advances to approved → paid → settled.

05 Payout resolves the settlement obligation. Reconciliation aligns the claim audit trail against reinsurance recovery data and regulatory reporting requirements. The canonical lifecycle transitions to CONSUMED once the coverage is fully drawn.

Protocol Safety

Policy vs coverage: container vs entitlement

Container vs Entitlement — Insurance

A policy is a container. It may present an aggregated view of all coverages, display the premium schedule, and show the policy period. It is not authoritative protocol truth.

Coverage is the entitlement. Each coverage (e.g., medical evacuation, trip cancellation, liability) is a discrete protocol-tracked right with its own constraints, evaluation rules, and lifecycle. A policy presenting "comprehensive cover" does not guarantee any individual coverage is active, unclaimed, or applicable to a given loss event — each must be evaluated independently.

This distinction is critical for multi-line policies: a motor policy with liability, own-damage, and personal accident coverages is a single container holding three discrete entitlements. Each has its own evaluation path and claim workflow state.

Domain Considerations

Insurance-specific patterns

Claim Workflow

The insurance claim workflow (17 states: draft → triggered → claim_initiated → evidence_submitted → assessed → approved/part_approved/declined → paid/settled → closed/disputed/resolved) governs the business process. It does not replace the canonical lifecycle — it composes on top of it. Claim states track the operational progress of a claim; canonical lifecycle states track protocol truth about the coverage entitlement.

Evidence and Verification

Insurance claims require substantial evidence before a coverage decision can be made. In MTK, evidence submission is part of the verification stage. Documentation (photos, police reports, medical records, assessor reports) constitutes the verification input that feeds the authorisation decision. Evidence is tracked as part of the claim evaluation record, not as a modification to the coverage entitlement itself.

Coverage Rules and Exclusions

Policy exclusions, coverage limits, deductibles, and territorial restrictions are constraints on the entitlement. MTK's constraint evaluation engine assesses these against the presented claim context. A claim that falls within an exclusion receives a declined authorisation decision — protocol-governed, with a recorded reason code, not a soft rejection.

Payout and Settlement

Insurance payout is the settlement of the coverage obligation. After an approved claim reaches the paid/settled workflow state, the financial resolution is recorded as a settlement event. Reconciliation aligns claim payments against reinsurance recoveries, bordereau submissions, and regulatory reserve calculations.

Delegation: Named Parties

Insurance frequently involves named parties other than the policyholder: named drivers on motor policies, named beneficiaries on life policies, insured employees on group schemes. In MTK, these are delegation grants — the coverage entitlement is issued to a holder, with one or more beneficiaries delegated the right to claim against it. Sub-delegation constraints prevent unauthorised further delegation.

Illustrative Scope

These examples are illustrative translations, not a complete legal or operational model for insurance. MTK's entitlement model can represent these patterns. Vertical-specific productisation — including regulatory solvency requirements, reinsurance treaty structures, claims handling obligations, and policy wording law — is a separate implementation concern.