A chronological split needs more than a sorted date column
Sorting samples by the day of a hypothetical decision is useful, but it does not establish that their inputs were available then. A row can describe September while carrying a value revised in October. An outcome can also extend beyond the point where a training set is supposed to have been frozen.
This worksheet asks for those dates separately before allocating eligible records. It deliberately does not accept prices, returns or accuracy scores. The useful result is a visible list of sample IDs, candidate periods and unresolved evidence. That list can be checked before a modelling pipeline turns the rows into an attractive statistic.
US vintage data separates observation history from knowledge history
The St. Louis Fed describes ALFRED as an archive of past versions of US economic data. Its real-time period describes when information was known, and the API uses calendar-date boundaries for that period. Retrieving today’s version of an old observation is therefore a different task from recovering the version available on a past day.
The help page also explains that release-date provenance can come from the original source, a provider or, when those dates cannot be determined, first availability in FRED. A date field does not by itself authenticate an intraday availability instant. Keep that provenance with your feature record rather than inventing a midnight release time.
Sources: Federal Reserve Bank of St. Louis — ALFRED Help, Federal Reserve Bank of St. Louis — FRED API Real-Time Periods.
Record four dates for each proposed decision
The decision date assigns the sample to a candidate period. The feature-known date describes when the actual feature version was available. The outcome-end date says when the horizon being evaluated finished. The label-known date says when the resulting outcome was available for training or retrospective evaluation.
These dates can differ without any error. A result measured over several days may become available later still. The worksheet rejects an outcome end before its decision or an outcome availability before its end because those entries contradict the declared event order. Missing dates stay missing; the tool does not repair them from adjacent rows.
Use one explicit fitting boundary
The fitting date is the start of a new calendar day for this policy. Training candidates have decision dates strictly before it, and both their outcome-end and outcome-known dates must also be strictly earlier. This prevents an apparently old decision from donating an outcome that reaches into the fitting boundary or later.
The test period has an inclusive first and last decision day. If the first test day follows the fitting date, the intervening days form a declared gap. A sample in that gap remains excluded even if its evidence is otherwise complete. This is a date partition, not a promise that samples are independent or equally spaced.
Do not promote same-day availability into prior knowledge
For every training or test candidate, feature availability must be on an earlier calendar day than the decision. Equality stays unresolved: the feature might have appeared before or after the hypothetical decision within that day. The tool does not choose whichever interpretation makes more rows eligible.
This is a deliberately conservative policy for day-level records, not a claim that same-day features can never be used. A different study could support intraday ordering with precise, independently established timestamps and a different validator. Here, a date-only ALFRED field cannot supply those missing hours and minutes.
The seven-row example keeps each exclusion visible
With a fitting date of 1 October, A has its feature on an earlier day and its outcome known before fitting, so it qualifies for the training candidate set. B fails the earlier-day feature rule. C began before fitting but its outcome ends on 2 October and becomes known on 3 October, so it cannot be used by the declared training cutoff.
D is a gap row. E belongs to the 5–10 October test window and has complete date evidence by the report’s 20 October endpoint. F has no feature-known date, while G has no outcome-known date or saved outcome reference. Only A and E pass their respective date gates; the five other rows are still exported.
| ID | Candidate allocation | Result |
|---|---|---|
| A | Training | Eligible date evidence |
| B | Training | Same-day feature unresolved |
| C | Training | Outcome crosses fitting boundary |
| D | Gap | Excluded by partition |
| E | Test | Eligible date evidence |
| F | Test | Feature date unknown |
| G | Test | Outcome evidence unknown |
Keep the library concept separate from this worksheet
The official scikit-learn TimeSeriesSplit documentation explains why ordinary splitting methods can train on future data and evaluate on the past. It provides ordered folds and an optional gap counted in samples. It also states an equal-spacing condition for comparing fold metrics over equal durations.
This worksheet is not a reimplementation of that class. It applies one user-chosen date boundary, a calendar gap and availability checks to a small evidence table. It does not generate folds, choose a favourable cutoff or assert equal spacing. If you later compare models, preserve the split definition instead of changing it after seeing their results.
Passing the date checks does not establish a clean strategy
The tool does not inspect how features were constructed. A rolling statistic could still include future observations, a normalisation step could use the full dataset, or repeated samples could share an outcome. A row passing this date policy does not rule out those other forms of leakage or dependence.
Neither does the tool verify the feature values or outcome values, since it does not collect them. The absence of a date problem is not predictive accuracy, profitability or permission to treat a back-test as observed account performance. Use the report to resolve concrete availability gaps before making any such evaluation.
Carry the assumptions with the sample list
The CSV records the fitting date, inclusive test endpoints, report endpoint and every sample’s dates, references, allocation and issues. Input order is preserved, and duplicate sample IDs are rejected. Formula-like reference text is escaped for spreadsheet export. Editing the form makes its old export unavailable until the report is recalculated.
No FRED key, account login, dataset upload or network request is used. The seven-row example remains readable without JavaScript. Once the evidence review is complete, the optional link leads to this site’s separate English-language crypto signals and Telegram updates offer; access to that offer is not required for the worksheet.
Worked examples
Example 1
With fitting date 1 October 2026 and test window 5–10 October, fictional A is training-eligible and E is test-eligible under the declared date policy. B is withheld because its feature became available on the decision day; C is withheld because its outcome crosses the fitting boundary. D falls in the excluded calendar gap. F lacks a feature-availability day; G lacks outcome-availability evidence. Counts: 1 training eligible, 2 training withheld, 1 test eligible, 2 test withheld, 1 gap, 0 outside. No model or performance result is produced.
Inspect example inputs
{
"fit_date": "2026-10-01",
"test_start_date": "2026-10-05",
"test_end_date": "2026-10-10",
"as_of_date": "2026-10-20",
"rows": "id|decision_date|feature_known_date|outcome_end_date|label_known_date|feature_reference|label_reference\nDEMO-A|2026-09-25|2026-09-24|2026-09-28|2026-09-29|DEMO feature A|DEMO outcome A\nDEMO-B|2026-09-28|2026-09-28|2026-09-29|2026-09-30|DEMO feature B|DEMO outcome B\nDEMO-C|2026-09-29|2026-09-28|2026-10-02|2026-10-03|DEMO feature C|DEMO outcome C\nDEMO-D|2026-10-02|2026-10-01|2026-10-05|2026-10-06|DEMO feature D|DEMO outcome D\nDEMO-E|2026-10-05|2026-10-02|2026-10-07|2026-10-08|DEMO feature E|DEMO outcome E\nDEMO-F|2026-10-06||2026-10-08|2026-10-09|DEMO feature F|DEMO outcome F\nDEMO-G|2026-10-07|2026-10-06|2026-10-09||DEMO feature G|"
}Questions about the method
Why withhold a feature released on the same day?
A date does not establish whether it was known before that day’s decision. This worksheet uses an explicit earlier-day policy and leaves same-day ordering unresolved.
Does a gap count trading sessions?
No. It excludes decision dates between two calendar boundaries. It neither counts sessions nor reproduces a library sample-count gap.
Does an eligible row prove there is no data leakage?
No. Feature construction, repeated samples, value provenance and model fitting remain outside this date-evidence check.
Primary sources and scope
- Federal Reserve Bank of St. Louis — ALFRED HelpChecked 2026-10-21. US economic-data vintages preserve versions reported in the past. Release-date provenance can use source, provider or first FRED availability when original dates are unavailable; this is not an exact intraday timestamp.
- Federal Reserve Bank of St. Louis — FRED API Real-Time PeriodsChecked 2026-10-21. Real-time periods describe information availability; API boundaries are inclusive YYYY-MM-DD dates, distinct from the worksheet’s own exclusive fitting policy.
- scikit-learn — TimeSeriesSplit documentationChecked 2026-10-21. Ordered time-series splits avoid future-training/past-evaluation ordering; library gap counts samples, and comparable-duration fold metrics assume equally spaced samples. This tool does not implement that library.
Examples explain a method. They do not predict prices or establish where a trading service is available. Check the named source before relying on future schedules.