Inspire key concepts

This page is the domain primer: the insurance and platform concepts every Inspire core assumes. It describes the domain as Inspire models it, with the objects and status codes the systems actually use — mostly from inspire-gi, the most complete core, with the other cores’ variations noted. Individual terms are defined in the Glossary; this page explains how they fit together.

Parties and roles

A party is any person or organisation the system knows about. Inspire GI keeps one golden party record per real-world entity (tparty), with roles hung off it — the same person can be a customer in one policy and a producer in another.

Role	What it does	Where you meet it
Customer / policyholder	Buys the policy, is billed, is owed the promise	Every core
Insured	The person or thing actually covered. May differ from the policyholder — a company insures its employees’ lives	Types: `PRIMARY`, `EMPLOYEE`, `SPOUSE`, `CHILD`, `DEPENDANT` (`tpolicy_insured`)
Member / dependent	Group and pension flavour of insured: a person enrolled under a group contract	`inspire-group` member module
Producer / agent	Sells and services business; earns commission	`tproducer`; commission shares on the policy
Reinsurer	Takes a share of the risk under a treaty or facultative placement	`inspire-gi` reinsurance module
Provider	Hospital, clinic or repairer that serves a claim	Group claims, provider network
Creditor / partner	The bank or financing company whose loans are insured	Credit life: `tpartner`

The product factory

Inspire GI’s central design idea, worth understanding even if you work on another core:

A product is a tree, not a set of columns. A policy is that tree, instantiated.

tproduct_element is a self-referencing table of typed nodes. A personal accident product is ROOT → RISK(person) → COVERAGE → BENEFIT. A commercial property product is ROOT → SECTION → INTEREST → COVERAGE, twice over. Same table, different rows — which is how the design goal holds: launching a new insurance product must not require a schema change or a deployment.

Products are defined in layers, three to four deep:

flowchart LR
    A["Component library<br/>reusable parts"] --> B["Technical product<br/>the superset for a line of business"]
    B --> C["Market product<br/>what is actually sold"]
    C --> D["Plan<br/>a restricted, packaged variant"]

Data that has no column lives in the data dictionary: tdd_field defines a field once, tproduct_element_field binds it to a level of a product, and tpolicy_element_value stores the value on a policy. Adding “vehicle chassis number” to a motor product is an INSERT, not a DDL change.

A published product version is immutable. In-force policies stay bound to the version they were written on (tpolicy.ProductVersionID), so redefining a product never rewrites history.

The policy and its lifecycle

A policy is a contract with a versioned structure. The words in the lifecycle, in order:

Quotation — a rated offer with no commitment. Premium is computed by the rating engine walking the product tree bottom-up, leaving a rating trace (trating_trace) so every figure is explainable.
Proposal — the real risk, real names, an allocated number (ProposalNo from tnumber). Now underwriting applies.
Issuance — a PolicyNo is allocated, the policy becomes in force, and version 1 of the policy tree is written with clause wording snapshotted.
Servicing — endorsements (mid-term changes), renewals (a new policy, linked both ways), cancellation and reinstatement.
Claims — see below.

The lifecycle is tracked in PolicyStatus, seeded in GI as:

Code	Meaning
`PN`	Pending — new business captured, not yet validated
`RD`	Ready — validated, awaiting underwriting
`TV`	Validated — underwriting accepted
`IF`	In force — issued
`PE` / `PR`	Pending endorsement / pending renewal
`TX` / `TM`	Cancelled / terminated

A transaction against a policy is one of three types: NB (new business), EN (endorsement) or RN (renewal) — POLICY_TRANS_TYPE.

Versioning is by element, not by policy row. Each policy element row carries an ElementKey (stable identity, for the life of the policy) and a version window (FromVersionSeq / ToVersionSeq). Endorsing an element closes its row and opens a new one under the same key; unchanged siblings stay live. Any past state is a plain query: fn_policy_element_at_version().

Underwriting

Underwriting is the insurer deciding whether to take the risk, and on what terms. Inspire automates the happy path:

Automatic underwriting runs configured rules per proposal (tunderwriting, UwType = AUTO, one tunderwriting_rule_result per rule).
A rule can refer the case to a human underwriter (tunderwriting_referral, with an SLA clock).
The underwriter accepts, declines, or accepts with terms — a loading (premium surcharge), a discount, or an excess.
Cases that pass without referral are STP — straight-through processing.
Who may approve what is the authority matrix (tmatrix), which claims and settlements also climb.

Blocklist screening runs at proposal and claim time against sanctions and internal blacklists (tclient_blocklist).

Claims

The claim pipeline, in the vocabulary the systems use:

FNOL — first notice of loss: the initial report, any channel. The notification row (tclaim_notification) is written before anything is known, so a loss is never lost.
Registration — matching the notice to the policy version in force at the loss date, snapshotted immutably into tclaim_policy. No later endorsement can change what the claim was entitled to.
Reserving — setting aside the expected cost. Reserves are movements, not balances: tclaim_reserve holds the current position, every change is an immutable tclaim_reserve_movement (OPEN / INCREASE / DECREASE / PAYMENT / RECOVERY). Actuarial triangles are exact because they read the movements.
Adjudication — calculating what is payable: gross loss, minus deductible, minus depreciation, minus salvage, scaled by underinsurance and the coinsurance share.
Settlement and payment — approved up the authority chain if needed, then a payable, then money out.
Recovery — money coming back: subrogation (third party at fault), salvage (damaged property sold), reinsurance (the ceded share), or a recoverable deductible.
Catastrophe — a declared event (tcatastrophe) with an hours clause (for example 72 hours of windstorm), tagging claims so accumulation can be measured against catastrophe reinsurance.

Premium and money

Premium is the price of the promise. Gross premium is before reinsurance; ceded premium is the reinsurers’ share; net is what remains.
A bill (tbill) is immutable once created; its fees (tbill_fee) split the money into net premium, tax, commission, stamp duty — each fee routed either to AR/AP (tarap, one row per installment) or to the ledger.
Collection (money in) parks in suspense (tsuspense) and is allocated by offset (toffset) against AR. Residual rounding clears by tolerance offset; uncollectible debt by write-off.
Payment (money out — claims, refunds, commission, RI premium) clears its AR/AP directly. There is no offset step. Confusing the two flows is the classic newcomer error.
A statement nets many debits and credits for one counterparty into a single collection or payment.

The ledger

Every financial event lands in the general ledger through posting templates: tevent_type matches the business transaction, expands into debit and credit legs, resolves accounts and up to 12 analysis dimensions, and stages a voucher (tgl_voucher). Vouchers become immutable journals (tjournal) in batches per accounting period, feeding the trial balance. The interface to an external ledger (often Oracle) can be INTERNAL, EXTERNAL or BOTH — ADR 0001.

Statutory supply — OJK reporting and IFRS 17 data — is drawn from the same movements.

Reinsurance

The insurer insures itself. What it keeps is the retention; what it passes on is ceded through:

Proportional treaties — cede a share of premium and sum insured at issuance: quota share (a fixed percentage) and surplus (everything above a retention, in lines).
Non-proportional treaties — attach at claim time: XOL (excess of loss per risk or per event), catastrophe XOL (per accumulation), stop loss (on a portfolio’s loss ratio). Each has an attachment point, a limit and paid by reinstatements.
Facultative — one-off placement of a single large risk.

Every cession (tcession) splits across treaty participants whose shares total 100%, produces RI premium and RI claim recovery, and rolls up into bordereaux (periodic schedules) and per-reinsurer statements and accounts.

Platform vocabulary

The plumbing every Inspire app shares — much of it inherited from the Orbit DMS platform, all of it useful to recognise:

tcode / tcode_type — the code tables: every dropdown and enum lives as rows, seeded (in GI, 194 code types verbatim from nxo-dms).
tnumber — the autonumbering engine that assembles document numbers from tokens like [YYMM] and [NEXT].
LOV / LOM — list of values, single- and multi-select. Two different mechanisms share the name on some screens; check which one a page means.
Entity lifecycle — documents move through status, approval (tentity_approval), queues and history via a shared framework keyed on (EntityType, EntityReference).
Outbox — GI fans out post-commit work (billing, cession, documents, search projection) through a durable queue (tentity_queue), at-least-once: issuance must not fail because reinsurance is briefly unavailable.
ReturnCode — the API envelope’s numeric verdict: 0 success, -1 failure, -2 a reconfirmable warning the client may override with byPassValidation.
ccs — the gitignored connection-string file next to the API binary. Ask a teammate for it; it carries the database password.

The big flow — these concepts in motion, stage by stage
The five cores — where your core differs
Glossary