Predictor Availability At Prediction Time

Why Predictor Availability Is a Design Decision

A historical database can contain a detailed account of what happened to a policy or claim. But a prediction is useful only if its inputs could have been known when the prediction would have been made. A claim event may have occurred before the prediction date, for example, while the insurer did not learn about it until afterward. Treating the event date as proof that its value was available would give a model information the actual decision-maker did not have.

The key question is therefore not simply, “Does this field exist in the data?” Ask: At the prediction index time, could the intended user or scoring system access this predictor value in the form being modeled? The answer depends on the business process and the source through which the value was made available, as well as on the event itself.

Definition: A predictor is available at the index time if its value was known, recorded in an accessible source, and usable by the intended decision process by the specified prediction cutoff. The index time is the time at which the prediction is intended to be made. A recorded event date, by itself, does not establish that the event or its value was known by then.

Availability is specific to the prediction task. A value visible to an adjuster in a claim system may not be available to an automated scoring service that reads only a policy database. Conversely, a historical warehouse may receive a field after the prediction date even though an underwriter could see the same value in an operational system at the time. A sound design describes whose information access is being represented.

A Practical Test for Each Predictor

For every candidate predictor, identify the value that would be scored and trace how it came to be available. At minimum, establish the index cutoff, the relevant source, the time the value was first usable there, and whether that source was accessible to the intended user or system. Use precise timestamps where the order of events within a day matters.

Fix the prediction cutoff.
State the index date and, when relevant, the exact time and time zone. “At renewal” or “at first notice” may be too vague if multiple updates happen that day.

Name the decision process and its sources.
Specify whether the intended predictor is available to an employee, an operational application, or an automated scoring service. They may have different access.

Trace the value’s availability.
Check when the underlying information was learned and when the relevant value became accessible through a source the decision process could use.

Classify the predictor and document uncertainty.
Include it only when its value was available under the stated process. Exclude it if availability followed the cutoff. If timestamps or access rules are unclear, mark the status unresolved rather than assuming inclusion.

This test can be expressed using an information set. Let $\mathcal{I}(t)$ denote the information accessible to the specified prediction process by time $t$, and let $X_j$ be a candidate predictor. The value used for a prediction at index time $t_0$ must be determined by information in $\mathcal{I}(t_0)$.

X_j(t_0) \text{ is admissible only if its value is determined by } \mathcal{I}(t_0).

This is an availability condition, not a claim that the predictor is useful or appropriate in every other respect. It also does not require every source to store a literal “available at” timestamp. It requires a defensible account of what was actually accessible at the cutoff.

Worked Examples

Worked Example: Renewal Outreach With Different Source Access

A hypothetical insurer wants to score home policies for renewal outreach at 8:00 a.m. local time on July 1, 2025. The outreach scoring service reads the policy administration system and claims portal. It does not read the customer relationship management system or the overnight warehouse. Classify each candidate value using the stated cutoff and system access.

The records show:

Policy inception date: July 1, 2021; present in the policy administration system before the index time.
Current premium of $1,200: issued and visible in the policy administration system at 4:20 p.m. on June 30.
A claim with a loss date of June 27: first reported and visible in the claims portal at 9:15 a.m. on July 1.
Address change submitted at 6:00 p.m. on June 30: visible in the customer relationship management system then, but not delivered to the warehouse until 10:00 a.m. on July 1. The scoring service reads neither source.

Step 1: Set the cutoff. The prediction occurs at 8:00 a.m. on July 1. Information first available after that instant cannot be used for this prediction.

Step 2: Check the inception date. It was already present in a source the scoring service reads. It is available.

Step 3: Check the premium. The $1,200 value was visible in the policy system the previous afternoon, so it is available.

Step 4: Check the claim. The loss occurred before the cutoff, but the claim was not reported or visible in the accessible claims portal until 9:15 a.m. on July 1. The claim value is unavailable at 8:00 a.m.

Step 5: Check the address change. The customer had submitted it before the cutoff, but the scoring service had no access to the system displaying it. Its later appearance in a warehouse does not make it available to this scoring service at 8:00 a.m. It is unavailable for this specified process.

Result: The inception date and premium qualify; the claim and address change do not. The common mistake is to treat “event or submission happened before the cutoff” as equivalent to “the scoring process could use the value.” Availability requires both timely information and access through the specified process.

Worked Example: Claim Triage at First Notice

A hypothetical insurer assigns a triage score when a new auto claim first reaches its intake team. For one claim, the index time is 10:00 a.m. on March 12, 2025. The intake system stores the call details as they are entered. Determine whether each candidate value can be used at that index time.

The reported collision date is March 9. The caller provides it at 9:52 a.m. on March 12, and intake enters it at 9:56 a.m.
The caller reports an injury at 9:52 a.m., and the intake employee records it at 9:57 a.m.
A repair vendor uploads an estimate at 10:27 a.m.
An adjuster enters an initial reserve at 11:10 a.m.

Step 1: Establish what “at first notice” means here. The stated prediction is made at 10:00 a.m., after the call details have been entered but before later claim developments.

Step 2: Evaluate the collision date. Although the collision happened on March 9, the date was also reported and entered before 10:00 a.m. The entered value is available. Its eligibility follows from the intake record’s availability, not merely from the earlier collision date.

Step 3: Evaluate the injury indicator. The caller provided the information and intake entered it by 9:57 a.m. It is available at the cutoff, subject to the model using the value as recorded at that time rather than a later revision.

Step 4: Evaluate the estimate and reserve. The estimate arrived at 10:27 a.m. and the reserve was entered at 11:10 a.m.; both are after the prediction cutoff. Neither is available for the 10:00 a.m. prediction.

Result: The reported collision date and injury indicator are available; the repair estimate and initial reserve are not. The common mistake is to include all fields eventually present on the claim record. The correction is to recreate the claim’s state at the specified scoring time.

Worked Example: A File Timestamp Is Not a Scoring-System Timestamp

A hypothetical commercial insurer scores accounts at 5:00 p.m. on September 30, 2025. The scoring application reads a daily exposure file and a policy system. An exposure file is generated at 4:40 p.m., but the transfer finishes and the file becomes available to the scoring application at 5:20 p.m. The policy system contains an account’s current region, entered at 3:30 p.m. and visible to the application. The exposure file contains an updated site count of 8; the last site count available to the application before 5:00 p.m. is 6.

Step 1: Use the application’s cutoff. The relevant question is what the scoring application could read by 5:00 p.m., not when a file was created elsewhere.

Step 2: Evaluate region. The policy system value was entered at 3:30 p.m. and the application could access that system. The region value is available.

Step 3: Evaluate the updated site count. Although the file containing 8 sites was generated at 4:40 p.m., the application could not access it until 5:20 p.m. The value 8 is unavailable at the index time.

Step 4: Identify the usable site-count value. The prior value, 6, was the value accessible to the scoring application before 5:00 p.m. It is the available value for this historical prediction, assuming the prior record is still valid for the task’s specified definition of site count.

Result: Use the accessible region and the prior site count of 6, not the subsequently delivered value of 8. The common mistake is to use the file-generation timestamp as proof that the receiving system had the data. The correction is to verify when the intended scoring process could actually access it.

Why the Availability Condition Holds

A prediction made at time $t_0$ can be computed only from information accessible by that time. Suppose a candidate value is first learned or made accessible at time $t_1$, where $t_1 > t_0$. Then that value is not in the information available at $t_0$. Using it in a reconstruction of the earlier prediction gives the model information from the future relative to that decision.

t_1 > t_0 \quad\Longrightarrow\quad X_j \text{ first usable at } t_1 \text{ is not available in } \mathcal{I}(t_0).

This is why historical evaluation should reproduce the information state at the intended prediction time rather than simply select columns that happen to be present in a final, completed record. If a predictor was available to an employee but not to the production scoring system, its status depends on which process the model is meant to represent. State that process explicitly.

Common Availability Traps

Using event time as knowledge time. A loss may precede the index date, but it cannot inform the prediction if it was not yet reported or otherwise known to the intended process.
Assuming a database timestamp settles the question. A timestamp may describe when a record was entered, copied, or loaded. Check what it means and which system had access.
Using a completed record instead of its earlier state. Fields added after a decision, such as an estimate or reserve, may be present in the final record but unavailable at scoring time.
Ignoring the user or system. Information available to one employee or application is not automatically available to another.
Guessing when evidence is incomplete. If source access or timestamp meaning is uncertain, record the uncertainty and resolve it before treating the field as an eligible predictor.

An availability decision does not by itself establish that a variable is appropriate for every modeling purpose. It answers the narrower question of whether the specified process could have used that value at the index time. Clear answers make later model results more credible because they reflect a prediction that could actually have been made. This treatment is aligned with the SOA Exam PA (Predictive Analytics) syllabus.

Key takeaway: A predictor belongs in a prediction at index time $t_0$ only when its value was both available by $t_0$ and accessible to the decision process being represented. Event dates and database timestamps are evidence to investigate, not substitutes for that test.

Check Your Understanding

For each problem, use the stated prediction process and cutoff. Classify the value or values based on actual availability.

A hypothetical policy renewal score is run at 9:00 a.m. on May 1. The policy system shows a premium updated at 8:40 a.m. A storm loss occurred April 29 but was first reported May 1 at 9:12 a.m. Which value is available? (Answer: The updated premium is available; the storm loss is not.)
A claim score is made at 2:00 p.m. An injury was reported to intake at 1:45 p.m. but entered into the accessible claim system at 2:08 p.m. The score service reads only that claim system. Is the injury value available to the service at scoring time? (Answer: No; it was not in a source the service could access by 2:00 p.m.)
A hypothetical underwriting application scores an account at 4:30 p.m. A location count of 12 is visible in its policy system at 4:10 p.m.; a later file shows 14 locations but is delivered to the application at 4:45 p.m. Which count is available at the index time? (Answer: 12 is available; 14 is not.)
A customer submits a contact-preference change at 10:00 a.m. The prediction is at 10:20 a.m. A service representative can see the change immediately, but the automated model reads a batch warehouse that updates at noon. For an automated-model prediction, is the new preference available? (Answer: No; the model’s specified source does not expose it until noon.)
A hypothetical claim is scored at 11:00 a.m. The event occurred at 10:00 a.m.; the claimant reported it at 10:40 a.m.; the accessible intake system recorded it at 10:55 a.m.; an adjuster added a severity assessment at 11:30 a.m. Which of these two fields—the event indicator and adjuster assessment—can be used? (Answer: The recorded event indicator can be used; the adjuster assessment cannot.)

What You'll Learn