Why a Binary Event Needs a Precise Definition
A binary prediction target records whether an event occurs: yes or no, often encoded as 1 or 0. That sounds simple, but “will this policy have a claim?” can mean several different things. Does a claim count when the loss occurs, when it is reported, or when it is paid? Does any claim count, or only claims of a particular type? Must the event happen within 30 days, within a policy year, or at any future time?
These choices determine what the model is being asked to predict. They also determine whether the available records support a reliable label. A well-defined target names the observational unit, the qualifying event, the time origin, and the outcome window. It specifies any relevant conditions, such as whether a claim must be covered, and states how events on the boundaries are treated.
The time origin \(t_0\) is the prediction time: the point at which the prediction would be made. A fixed horizon \(H\) is the length of time after \(t_0\) during which the event is sought. For example, “a covered water-damage incident at the insured property during the 90 days after the prediction date” is more precise than “a future claim.”
Specify the Event and Its Window
A useful event definition distinguishes the event itself from administrative steps surrounding it. For a claim, occurrence, notice, report, adjudication, and payment can happen on different dates. If the intended target is a loss occurring during the horizon, the occurrence date determines the label, even if the claim is reported later. If the intended target is a claim being reported during the horizon, the report date determines it instead. Neither convention is automatically right; the choice must match the intended prediction task.
The window also needs an explicit boundary rule. A common convention is the half-open interval \((t_0,t_0+H]\): an event exactly at the prediction time is excluded, and an event exactly at the horizon endpoint is included. Another convention could be used, but it must be stated and applied consistently. Without it, two analysts can assign different labels to the same record.
“Qualifying criteria” should be concrete enough to apply to individual records. They might specify an event type, a coverage status, a cause, or a threshold that is part of the event definition. Avoid terms such as “serious claim” or “significant lapse” unless they are defined with operational rules. Also distinguish a one-or-more-events target from a count target: for a binary target, one event and several events both receive a label of 1.
A Short Justification for the Binary Rule
The indicator rule follows directly from what “any qualifying event” means. If the count \(N_Q\) is zero, there was no qualifying event, so the indicator is 0. If the count is one or greater, at least one qualifying event occurred, so the indicator is 1. In particular, additional qualifying events do not increase this binary label.
For a prediction conditional on information available at \(t_0\), this also gives the following identity, provided the event definition and observation window are fixed and ascertainment is complete:
The last equality holds because “at least one” and “zero” are complementary outcomes for a nonnegative event count. The identity concerns the probability of any event; it does not say that the probability equals the expected number of events. It is also not a valid way to turn incomplete follow-up into a negative label: if the final part of the window is unobserved, the event count for the full window is not known.
Worked Examples
Worked Example: A Water-Damage Claim Window
A hypothetical insurer wants to identify policies that will have a covered water-damage incident in the 90 days after a prediction made at the start of January 1, 2026. Define the window as \((\text{Jan 1},\text{Apr 1}]\), so an incident on April 1 is included and one on January 1 is excluded. The qualifying event is the date of occurrence of a covered water-damage incident at the insured property. The claim record is complete for incidents in the window, including those reported after April 1. Assign labels for five policies.
Method. For each policy, first check that the event is covered water damage, then compare its occurrence date with the window. Do not substitute the report date for the occurrence date.
Policy A has a covered water incident occurring on January 1. The occurrence is at \(t_0\), which is outside \((t_0,t_0+90\text{ days}]\), so \(Y_A=0\).
Policy B has a covered water incident occurring on March 31. March 31 is after January 1 and before April 1, so the qualifying event is inside the window and \(Y_B=1\).
Policy C has a covered water incident occurring on April 2. This is after the April 1 endpoint, so it is outside the window and \(Y_C=0\).
Policy D has a covered water incident occurring on March 30 and reported on April 15. The occurrence date is in the window; the later report date does not change when the event occurred. Therefore, \(Y_D=1\).
Policy E has a theft claim occurring on March 15. It is inside the dates but does not meet the water-damage criterion, so \(Y_E=0\).
The labels in policy order are \((0,1,0,1,0)\). There are 2 positive labels out of 5, so the positive-label fraction in this small hypothetical set is \(2/5=0.4\). This fraction is simply a check on the assignments, not a claim about an actual portfolio. The common mistake avoided is to count every claim within the dates, or to use its report date without checking the event definition.
Worked Example: Defining a Nonpayment Lapse
A hypothetical insurer makes predictions at time \(t_0\) for whether a contract will lapse due to nonpayment during the next 60 days. Use the interval \((t_0,t_0+60\text{ days}]\). A qualifying lapse is the effective date on which coverage terminates for nonpayment; a warning notice is not itself a lapse. A customer-requested cancellation is not a qualifying event. Assign labels for five contracts using the recorded events below.
Method. Check the reason for termination and the effective termination date. The event must meet both the reason criterion and the time-window criterion.
Contract A terminates for nonpayment on day 60. The reason qualifies and the endpoint is included, so \(Y_A=1\).
Contract B is cancelled at the customer’s request on day 12. Although the date is in the window, the reason does not qualify, so \(Y_B=0\).
Contract C terminates for nonpayment on day 61. The event type qualifies, but it occurs after the endpoint, so \(Y_C=0\).
Contract D receives a nonpayment warning on day 30, and its coverage terminates for nonpayment on day 45. The warning is not the event; the effective termination is. Day 45 is in the window, so \(Y_D=1\).
Contract E remains active through day 60 with no nonpayment termination. The full window is observed and no qualifying event occurs, so \(Y_E=0\).
The labels are \((1,0,0,1,0)\), giving \(2\) positive labels out of \(5\). Counting Contract D as positive because it received a warning would happen to give the same result here, but for the wrong reason; it would also mislabel a contract whose warning was followed by payment and no termination. The correct rule uses the defined event and its effective date.
Worked Example: Incomplete Follow-Up and a Late Report
A hypothetical equipment insurer defines \(Y=1\) when a covered mechanical failure occurs in the 30 days after a prediction time, with the window \((t_0,t_0+30\text{ days}]\). The target uses the failure occurrence date, not the date the customer reports it. At the data extraction date, reports are considered complete through day 30 for three units, but follow-up for a fourth unit stops at day 20. Determine which labels can be assigned.
Method. Apply the event and date rules first, then check whether the full window is observed. Only a fully observed window with no qualifying event supports a label of 0.
Unit A has a covered failure on day 28, reported on day 42. The failure occurred within the window, so \(Y_A=1\). Its later report does not move the occurrence outside the window.
Unit B has no qualifying failure, and its records are complete through day 30. It has no event in the fully observed window, so \(Y_B=0\).
Unit C has no recorded failure by day 20, when follow-up ends. Days 21 through 30 are unobserved, so the full-window event count is unknown. Assign no binary label from these data; in particular, \(Y_C=0\) is not justified.
Unit D has a covered failure on day 31, reported on day 32, and complete observation through day 30. The occurrence is outside the window, so \(Y_D=0\).
Thus the assignable labels are \(1,0,\text{unresolved},0\): one positive and two negatives among three units with known outcomes. The unresolved unit must not be silently treated as a negative. The common mistake avoided is equating “no event recorded yet” with “no event during the entire horizon.”
Common Traps and a Practical Definition Checklist
A binary label is a rule applied to records, not merely a column containing zeros and ones. Before assigning it, write down the decisions that make the rule reproducible:
Specify which policy, person, account, or other unit receives one label, and the date or time at which its prediction is made.
State the event type and any required conditions, such as coverage or cause. Distinguish the event from notices, reports, decisions, or payments unless one of those administrative actions is itself the intended target.
Give the window length and say whether the start and endpoint are included. Apply that rule consistently to events on boundary dates.
Check that records can establish whether the event occurred throughout the full window. Mark incomplete outcomes unresolved rather than automatically assigning 0.
Several shortcuts produce systematically incorrect labels. “Any claim” can include events that do not meet the intended cause or coverage rule. Using a report date for an occurrence-based target can move events across the horizon boundary. Treating an event exactly at the start as in-window can contradict a stated \((t_0,t_0+H]\) convention. Finally, assigning 0 whenever a record contains no event can turn an observation gap into a false negative.
A concise, operational definition might read: “For each active contract at the prediction date, \(Y=1\) if at least one covered mechanical failure occurs after that date and on or before 30 days later; otherwise \(Y=0\) only when occurrence records are complete through day 30.” This makes the event, time origin, horizon, endpoint, and negative-label requirement explicit. Such precision is aligned with the SOA Exam PA (Predictive Analytics) syllabus because a prediction task cannot be evaluated consistently until its outcome is defined.
Check Your Understanding
For each problem, use the stated event definition and boundary rule. Treat any explicitly incomplete window as unresolved rather than negative.
- A hypothetical travel insurer predicts at \(t_0\) whether a covered baggage loss will occur in \((t_0,t_0+14\text{ days}]\). A covered loss occurs on day 14 and is reported on day 18. What is the label? (Answer: 1)
- A hypothetical insurer defines a lapse as coverage termination for nonpayment in \((t_0,t_0+45\text{ days}]\). One contract receives a warning on day 20, pays on day 25, and remains active through day 45. What is its label? (Answer: 0)
- A hypothetical warranty target is a covered repair event occurring in \((t_0,t_0+30\text{ days}]\). A repair occurs on day 31 and is reported on day 29. Records are complete through day 30. What is the label? (Answer: 0)
- A hypothetical policy target is any covered collision occurring in \((t_0,t_0+60\text{ days}]\). A covered collision occurs on day 12 and another on day 50, with complete observation. What is the binary label, and how many positive labels does this unit contribute? (Answer: 1; one positive label)
- A hypothetical account target is termination for nonpayment by day 90, using \((t_0,t_0+90\text{ days}]\). One account has no qualifying event recorded, but the data feed ends on day 72. What can be assigned? (Answer: unresolved; a 0 is not justified)