| # LEAKAGE_RULES.md | |
| These rules apply to every project using temporal data, prediction, simulation, backtesting, ranking or historical evaluation. | |
| ## Recommended Columns | |
| - `source_published_at` | |
| - `source_ingested_at` | |
| - `available_at` | |
| - `prediction_time` | |
| - `target_time` | |
| - `source_url` | |
| - `source_name` | |
| ## Central Rule | |
| `available_at <= prediction_time` | |
| If a feature was not available at prediction time, it must not be used. | |
| ## Prohibitions | |
| - No future information in prediction features. | |
| - No labels inside prediction features. | |
| - No survivorship bias. | |
| - No look-ahead bias. | |
| - No backtest without walk-forward or time-aware validation. | |
| - No random split when temporal order matters. | |
| - No corrected historical data without recording when the correction became available. | |
| ## Trading-Agent Example | |
| A news article can affect a prediction only if: | |
| - `source_published_at` is known. | |
| - `source_ingested_at` is known. | |
| - `available_at` is computed. | |
| - `available_at <= prediction_time`. | |
| - The target return is stored separately from features. | |
| Backtests must be walk-forward and must not rebalance using future prices, future constituents or future news. | |
| ## Immobilier-Predictif Example | |
| Urbanism permits, demographics and transaction data can affect a prediction only if they were available before `prediction_time`. | |
| Do not use final sale price, future renovation, later zoning decisions or post-event news as features for earlier predictions. | |