Claims 2: Claims With a Member

Problem statement

Lesson 1’s model tells you how many claims happened and how large they were, but nothing about who they happened to. Real claims analytics almost never stops at aggregate counts and amounts — you need to roll claims up by policyholder, look for members with unusual claim patterns, or join claims data against a completely separate system that only knows how to key on a person. None of that works if “who” isn’t part of the observation at all.

The model

SpiceGrinder Pro already ships a full synthetic-identity business object: samples/pro/person-model.xml. It’s worth looking at directly — a PersonAssembler (a small custom filter) combines a 50/50 Mix over gender with a matching given-name FlatFile lookup (SSA top-100 names) and a separate surname FlatFile lookup (US Census top-100 surnames), so gender and given name always agree while the two name components vary independently.

Rather than copy any of that into the claims model, Import it — the same tool the Vitals lessons used to reuse vitals-lib.xml.

<?xml version="1.0" encoding="UTF-8"?>
<dataset seed="42">
  <root node="ClaimObservation"/>
  <nodes>
    <Append name="ClaimObservation">
      <input name="Member"/>
      <input name="Frequency"/>
      <input name="Severity"/>
    </Append>
    <Import name="Member" file="person-model.xml"/>
    <Poisson name="Frequency" lambda="3.5"/>
    <Lognormal name="Severity" mu="8.0" sigma="1.2"/>
  </nodes>
</dataset>

One new <input>, one new Import line — nothing about Frequency/Severity changed. Run it and each observation is now a full row: who, plus what happened to them.

female|Sophia|Peterson,3,1546.002970041561
male|Isaac|Moore,9,7302.257200899249
female|Karen|Collins,2,4330.182421819674
male|Donald|Jones,5,829.3713272352472
female|Virginia|Diaz,4,1369.5704367902017
female|Rebecca|Wilson,2,3257.7946132474904
female|Jean|Patel,3,508.32605957712695
female|Sarah|Williams,6,2265.6032650534235

Reading this as a claim record, not a coincidence

Notice that frequency and severity are drawn completely independently of who the member is — that’s a simplification we’re using for this lesson. A real book of business often does have correlation between policyholder attributes and claim behavior; nothing stops you from modeling that (a Mix over member cohorts, the same technique the Vitals lessons used for the anomalous-reading population, is a natural next step).

This lesson is narrower than that. We’re just showing that a complex data type like an identity composes into a claim record the way any other input does, with Append never caring whether an input is a statistical distribution or an entire imported business object.