Insurance Claim Validation System

Claims arrive as one flat payload: claimNumber, policyNumber, policyStatus, policyStartDate, incidentDate, and damageAmount are the fields the three validation tables inspect in sequence.

Format checks run top to bottom with a first hit policy, each failure short-circuiting with its own reason: len(trim(claimNumber ?? '')) < 5 fails as 'Invalid claim number format', a non-numeric incidentDate as 'Incident date is missing or invalid', a policyNumber shorter than 8 characters as 'Invalid policy number format', and damageAmount <= 0 as 'Damage amount must be greater than zero'. The empty final row passes with a blank reason.

Running cheap structural checks before any policy verification is normal claims-intake hygiene: a malformed claim or policy number means the loss cannot be matched to a file at all, and a zero or negative damage amount signals a data entry error rather than a real loss. The minimum lengths of 5 and 8 characters belong to this template's numbering scheme, not to any industry standard.

Before touching status, the first row forwards any upstream failure: !validation.claimDetailsValid re-emits validation.claimDetailsReason so the earliest error survives to the final message. The remaining rows decline when policyStatus equals 'expired', 'canceled', or 'suspended', each with its own reason string, and the catch-all treats anything else as valid.

Coverage has to be in force on the date of loss, so nothing other than an active policy should reach investigation. Keeping expired, canceled, and suspended as distinct reasons matters operationally: an expiry is a renewal conversation, a cancellation may still cover losses that predate the cancellation, and a suspension is often a lapsed payment the insured can cure.

Chained like the previous step, the first row propagates !validation.policyStatusValid with its reason. Then date arithmetic takes over: date('now') - incidentDate > 60 * 24 * 60 * 60 rejects claims reported more than 60 days after the incident, an incidentDate later than now fails as 'Incident date cannot be in the future', and policyStartDate > incidentDate fails as 'Incident occurred before policy start date'.

Prompt-notice requirements are genuine policy conditions, and a 60-day reporting window sits in the range many property forms use, though the exact figure here is a template choice. The other two rows guard against fraud and bad data: a future-dated loss is impossible, and a loss that predates inception is simply not covered under the policy period.

One AND across the three validation flags yields isValid, while validationMessage picks the first failing stage's reason through nested ternaries and defaults to 'Claim validation passed'. The nextStep expression then routes the file to 'investigation' or 'rejection', giving downstream systems a single field to dispatch on.