Why Record Status Matters
A loss data file may contain an exact payment, a threshold report, or a follow-up duration during which no loss was observed. These entries can look like ordinary numbers, but they do not all mean the same thing. A recorded \(20{,}000\) might be an exact loss of \(20{,}000\), or it might mean only that the loss reached a reporting cap of \(20{,}000\). The number alone cannot distinguish those cases.
For empirical work, retain both the reported information and its status. This tutorial focuses on how to encode that information faithfully. It does not estimate a distribution from incomplete data. All scenarios and data below are hypothetical. No interest rate, mortality assumption, or probability distribution is required for this recording task.
A useful general representation is a pair consisting of a status and the information reported. To make the meaning precise, associate each record with the set of loss values compatible with it. An exact observation \(X=x\) is compatible with the one-element set \(\{x\}\). A lower-bound report \(X\ge c\) is compatible with \([c,\infty)\); a strict lower-bound report \(X>c\) is compatible with \((c,\infty)\). The endpoint is part of the data definition, not a formatting detail.
Here \(\mathcal{C}\) denotes the compatible-value set. Similar notation works for upper bounds: \(X\le c\) corresponds to \((-\infty,c]\), while \(X<c\) corresponds to \((-\infty,c)\). If the loss is known to be nonnegative, intersect a reported set with \([0,\infty)\). A record with no usable loss information should instead be marked unavailable or missing, not assigned a bound that was never observed.
A Consistent Record Format
A practical record can store an identifier, a status, the reported value or limits, the unit, and the exact comparison operator. For example, a lower-bound entry should distinguish \(X\ge 20{,}000\) from \(X>20{,}000\). If a data source uses a cap that includes the cap value, storing only “right-censored at 20,000” without its convention risks ambiguity.
| Information available | Suggested status | What the record says |
|---|---|---|
| Loss amount is observed | Exact | \(X=x\) |
| Loss is at least a threshold | Lower bound, inclusive | \(X\ge c\) |
| Loss is greater than a threshold | Lower bound, strict | \(X>c\) |
| Loss lies within a reported band | Bounded interval | \(a\le X<b\), or the stated alternative |
| No loss information is available | Missing/unavailable | No restriction on \(X\) is provided by the record |
The table describes ways to record information, not estimation procedures. In particular, it does not license replacing a bound by its threshold or midpoint. If a file uses a special reporting rule, record the rule as well as the numeric value.
Decide whether the record concerns a loss amount, a payment, or elapsed time to an event. Keep the quantity and unit explicit.
Determine whether the value is exact, bounded, incomplete, or unavailable. Do not infer exactness from the presence of a number.
Translate the reporting rule into an equality or inequality, including whether equality at a threshold is allowed.
Confirm that the reported value, status, units, and compatible set agree with the source description.
Why the Compatible-Set Representation Works
The set representation is a direct translation of what a record establishes. If the observed value is exactly \(x\), the only value consistent with the observation is \(x\), so the compatible set is \(\{x\}\). If the report says the loss is at least \(c\), every value from \(c\) upward is consistent, including \(c\), and every value below \(c\) is inconsistent. Therefore the compatible set is \([c,\infty)\), not \((c,\infty)\). For a strict report \(X>c\), the value \(c\) is excluded, giving \((c,\infty)\). This is why the inequality symbol must be preserved when encoding a record.
A record with a band follows the same logic. If it says \(a\le X<b\), values at \(a\) are compatible, values at \(b\) are not, and values outside the band are not. The resulting set is \([a,b)\). This representation does not claim that the true loss is any particular point inside the set; it states only what the observation supports.
Worked Example: Exact Payments and an Inclusive Reporting Cap
A hypothetical insurer records four claim payments. Two are measured exactly as \$4,860 and \$12,300. For another claim, the system reports “\$20,000,” with the documented rule that payments at or above \$20,000 are capped in the file and the exact amount is not retained. A fourth claim is reported exactly as \$20,000. Encode each record. All monetary values are in dollars. No distributional, interest, or mortality assumption is used.
Step 1: Identify exact reports. The first record is \(X=4{,}860\), so its status is exact and its compatible set is \(\{4{,}860\}\). The second is \(X=12{,}300\), with compatible set \(\{12{,}300\}\).
Step 2: Apply the stated cap rule. The capped record means the true payment is at least \$20,000. Because the rule includes equality, encode it as \(X\ge20{,}000\), with compatible set \([20{,}000,\infty)\). It is not an exact \$20,000 payment.
Step 3: Keep the exact threshold payment distinct. The fourth record is documented as an uncapped exact observation. Its compatible set is \(\{20{,}000\}\). Although the displayed number matches the cap threshold, its status differs from the capped record.
Check. The capped record allows \(X=20{,}000\) and values above it; the exact record allows only \(X=20{,}000\). The two records therefore encode different information despite displaying the same number.
Bounded Reports and Incomplete Times
Not every incomplete observation is a threshold cap on a loss amount. A data source may report that a loss falls in a band, or it may record how long a subject was observed before the study ended without an event. The observed quantity and the observation status should be kept separate. For a time-to-loss variable \(T\), an event observed at time \(t\) is an exact time \(T=t\). If observation ends at time \(c\) and no event has occurred by then, the record says \(T>c\), provided the time convention defines an event at \(c\) as already observable. If the source instead defines “not observed through time \(c\)” to include the endpoint, that convention must be recorded explicitly.
This encoding is not a claim that the loss will never occur. Nor does it assign an event time of \(c\). It records the time actually observed and the fact that the event was not seen during that period. Time units matter: a duration of 18 months is not numerically the same as 18 years.
Worked Example: Loss Known Only to Fall in a Band
A hypothetical equipment insurer groups reported repair losses into the band “at least \$650 but less than \$750.” A record in that band displays \$650 as its lower endpoint. Encode the information, then determine whether exact losses of \$650, \$700, and \$750 are compatible. Amounts are in dollars. No probability distribution, interest rate, or mortality assumption is used.
Step 1: Translate the band literally. “At least \$650” includes the lower endpoint, and “less than \$750” excludes the upper endpoint. Thus the report is \(650\le X<750\), with compatible set \([650,750)\).
Step 2: Check \$650. Since \(650\le650<750\), an exact loss of \$650 is compatible.
Step 3: Check \$700. Since \(650\le700<750\), an exact loss of \$700 is compatible.
Step 4: Check \$750. The condition \(750<750\) is false, so an exact loss of \$750 is not compatible.
Check. The interval endpoints in the encoded set match the words “at least” and “less than.” The record does not establish that the loss equals \$650, even though \$650 is shown as the lower endpoint.
Worked Example: An Incomplete Time-to-Loss Record
A hypothetical study follows insured devices from the start of coverage until the first covered breakdown or the end of follow-up. Device A has a breakdown observed 14 months after coverage began. Device B has no breakdown observed by the end of 9 months of follow-up. Device C has no usable follow-up information. Encode the records in months. Assume the study records an event at its observed time and that “no event by month 9” means no event has occurred at or before month 9. No distributional, interest, or mortality assumption is used.
Step 1: Device A. The event time was observed, so record an exact time \(T=14\) months, with compatible set \(\{14\}\).
Step 2: Device B. The event had not occurred by the end of month 9. Under the stated endpoint convention, its eventual event time must satisfy \(T>9\) months. Record a lower bound with strict inequality and compatible set \((9,\infty)\). Do not record \(T=9\) months.
Step 3: Device C. There is no usable follow-up duration and no event time. Mark the record missing or unavailable. It is not valid to assign \(T>0\) or any other bound without observed information supporting that statement.
Check. Device A has an exact event time; Device B has an observed duration but an unobserved event time; Device C has no usable time information. The three statuses preserve these distinct facts.
Common Exam Trap: Treating a Threshold as an Exact Loss
A frequent error is to replace a capped value by the cap amount and then treat it as an ordinary exact observation. Suppose the record says \(X\ge20{,}000\). The incorrect encoding is \(X=20{,}000\), with compatible set \(\{20{,}000\}\). That set excludes every possible value above \$20,000, even though the report allows them. The correction is to retain the status and inequality: \(X\ge20{,}000\), with compatible set \([20{,}000,\infty)\).
A related endpoint error is to change \(X\ge c\) into \(X>c\). The first includes \(c\), while the second excludes it. A reporting rule that caps values at \$20,000 and includes exact \$20,000 losses is consistent with \(X\ge20{,}000\), not \(X>20{,}000\). Conversely, a rule that says strictly “exceeds \$20,000” must be recorded with \(>\). Never choose the operator by habit; use the observation rule.
These distinctions matter because empirical summaries and later estimation methods depend on what was actually observed. Encoding a bound as exact can create false precision; encoding a missing record as bounded can create information that was never collected. A careful data record makes both errors easier to detect before calculations begin.
Check Your Understanding
For each hypothetical record, identify the appropriate status and write the compatible values. Keep each stated unit and endpoint convention.
- A claim is measured exactly at \$3,475. Encode it. (Answer: Exact, \(X=3{,}475\), compatible set \(\{3{,}475\}\).)
- A payment system reports “\$8,000 or more,” including exactly \$8,000. Encode the report. (Answer: Inclusive lower bound, \(X\ge8{,}000\), compatible set \([8{,}000,\infty)\).)
- A loss is reported as strictly greater than \$1,250. Is an exact loss of \$1,250 compatible? (Answer: \(X>1{,}250\), compatible set \((1{,}250,\infty)\); no, \$1,250 is excluded.)
- A record states \(400\le X<500\). Which of the exact values \$400, \$499, and \$500 are compatible? (Answer: \$400 and \$499 are compatible; \$500 is not.)
- A hypothetical warranty study observes no failure through 2.5 years, and its convention says a failure at 2.5 years would have been recorded. Encode the time-to-failure information. (Answer: \(T>2.5\) years, compatible set \((2.5,\infty)\); the failure time is not exactly 2.5 years.)