Why Decision-Time Information Matters
A prediction is useful only if it can be made using information the decision-maker could actually access at the time. A field in a historical data set may look like a strong predictor because it was recorded near the outcome. But if it was created after the decision—or after the outcome—it could not have helped make the original decision. Using it in a model can produce an artificially persuasive assessment of predictive performance.
The key distinction is between when a fact was true and when the fact was available. A payment might be made before a decision but posted to the system afterward. An event might occur after a decision but be backdated in a later report. Prediction inputs must reflect what could be known at decision time, not merely what a completed data extract eventually contains.
The earlier material on setting the prediction time and specifying the forecast horizon establishes the decision timestamp and the period of interest. Here, the task is to classify facts against that timeline. A useful record may need at least two timestamps: an event time (when something happened) and an availability time (when the decision-maker could know it). A data warehouse’s extraction date is not automatically either one.
Build the Timeline Before Classifying Fields
Start with the decision timestamp \(t_0\), then mark the beginning and end of the outcome period. For each candidate field or event, ask: What does it describe? When did the described event happen? When did the information become available? Could the intended decision-maker access it at \(t_0\)?
An interval’s endpoint convention matters. For example, events strictly after \(t_0\) and strictly before \(t_1\) belong to the open interval \((t_0,t_1)\). An event exactly at \(t_1\) is excluded. If the intended rule instead includes that instant, use a right-closed interval and state that explicitly. The endpoint rule must match the business definition; it should not be guessed from a database query.
Use a precise date, time, and time zone where those details could affect availability or event eligibility.
Write its start and end, including whether events at either endpoint count.
Compare its event time and availability time with \(t_0\). A pre-decision event that was not yet available is not decision-time information.
Use a historical, as-of view of the information set, and keep later outcomes separate from the predictors.
Why Future Information Creates Leakage
A prediction rule at time \(t_0\) must be a function of the information available then. In general terms, write the prediction as \(\hat{Y}=f(\mathcal{I}(t_0))\), where \(\mathcal{I}(t_0)\) denotes that information set. If a proposed input is added from a later date, the rule is no longer implementable at the original decision time.
This is the basic justification for excluding future information: the prediction is supposed to be made from what is known then. A field generated after the outcome can reveal, directly or indirectly, what the model is meant to predict. Historical data may contain that field because records are updated as cases develop, but its later presence does not make it a legitimate earlier input. This is commonly called target leakage.
The same reasoning applies to a field that describes an earlier event but was reported late. If a report arriving after \(t_0\) is used as though it had been available at \(t_0\), the reconstruction gives the decision-maker knowledge they did not have. A model’s apparent accuracy can then reflect hindsight rather than a usable predictive signal.
Worked Example: Defining an Urgent-Support Outcome Window
A hypothetical service team makes a case-prioritization decision at 9:00 a.m. on April 1, 2026. The intended outcome is an urgent support request occurring after that decision and before May 1, 2026. Classify five requests timestamped at March 31, 4:00 p.m.; April 1, 9:00 a.m.; April 15, noon; April 30, 11:59:59 p.m.; and May 1, midnight. Also decide whether a balance update posted at 8:52 a.m. and a message received at 9:03 a.m. can be inputs.
Method. Write the target interval first. “After the decision” excludes the decision instant, and “before May 1” excludes midnight at the start of May 1. Therefore the eligible interval is \((\text{April 1, 9:00 a.m.},\text{May 1, 12:00 a.m.})\).
Classify the requests. March 31 at 4:00 p.m. is before the interval. April 1 at exactly 9:00 a.m. is at the excluded lower endpoint. April 15 at noon is inside the interval. April 30 at 11:59:59 p.m. is also inside it. May 1 at midnight is at the excluded upper endpoint. Thus, of the five requests, exactly two meet the outcome definition.
Classify the candidate inputs. The balance update posted at 8:52 a.m. was available before the 9:00 a.m. decision, so it can be considered as an input, assuming it is otherwise appropriate. The message received at 9:03 a.m. was not available at decision time and cannot be an input, even if it concerns a circumstance that began earlier.
Check and common mistake. The two qualifying requests are both strictly later than 9:00 a.m. on April 1 and strictly earlier than midnight on May 1. Including the May 1 midnight request would contradict “before May 1”: midnight is the instant May 1 begins. The correction is to use the open upper endpoint shown above, not a right-closed interval.
Availability Is Not the Same as Event Time
Operational systems often make the distinction less obvious than the example above. Consider a payment made shortly before a decision but posted shortly afterward. The event time says the customer paid before the decision; the posting time says the decision-maker did not yet know about it. For a model intended to reproduce that decision, the payment cannot be treated as known unless the system had another accessible record of it by \(t_0\).
The reverse can also happen. A report may be entered today with an event date from last week. If the report was not available last week, using its content to predict a decision made last week introduces hindsight. A later data extract might show the backdated event, so event dates alone are not enough to reconstruct the information set.
Worked Example: A Hypothetical Policy Review
A hypothetical insurer reviews a policy at 4:00 p.m. on January 10. It has specified an outcome period of 30 days after the decision, ending at 4:00 p.m. on February 9, with events at that exact ending instant excluded. Review these records: (1) policy status refreshed at 3:55 p.m. on January 10; (2) a payment made at 3:50 p.m. but posted at 4:07 p.m.; (3) an accident at 11:30 p.m. on January 9, reported at 4:04 p.m. on January 10; (4) a claim reported at 3:59 p.m. on February 9; and (5) a claim reported at exactly 4:00 p.m. on February 9.
Method. The decision time is January 10 at 4:00 p.m. The specified outcome interval is \((\text{January 10, 4:00 p.m.},\text{February 9, 4:00 p.m.})\). The records are evaluated using the stated timestamps, rather than by whether they seem generally close to the decision or outcome.
Classify the records. The policy-status refresh at 3:55 p.m. occurred before the decision and was available before it, so it can be an input. The payment happened at 3:50 p.m., but its posting time is 4:07 p.m.; on the facts given, it was not available at 4:00 p.m. and must be excluded as an input. The accident happened before the decision, but its report arrived at 4:04 p.m.; the report’s contents were not available at decision time, so they must also be excluded as inputs.
The claim reported at 3:59 p.m. on February 9 is after the January decision and before the specified ending instant, so it is inside the outcome period. The claim reported at exactly 4:00 p.m. is at the excluded upper endpoint, so it is outside that period. There are two usable conclusions: one of the five records is an eligible input, and one of the two claims falls within the outcome period.
Check and common mistake. A frequent error is to treat the payment and accident as inputs solely because their event dates precede the decision. The relevant question is whether their information was accessible by 4:00 p.m. The posting and report times show that it was not. Separately, the endpoint rule excludes the claim exactly at 4:00 p.m. on February 9.
Reconstructing Historical Inputs
A practical data audit should preserve enough history to answer “what could the user have known then?” A current customer record may overwrite a previous status; a claim reserve may change as an investigation progresses; an equipment record may acquire a repair code after a failure. If only the latest values are retained, it may be impossible to recreate the information available at an earlier decision.
When records have multiple dates, document what each timestamp means. Useful distinctions include the time an event occurred, the time it was entered, the time it became visible to the relevant user, and the time a later extract was created. If a system makes updates visible only after a scheduled refresh, the relevant availability time may be the refresh time rather than the entry time.
The intended user matters too. A field might be available to a central analytics team but not to the person making the decision. The information set should reflect the actual decision process, not the maximum information technically stored somewhere in the organization. When availability cannot be established, do not silently assume the field was known; flag the limitation and investigate or exclude it.
Worked Example: Daily Equipment-Risk Decisions
A hypothetical maintenance team makes an equipment-risk decision at 6:00 a.m. each day and uses information available by then. The outcome period is the next seven days, excluding an event exactly seven days after the decision. At a particular decision time, the candidate records are: (1) a temperature reading measured at 5:50 a.m. and visible at 5:56 a.m.; (2) a vibration reading measured at 5:58 a.m. but uploaded at 6:04 a.m.; (3) service history for a repair completed the prior day and entered at 5:40 a.m.; (4) a work-order closure code entered two days after a failure; and (5) a daily maximum temperature calculated at midnight after the decision. A failure occurs exactly seven days after the decision.
Method. Compare each field’s availability time with 6:00 a.m. The temperature reading was available four minutes before the decision, and the service history was entered twenty minutes before it. Both can be considered inputs. The vibration reading was uploaded four minutes after the decision, so it was unavailable then. The work-order closure code was entered after the failure, and the daily maximum was calculated later that day; neither belongs in the decision-time information set.
There are five candidate records, of which two are available inputs and three are unavailable or future-derived records. The failure at exactly seven days is at the excluded endpoint, so it does not fall inside the specified outcome period. The fact that it is an important equipment event does not override the stated boundary rule.
Check and common mistake. It would be wrong to include the vibration reading because it was measured before 6:00 a.m.; it was not uploaded until afterward. It would also be wrong to label the failure as inside the outcome period when the rule excludes an event exactly seven days later. The classification follows the availability and endpoint rules, not the apparent relevance of each record.
Common Traps and a Practical Checklist
The main risk is allowing a completed record to stand in for the information that existed at the decision. Before using a field, ask whether it is a snapshot or a value that can be revised later. Check for post-decision updates, delayed feeds, backdated entries, and summaries calculated using a period that extends beyond \(t_0\). A value that incorporates even part of the future is not a clean decision-time input.
- Using event time alone. A pre-decision event may not have been reported or visible until later.
- Using availability time alone. A field visible before \(t_0\) may still summarize future information if it was calculated using later records.
- Ignoring endpoint conventions. “Before a date” usually excludes the instant that date begins; state the interval explicitly to avoid disagreement.
- Confusing an extract with a historical snapshot. A value in today’s extract may reflect updates made after the original decision.
- Assuming access is universal. Confirm that the intended decision-maker—not merely some system or analyst—could use the field.
A reliable specification records the decision timestamp, time zone, outcome-period endpoints, field definitions, and the rule used to determine availability. This makes the prediction task reproducible and helps distinguish a genuinely useful input from information that only appears predictive because it arrived later.
Check Your Understanding
For each scenario, identify what belongs to the decision-time information set or outcome period, and apply the stated endpoint rule.
- A hypothetical claims team decides at 2:00 p.m. on June 3. A document is signed at 1:55 p.m. but uploaded at 2:06 p.m. Can the decision-time model use its contents? (Answer: No; it was not available until after 2:00 p.m.)
- A decision is made at 8:00 a.m. on August 12. The target period is strictly after that time and before 8:00 a.m. on August 19. Does an event at 7:59 a.m. on August 19 count? Does one at exactly 8:00 a.m.? (Answer: The 7:59 a.m. event counts; the event at exactly 8:00 a.m. does not.)
- A hypothetical account review is made at noon. A balance was last refreshed at 11:45 a.m.; a debit occurred at 11:50 a.m. and posted at 12:10 p.m. Which balance information can be treated as known at noon, given no other data source? (Answer: The 11:45 a.m. refreshed balance; the debit was not yet available.)
- A maintenance decision is made at 6:30 a.m. A sensor value is recorded at 6:25 a.m. and made visible at 6:28 a.m.; a summary covering the full calendar day is calculated at 11:00 p.m. Which can be an input? (Answer: The sensor value can; the full-day summary cannot.)
- A hypothetical service decision occurs at 9:00 a.m. on October 1. An event at 8:50 a.m. is reported at 9:20 a.m.; another event occurs at 9:20 a.m. and is reported immediately. Which report can be treated as a predictor, and which event is potentially a future outcome? (Answer: Neither report is a decision-time input; the first event was not reported until later, and the second event occurs after the decision and may be an outcome if it falls within the specified horizon.)