Outcome Horizons And Label Maturity

Why the Outcome Horizon Matters

A prediction needs a specific future period in which its outcome will be assessed. “Will this policy cancel?” is incomplete unless the analyst also specifies by when. A cancellation in the next 30 days and a cancellation in the next year are different targets, even when they concern the same policy and prediction date. The selected horizon should reflect the decision the prediction is intended to support.

A second issue is timing: the event may occur during the defined period, but the data needed to confirm it may arrive later. A record with no event shown in an incomplete data extract cannot automatically be labeled negative. The outcome period must have elapsed, and enough time must have passed for the relevant records to be reported and reconciled.

This is aligned with the SOA Exam PA (Predictive Analytics) syllabus. The focus here is the future period used to define the outcome and the timing needed to label it—not the choice of prediction method.

Define the Horizon and Its Boundaries

Let \(t_0\) be the prediction index date and let \(H\) be the outcome horizon, measured in a stated unit such as calendar days. For this tutorial, an event is counted if it occurs in the interval \((t_0,t_0+H]\): an event on the index date is excluded, while an event exactly at the horizon endpoint is included. This convention makes the boundary explicit. A different convention can be used if the business question requires it, but it must be stated and applied consistently.

The outcome event itself must also be defined precisely—for example, whether it is a submitted cancellation request or a completed cancellation. The horizon does not resolve ambiguity about what counts as the event. Nor does a long horizon make a poorly specified target precise.

Date arithmetic depends on the calendar and the chosen time unit. The examples below use calendar-day durations and explicitly state the year. For a 60-day horizon beginning January 10, 2025, the endpoint is March 11, 2025: January 11 through January 31 contributes 21 days, February contributes 28, and March 1 through March 11 contributes 11, for \(21+28+11=60\) days. The resulting event interval is \((\text{January 10},\text{March 11}]\).

When Is a Label Mature?

The horizon endpoint is not necessarily the date on which the data can support a final label. Suppose a qualifying event can take time to appear in the data source. Let \(L\) be a stated reporting or reconciliation allowance after the horizon endpoint, and let \(C\) be the latest date through which the data are considered reliable. Under the assumption that the data capture the specified outcome completely by the end of that allowance, a record is mature when the reliable-data cutoff reaches or passes the end of the allowance.

Here, \(L\) is a bound or operationally chosen allowance, not a guarantee that every imaginable data error has been eliminated. The maturity rule is defensible only if its assumptions are appropriate: the outcome source is sufficiently complete through \(C\), the allowance reflects the relevant reporting process, and the record was actually observable for the intended period. If data are not reliable through the cutoff, or the record was not under observation for the full horizon, the absence of an event does not establish a mature negative.

A verified event may sometimes establish a positive outcome before the full horizon has elapsed. However, if labels are intended to be comparable and final, a consistent maturity rule helps prevent differences in reporting delay from being mistaken for differences in outcome. The analyst should document whether early positives are accepted or whether every record must reach the common maturity date before labels are finalized.

Why the Maturity Rule Holds

The maturity date follows directly from what must be observed to label the entire horizon. Starting at the index date, first allow the full duration \(H\) for the event to occur. That reaches \(t_0+H\). Then allow up to \(L\) additional time for an event from that horizon to be recorded and reconciled. The latest expected completion date is therefore the horizon endpoint plus the allowance:

The logic is especially important for a negative label. To conclude that no qualifying event occurred in the whole interval, the analyst needs both the completed interval and sufficiently complete event reporting for that interval. Before then, “no event recorded so far” describes the extract, not necessarily the outcome.

Common Traps and Practical Checks

A horizon and maturity rule should be written down before labels are produced. That makes it possible to identify which records are eligible for final labeling at a particular data cutoff and to avoid silently mixing complete follow-up with incomplete follow-up.

• Using an ambiguous duration. “Next quarter” could mean a calendar quarter, three months, or a fixed number of days. State the duration and the unit.
• Leaving the boundary implicit. Specify whether an event on the index date counts and whether one on the endpoint counts. Here, the convention is \((t_0,t_0+H]\).
• Ignoring reporting delay. The horizon may have ended even though the data are not yet complete enough to trust a no-event label.
• Calling an immature record negative. An empty event field can mean “not reported yet.” Use an unresolved status until the maturity condition is met, rather than forcing a zero.
• Mixing time units. If \(H\) is in calendar days, do not calculate it as business days. If a real process uses business days, specify the calendar and holiday convention.

A useful audit is to select a few records near the cutoff and calculate their horizon endpoints and maturity dates by hand. Check that boundary events are treated consistently and that no record labeled negative lacks a complete, reliable observation period. These checks address label timing; they do not replace a precise definition of the event or an assessment of whether the records were observable.