Claims 3: Reusing the Member Elsewhere

Problem statement

Claims 2 imported person-model.xml into one model. That’s not really reuse yet — reuse means the exact same library backs more than one thing without being copied. If your organization needs synthetic members for claims data today and a completely unrelated policy roster tomorrow, the identity logic has to live in exactly one place, or you’re back to the copy-paste-and-drift problem the Vitals 3 lesson already solved for distributions.

The model

A policy roster has nothing to do with claims — no frequency, no severity, just membership: who’s on the book, their policy number, their coverage tier. It imports the identical person-model.xml used in Claims 2.

<?xml version="1.0" encoding="UTF-8"?>
<dataset seed="42">
  <root node="PolicyRow"/>
  <nodes>
    <Append name="PolicyRow">
      <input name="Member"/>
      <input name="PolicyNumber"/>
      <input name="Tier"/>
    </Append>
    <Import name="Member" file="person-model.xml"/>
    <Sequence name="PolicyNumber" start="100000" step="1"/>
    <Categorical name="Tier" weights="0.5,0.35,0.15"/>
  </nodes>
</dataset>

Sequence counts up by a fixed step — a clean policy number, not a distribution pretending to be one. Categorical draws a weighted index over three coverage tiers (0/1/2, weighted roughly 50/35/15 — read as Bronze/Silver/Gold, or however your own tiers are ordered). Run it:

female|Sophia|Peterson,100000.0,1
female|Nancy|Turner,100001.0,2
male|Isaac|Moore,100002.0,2
male|Jeremy|Alvarez,100003.0,2
female|Kelly|Ross,100004.0,1
male|Patrick|Cox,100005.0,0
female|Ruth|Davis,100006.0,0
male|Patrick|Moore,100007.0,0

The proof of reuse

That’s the same member from Claims 2 — not a name that merely looks similar, the identical generator graph, wired into a model that shares nothing else with Claims 2’s claim structure. If you extended person-model.xml tomorrow (add a middle name, change the surname pool), both models would pick up the change automatically — the same “add a field once” argument Vitals 3 already made about vitals-lib.xml. A model file that’s only ever referenced by one other model isn’t proven reusable yet, no matter how cleanly it’s factored — it’s reuse the moment a second, unrelated model imports it too.

Going back to Claims 2, the “person” we added before can now be a “policy” instead. Import the policy roster above instead of person-model.xml and now you’re starting to model a real, reusable business object that is portable to other models you use.