Choose the decision timestamp
State when the model is expected to act: order submission, invoice receipt, renewal review, or month-end close. For every feature, ask whether it existed at that point. A later payment status can turn a difficult prediction into an easy retrospective lookup if it enters the input unnoticed.
Keep reporting and event time separate
Business systems often record when something happened, when it was entered, and when it was exported. Preserve those distinctions when available. A historical extract created today may contain corrections that were not known at the original decision date; describe whether the evaluation permits that hindsight.
Reserve complete future periods
Select training and evaluation windows that respect the intended deployment sequence. Consider recurring customers, seasonal cycles, and policy changes when choosing boundaries. Report which entities appear in both periods, because evaluating a familiar customer next month differs from evaluating an entirely new organization.
Document revisions and drift
Track category changes, reorganizations, currency conventions, and system migrations that affect comparisons across time. Define whether the model should handle these changes or whether they are outside scope. Send Fiund your prediction timestamp, target periods, and required history so source discussions can focus on usable temporal evidence. For a concrete leakage check, take one prediction example and list when each input field became available. Compare that list with the decision timestamp. A field populated after closure should be excluded or explicitly justified; its presence in a current database export does not mean it existed at the historical prediction point.
Review checklist
- Define the moment of prediction
- Separate event, entry, and export times
- Audit future information in inputs
- Document period and entity overlap