1. Two-stage model
Every policy-year record is generated in two stages, same shape as motor, life, and health:
- Frequency — whether at least one claim occurs this policy year is table-rated, life's/health's technique, not motor's from-scratch logistic regression. A property-type base claim rate (Residential vs. Commercial) is the actuarial anchor; building age and security-features-present each apply a multiplicative loading on top. This keeps the base-rate table itself the thing a reviewer can check directly, and the loadings legible as loadings on it, rather than opaque coefficients in a regression.
- Severity — for policy years that do have a claim, the payout is a log-normal fraction of the sum insured, motor's/life's "multiple of a sum field" technique. Construction type is the primary severity driver; prior claims count is folded in as a plain continuous coefficient rather than a named-category loading (motor's own treatment of past claims, applied here on the severity side instead of motor's frequency side, since "how many prior claims" is a count, not a category). Claim category and property type each apply a decorative multiplier on top, health's claim-category/plan-tier pattern.
Which stage count to generate is itself a runtime choice on the
generator page —
two-stage (the default) runs both steps above;
single-stage runs the frequency step only. The frequency
logic and its coefficients are identical either way, so
claim_occurred, claim_id,
claim_category, and claim_date
are the same regardless of mode. claim_amount_ghs — the only severity-side column — is entirely absent from the output in
single-stage mode, not null-filled. Whichever mode you pick is recorded
in the dataset's manifest and citation, same reasoning
motor's own stage_mode
toggle documents.
Unlike life and health, where all four hypotheses sit on frequency, and unlike motor, where all four sit on severity, this line puts two hypotheses on each stage — the one combination the other three lines hadn't covered yet. The two frequency-side hypotheses below apply in both stage modes; the two severity-side hypotheses only apply, and are only verified, in two-stage mode.
2. The four hypotheses
Two hypotheses drive whether a claim happens at all; the other two drive how large it is once it does — tracked separately below, since averaging them into one undifferentiated table would obscure which stage each factor actually acts on.
| Factor | Stage | Direction | Rationale encoded |
|---|---|---|---|
| Building age | Frequency | Positive | Older buildings claim more often — electrical and plumbing systems degrade with age, most sharply past 30 years. |
| Security features present | Frequency | Negative | Alarm/CCTV/guard presence deters burglary claims specifically, which make up most of this line's claim volume. |
| Construction type | Severity | Positive | Combustible construction (Wood/Thatch, then Mixed) burns and floods worse than Brick/Concrete/Sandcrete, running larger claims when one occurs. |
| Prior claims count | Severity | Positive | A property with a worse claims history tends to run larger subsequent claims too, not just more frequent ones — the same moral-hazard/correlated-risk logic motor's past-claims hypothesis encodes, on the severity side here instead. |
3. Coefficients
Claim probability is modeled as
p = clip(base_rate(property_type) · building_age_loading ·
security_features_loading · region_flood_loading, min_probability,
max_probability), where base_rate(property_type) is the property-type
base-rate table lookup, building_age_loading is
a banded multiplier on building age, security_features_loading applies only when security features are present, and region_flood_loading is the decorative region term, motor's own region playing the identical role on its frequency side. Claim payout, when a
claim occurs, is modeled as
claim_amount = min(sum_insured · exp(log_base +
log(construction_type_multiplier) + prior_claims_coef ·
prior_claims_count + log(claim_category_multiplier) +
log(property_type_multiplier) + ε), sum_insured), where construction_type_multiplier,
claim_category_multiplier, and property_type_multiplier are named terms keyed off construction type, claim category, and property
type respectively, prior_claims_coef is applied
directly to the prior-claims count rather than as a category lookup, and
ε is normal noise. The min(..., sum_insured) term
is this line's indemnity cap — Home & Property is a pure indemnity contract
with no rider mechanism the way life's accidental-death rider works, so
payout is capped at exactly 1.0x sum insured by construction, not just by
choice of cap magnitude, unlike life's 2.5x cap on sum assured. These coefficients
are illustrative, chosen to produce a clearly recoverable signal — manually
verified to hold in the expected direction for all four hypotheses at n=20,000;
the regression suite's own default sample size is still being finalized
(see ROADMAP.md). Exact magnitudes aren't published on this page and aren't
derived from real Ghanaian property-claims data — see the current defaults,
and change them, in the
Advanced: customize the model panel on the
Home & Property generator if your thesis calls for weaker or stronger effects, and note in your
write-up which values you changed from the defaults.
4. Determinism
Generation runs server-side using a seeded generator (numpy's
default_rng, PCG64) rather than an unseeded
source of randomness — same mechanism as motor, life, and health. The
same seed, record count, and generator version (stamped in every
citation and manifest — see the Cite section on the generator page)
will always reproduce byte-identical output. Report the seed and
record count alongside your dataset — that pair, together with the
generator version, is sufficient for anyone to regenerate exactly what
you analyzed.
5. What's decorative vs. load-bearing
Region, insured name, and premium calculations exist to make records
look like real Ghanaian Home & Property policies and are internally
consistent with each other, but they are not the object of the four
hypotheses above. Treat the premium figures as an illustrative
table-rated approximation, not as calibrated to any actual insurer's
rate card. insured_name is excluded from generated
output only if you disable it in a future name-inclusion toggle (not yet
built — see ROADMAP.md Phase 4.5.3); today it's always present, same as
every other field.
6. Known limitations
- This is synthetic data. It should never be presented as, or mistaken for, real insurer or property-claims data in a publication.
- Frequency is table-rated with multiplicative loadings, not a from-scratch regression — no interaction effects between building age and security features are modeled beyond simple multiplication, unless you add them yourself downstream.
- Claim payout is capped at 1.0x sum insured regardless of how construction type, prior claims, claim category, and property type stack — this line's indemnity cap, a harder constraint than motor's or life's own tail caps since it follows directly from the contract being indemnity-based rather than being a chosen sanity limit.
- If your thesis needs a different balance between the four hypotheses, adjust the relevant loadings in the Advanced: customize the model panel on the Home & Property generator and say so in your write-up.
7. Citing this tool
Something like: "Synthetic data generated using Dataset Foundry (seed = 42, n = 5,000), a deterministic Home & Property insurance data generator built for this thesis in the absence of accessible real-world property-claims data." Include the seed and record count so the exact dataset is reproducible from the tool alone — or use the auto-generated citation block on the generator page, which also includes the generator version and any advanced-config changes.