Tutorials › Exam PA - Predictive Analytics › Aligning Predictor And Outcome Windows

Exam PA · Data Design and Study Structure · Tutorial 41 of 966

Aligning Predictor And Outcome Windows

Use a common index date and explicit interval boundaries to make predictor and outcome windows align without gaps or leakage.

Beginner 10 min read

What You'll Learn

  • Define predictor and outcome windows relative to a shared index date
  • Apply inclusive and exclusive boundaries consistently
  • Distinguish intentional gaps from accidental missing time
  • Detect overlapping windows that create leakage or ambiguous labels
  • Check whether a record has a clearly defined predictor and outcome status

Why Window Alignment Matters

A prediction record needs a clear reference time: the index date at which the prediction is meant to be made. Predictor information must describe an allowed period at or before that time; the outcome must describe a specified period after it. If those periods are not aligned, a record can silently include future information, count a past event as a future outcome, or leave part of the timeline unclassified.

The issue is not solved by stating that predictors use “recent history” and outcomes use “the next month.” Each window needs a start, an end, and a boundary rule. This tutorial uses continuous time for interval notation; when data are stored as dates, the analyst must translate the same rules into explicit timestamps or calendar-date conventions.

Definition: Let \(t_0\) be the index time, \(L\) the predictor lookback length, and \(H\) the outcome horizon length. A standard aligned design uses the predictor window \([t_0-L,t_0]\) and the outcome window \((t_0,t_0+H]\). The predictor window includes information through the index time if it is available then; the outcome window includes events strictly after the index time through the horizon endpoint.

The square bracket includes its endpoint; the parenthesis excludes its endpoint. Thus an event exactly at \(t_0\) is not a future outcome under this convention. A value measured at \(t_0\) may be a predictor only if it is genuinely available when the prediction is made. In practice, the availability rule matters as much as the measurement date: a value entered later cannot be treated as known at \(t_0\).

The intervals should be drawn on one timeline before records are assembled. This makes it easier to spot whether the lookback stops early, whether the outcome begins too soon, or whether the windows overlap. A deliberately chosen gap can be valid, but it must be part of the design rather than an unnoticed consequence of inconsistent dates.

A Timeline and Its Boundary Rules

For the standard convention, the timeline is:

$$ \underbrace{[t_0-L,\ t_0]}_{\text{predictor history}} \qquad \underbrace{(t_0,\ t_0+H]}_{\text{outcome horizon}} $$

The predictor window has length \(L\), and the outcome window has length \(H\). The two windows meet at the index time in the sense that the predictor may use information available at \(t_0\), while an outcome event must occur strictly later. They therefore do not share an event time. For a target defined as “any qualifying event in the horizon,” the binary outcome is 1 if at least one qualifying event occurs in \((t_0,t_0+H]\), and 0 otherwise, provided the full horizon can be observed.

This is one consistent convention, not the only possible business definition. A task could instead treat an event occurring on the index date as an outcome, but then the index-time rule must distinguish events before and after the actual prediction cutoff, typically using timestamps. Simply including the index date in both windows creates ambiguity.

Worked Example: Placing a 30-Day Claim Triage Record

Hypothetical scenario. A claims team wants to flag policies for review at day 100. It will use the prior 30 days of information and label whether a new qualifying claim occurs during the next 14 days. Assume all listed predictor measurements are available by day 100. Use the standard boundary convention and classify events at days 69.9, 70, 99.5, 100, 100.1, 114, and 114.1.

Method. Set \(t_0=100\), \(L=30\), and \(H=14\). The predictor window is \([100-30,100]=[70,100]\). The outcome window is \((100,100+14]=(100,114]\).

Predictor classification. Day 69.9 is before the lookback and is excluded. Day 70 is the included start of the lookback. Days 99.5 and 100 are within the predictor window; the day-100 value is usable only because the problem states it is available by the prediction time.

Outcome classification. Day 100 is excluded because the outcome begins strictly after the index time. Day 100.1 and day 114 are included. Day 114.1 is beyond the horizon and excluded. If the listed events are qualifying claim events, the outcome is \(Y=1\), because events at days 100.1 and 114 lie within the outcome window.

Check. The predictor window length is \(100-70=30\) days, and the outcome window length is \(114-100=14\) days. The shared boundary has not been counted as a future event. A common mistake is to write both windows as closed intervals and count a day-100 claim in the outcome; the correction is to specify which side of the index boundary includes the event.

Gaps: When Some Time Is in Neither Window

A gap exists when the predictor window ends before the outcome window begins, leaving an interval that belongs to neither. For example, suppose the predictor history is deliberately cut off \(g\) time units before the index:

$$ P=[t_0-L,\ t_0-g), \qquad O=(t_0,\ t_0+H], \qquad g>0. $$

The time from \(t_0-g\) to \(t_0\) is not represented by either window. This may be intentional: a design could exclude a recent period from the predictor definition, or a data rule could require a buffer. Whatever the reason, events and measurements in that interval must not be silently treated as either predictors or outcomes. A gap is not automatically a data error; an unexplained or inconsistently applied gap is.

Worked Example: Identifying an Intentional Five-Day Gap

Hypothetical scenario. An insurer scores policies at day 200 using 60 days of predictor history, but its design intentionally stops that history five days before the score time. It predicts a qualifying event during the following 30 days. Classify a measurement at day 194.9 and events at days 197, 200, 201, and 230.

Method. Here \(t_0=200\), \(L=60\), \(g=5\), and \(H=30\). The predictor window is \([200-60,200-5)=[140,195)\). The outcome window is \((200,200+30]=(200,230]\).

Predictor and gap. The measurement at day 194.9 is in \([140,195)\), so it is included. Day 195 is excluded from the predictor window. The gap has length \(200-195=5\) days: the interval from day 195 up to day 200 is in neither window. An event at day 197 is therefore neither a predictor-window event nor an outcome-window event under this design.

Outcome classification. An event at day 200 is excluded by the strict start of the outcome window. Day 201 is included, as is day 230, the included horizon endpoint. Therefore, if these are qualifying events, the target is positive because events at days 201 and 230 are in the outcome window.

Check. The lookback window runs from day 140 to day 195 and has length 55 days, not 60; the five-day buffer explains the difference. The outcome window is 30 days long. A common mistake is to call the predictor history “60 days ending at day 195,” which would imply a different start, day 135. The correction is to state whether \(L\) is the full lookback length or whether a buffer shortens the actual predictor window. Here it is the full span from \(t_0-L\) to \(t_0-g\), so its used duration is \(L-g=55\) days.

Overlaps: When a Record Becomes Ambiguous

An overlap occurs when predictor information includes time that is also inside the outcome period, or when a proposed outcome window reaches back before the prediction time. In the first case, the predictor can contain information about the event it is supposed to predict. This is a form of target leakage: the model appears to have predictive information that would not be available at the intended prediction time. In the second case, the target can label an event that happened before the prediction.

A quick alignment check compares the latest predictor time with the earliest outcome time. For the standard design, the latest allowed predictor time is \(t_0\), and the outcome begins strictly after \(t_0\). If a predictor window extends beyond \(t_0\), or an outcome includes times before \(t_0\), investigate the record definition before fitting a model.

Worked Example: Finding Leakage in a Rolling Claim Feature

Hypothetical scenario. A model is intended to predict a new claim during the 30 days after day 300. A rolling feature is mistakenly calculated from day 270 through day 302, while the label is based on claims from day 299 through day 330. An event occurs on day 301. Identify the problem and correct the windows using the standard boundary convention.

Method. The intended index time is \(t_0=300\), and the horizon length is \(H=30\). The feature interval \([270,302]\) includes days after the index. The stated label interval \([299,330]\) also includes days before the index.

Calculate the overlap. The intersection of the two stated intervals is \([299,302]\). Its duration is \(302-299=3\) days. The event on day 301 lies in both intervals, so it can contribute to the feature and to the label. The record does not represent a clean prediction made at day 300.

Correction. Under the standard convention, the 30-day outcome window is \((300,330]\). If the feature is meant to use 30 days of history, its window is \([270,300]\), subject to information being available by day 300. The overlap is now empty because every outcome time is strictly greater than 300, while no feature time is greater than 300. The day-301 claim remains an outcome event, but it must not enter the predictor feature. A day-300 event is not a future outcome under this rule; if it needs different treatment, define a timestamp-based cutoff rather than changing interval endpoints inconsistently.

Check. The corrected feature window has length \(300-270=30\) days, and the outcome window has length \(330-300=30\) days. The common mistake is to keep the feature’s day-302 endpoint because it was produced by a rolling calculation. The correction is to recompute or truncate the feature using only data available at the index time.

Why the Boundary Convention Works

The non-overlap result follows directly from the interval definitions. For the predictor window \([t_0-L,t_0]\), every time \(s\) satisfies \(s\leq t_0\). For the outcome window \((t_0,t_0+H]\), every time \(s\) satisfies \(s>t_0\). No time can satisfy both conditions, so the intersection is empty:

$$ [t_0-L,t_0]\cap(t_0,t_0+H]=\varnothing. $$

The strict inequality on the outcome side is what prevents the index time from being assigned to both periods. This justification also shows why changing the endpoint convention changes the result: if both intervals include \(t_0\), their intersection contains \(t_0\). For data recorded only by calendar date, choose a rule for what “at the index time” means and apply it to every record. When event and prediction timestamps are available, compare those timestamps directly.

A Practical Alignment Check

Before constructing labels or fitting a model, write the windows down for a typical record and check each boundary. A compact review is:

1
Fix the index time.
State when the prediction is made and what information is available at that time.
2
Write the predictor interval.
Give its start and end, including whether measurements at the index time are allowed.
3
Write the outcome interval.
Give the horizon endpoint and decide whether an event exactly at the index time counts.
4
Compare the intervals.
Identify any gap or overlap, then decide whether it is intended and consistently handled.
5
Test boundary cases.
Classify an event just before, exactly at, and just after each relevant boundary.

This check is important because ambiguous records can produce systematic rather than random errors. Leakage may inflate apparent predictive performance, while inconsistent endpoint rules can assign the same type of event differently across records. Clear windows make the target reproducible and make the intended prediction task easier to explain. This tutorial is aligned with the SOA Exam PA (Predictive Analytics) syllabus.

Key takeaway: Put the predictor window, the index time, and the outcome horizon on one timeline. State boundary inclusion explicitly, verify whether any interval is uncovered or shared, and resolve ambiguity before creating model records.

Check Your Understanding

For each hypothetical design, apply the stated endpoint convention and check the interval arithmetic.

  1. A model uses index day 500, a 45-day predictor lookback, and a 20-day outcome horizon. Write both standard windows. Does an event on day 500 or day 520 count as an outcome? (Answer: Predictor \([455,500]\); outcome \((500,520]\); day 500 does not count, and day 520 does.)
  2. A predictor window is \([50,77)\) and the outcome window is \((80,95]\). Find the gap length and classify an event on day 78 and an outcome event on day 94. (Answer: The gap is 3 days, from day 77 to day 80; day 78 belongs to neither window, while day 94 is in the outcome window.)
  3. At index day 1,000, a feature uses measurements in \([910,1004]\), and the target uses events in \((1000,1030]\). Find the overlapping interval and explain whether an event on day 1,002 can enter both. (Answer: The overlap is \((1000,1004]\), of length 4 days; day 1,002 can enter both, so the feature window must be corrected to stop at day 1,000.)
  4. A future-event label is mistakenly defined using \([t_0-2,t_0+10]\). Under the standard convention, which portion should be removed, and what is the corrected outcome interval? (Answer: Remove the two-day pre-index portion and exclude the index instant; the corrected interval is \((t_0,t_0+10]\).)
  5. A record has index day 240 and horizon length 25 days, but outcome data are available only through day 260. Is the complete outcome horizon observed, and how far short is the available data? (Answer: No; the horizon ends on day 265, so data are 5 days short.)
Clinical Biostats