The five Inspire cores

All five cores run the same skeleton — define a product, sell a contract, underwrite it, bill it, serve it, pay claims, keep the ledger and the reinsurance honest (The big flow). What differs per vertical is what the contract is, who is covered, and how the volume arrives.

	GI	Group	Credit Life	Pension	Individual
Contract	One policy per customer or fleet	One master policy per employer scheme	One policy scheme per creditor partner; certificates per loan	One policy per policyholder/employer	One policy per person (planned)
Covered life	Property, vehicles, persons	Members and dependents	Debtors (loan holders)	Plan members	The applicant
How volume arrives	One by one, or bulk files for micro-insurance	Bulk enrollment uploads, per policy year	Bulk certificate uploads per disbursement file	Regular contribution remittances	One by one via e-submission
Billing to	The customer	The sponsor (employer/client)	The creditor partner	The policyholder/employer	The policyholder
Claims character	Loss of property, accident, liability	Member medical and life events, via providers	Debtor death or disability; early payoff = surrender	Retirement and withdrawal benefits	Death, maturity, surrender
Replaces	Nothing — greenfield	AIA Compass 2000	iCLIPS	Avrist RPAS	—
Status	Furthest along	Specs done, code starting	In build	Legacy archive only	Planned, no repo yet

Inspire GI — general insurance

The reference implementation of the big flow, and the only core built greenfield. Non-life: motor, property, personal accident, travel, micro-insurance. Its distinguishing capability is the product factory — products are trees of elements, versioned and published as configuration, so a new product is never a schema change.

The one flow GI adds to the skeleton is bulk issuance for micro-insurance and partner channels:

flowchart LR
    A["Partner file<br/>Excel or API"] --> B["Upload with detail rows"]
    B --> C["Validate per row"]
    C -->|"invalid"| D["Error reported<br/>for that row"]
    C -->|"valid"| E["Issue policy or certificate<br/>under a master policy"]
    E --> F["One consolidated AR<br/>for the partner"]

Per-row validation matters at scale: a 50,000-row file with three bad rows should issue 49,997 policies and report three, not reject the file.

Where to look — inspire-gi/docs/00-overview.md (the design goal), 06-process-flows.md §10 (bulk), BulkUploadsController.

Inspire Group — group insurance

Group inverts the contract model: the customer is an employer or scheme sponsor holding one master policy; the covered lives are members and dependents enrolled under it, each covered by the policy’s products and plans. The business flow:

flowchart TB
    CL["Client / employer"] --> PS["Setup<br/>products, plans, benefits, rates"]
    CL --> MP["Master policy<br/>the group contract, policy years"]
    MP --> EN["Enrollment<br/>members and dependents,<br/>bulk upload or screen"]
    EN --> CV["Member coverage<br/>under policy products and plans"]
    MP --> BL["Bill the sponsor<br/>draft bills, then the official bill"]
    BL --> RC["Receivables<br/>collect from the client"]
    CV --> GMC["Member claims<br/>adjudication, EOB letters"]
    GMC --> PRV["Provider network<br/>pre-authorisation, cashless"]
    MP --> RW["Renewal<br/>policy-year rollover, average rate"]

Details that make group group:

Billing is draft-then-official. Bills are produced per policy-product on a bill mode (monthly, quarterly, semi-annual, annual), reviewed as drafts, then made official; receivables follow.
Claims are member claims, adjudicated by configured edits, with Explanation of Benefits letters to members and heavy provider-network interaction (pre-authorisation, cashless treatment).
The legacy this core replaces — AIA’s Compass 2000 — ran group life, group medical/dental (GMD), LTD and ASO across nine countries; the migration collapses the country forks into one generic baseline.

Where to look — inspire-group/docs/03-migration-plan.md (the 24-module map), 04-module-specs/policy.md, member.md, billing.md, claims.md; web modules client, policy, member; MemberController (dependents as a first-class concept).

Inspire Credit Life — loan protection

Credit life insures loan repayment: if the debtor dies or is disabled, the insurer settles the outstanding loan. The customer is the creditor partner — a bank, financing or leasing company — and volume arrives as bulk uploads keyed to disbursement files, not one application at a time.

flowchart TB
    BK["Creditor partner<br/>bank, financing, leasing"] --> SC["Policy scheme<br/>product package, rates, limits"]
    BK --> LN["Loan disbursement file"]
    LN --> UP["Bulk certificate upload<br/>one row per debtor loan"]
    UP --> V["Validate per row<br/>agreement no, installment, duration"]
    V --> CERT["Certificate issued<br/>under the scheme policy"]
    CERT --> BL["Billing to the partner<br/>consolidated"]
    CERT --> CLM["Claim<br/>debtor death or disability<br/>pays the outstanding loan"]
    CERT --> SUR["Surrender<br/>early loan payoff<br/>refund the unearned premium"]

The certificate — not the policy — is the unit of business: tcertificate carries the loan fields directly (MonthlyInstallment, LoanDuration, LoanMaturityDate, LoanInterestRate), with satellites for coverage, premium, beneficiaries, health questions and staging. Early settlement of the loan is a surrender, not a cancellation. The vocabulary is bilingual: the legacy system was Indonesian, so Debitur (debtor) and agreement numbers appear in the schema.

Where to look — inspire-cl/README.md, CertificateController, surrenderController, ClaimController; sql/010-tables/ (the iCLIPS schema, regenerated); tcertificate*, tCertUpload, texim_file families.

Inspire Pension — retirement administration

Pension is a savings and investment administration, not just a risk cover: the system’s job is to track contributions in, fund performance, and contractual benefits out. No modern code exists yet — the domain vocabulary below comes from the RPAS archive (legacy/scrpas.sql, 862 tables) and is what the core will be built to serve:

flowchart TB
    PH["Policyholder / employer"] --> PL["Plan<br/>investment options, vesting scale"]
    MB["Members"] --> EN["Enrollment<br/>member accounts"]
    PH --> CT["Contributions<br/>regular remittances"]
    CT --> AL["Fund allocation<br/>across investment options"]
    AL --> UP["Unit pricing<br/>fund price updates"]
    UP --> BAL["Fund balance<br/>per member account"]
    BAL --> VS["Vesting<br/>entitlement by the vesting scale"]
    BAL --> CHO["At retirement or exit"]
    CHO --> RT["Retirement benefit"]
    CHO --> WD["Withdrawal<br/>full or partial"]
    CHO --> SW["Switch<br/>move between funds"]

The distinctive machinery is fund accounting: allocations and movements per investment option (tmffnalloc, tmffnmovement), daily fund prices, and balances per member; vesting scales deciding what the member keeps; and withdrawal/switch processing with its own interface files. Regulatory reporting (OJK) is a first-class output of the legacy system and will be of the core.

Where to look — inspire-pension/legacy/Doc RPAS/ and legacy/scrpas.sql. When the build starts, the inspire-group platform is the presumptive starting point (as it was for credit life).

Inspire Individual — planned

No repository exists yet. The intent is the classic individual-life flow on the shared platform: illustration → application → underwriting (medical and financial) → issuance → premium collection → servicing (loans, top-ups, riders, fund switches if unit-linked) → claims, surrender or maturity.

Two relationships already exist in the estate: nxo-link is the live life e-submission system (illustration, application, funds, questionnaires) that an individual core would sit behind, and the launcher already carries the product’s brand assets. Until a repository appears, treat this section as intent, not design.

Legacy to Inspire — where the migrated cores’ behaviour comes from
Glossary