A real filing arrived after its reporting period
| Returned field | Recorded result |
|---|---|
| Company | Apple Inc. |
| Form | 10-Q |
| Filing date | 2026-07-31 |
| Period ended | 2026-06-27 |
| Accession | 0000320193-26-000020 |
No matching rows. Clear the filter to see all records.
The captured AAPL 10-Q listing ends its reporting period on 2026-06-27 and records filing on 2026-07-31, 34 calendar days later. Joining this report onto decisions at period end would place it before its recorded filing date.
Use a source's actual release or accepted timestamp for an exact intraday availability join. This returned filing date demonstrates the calendar mismatch; it supplies no measured strategy improvement from repairing it. The timestamp check below remains an explicit arithmetic test.
{
"action": "list_filings",
"ticker": "AAPL",
"limit": 1
}Follow the minute that changes the decision
Catch the early decision
The signal reads the final close at 20:59 UTC. That value becomes available at 21:00. The decision is one minute too early.
The timestamp check rejects this ordering with “Information was unavailable at decision time.”
Move the decision after the close
At 21:01 UTC, the same close is already available. Place the order after the decision and check which subsequent fill your strategy permits.
This corrects the ordering in this example. A real audit must also check every input used by the signal.
Check this timeline in Aurora
Open the prepared request in Aurora. It includes the example’s actual inputs, so you can ask about the part you want to check.
Review the explanation against the evidence on this page. Account changes and research jobs require a separate decision.
Run a concrete timestamp audit on an order decision
Inspect the timestamp audit and filing request
Export or retain the source availability time, decision time, order time and eligible fill time for an actual signal. Use the simple check below on those timestamps. The sample is deliberately invalid: the final close arrives after the proposed decision. It contains no price or performance observation.
Run the check once with the sample, then replace the timestamps with one actual order trace. A failed assertion identifies a violated information boundary. A passed row only checks that row; review operands such as indicators and filings as well as the final signal.
For filing-based research, list the actual filing metadata with sec_edgar using the JSON below. Keep the returned filing/acceptance time separate from the fiscal period. Do not call ingest_filings merely to demonstrate a read.
from datetime import datetime
def utc(value):
return datetime.fromisoformat(value.replace("Z", "+00:00"))
available = utc("2026-01-05T21:00:00Z")
decision = utc("2026-01-05T20:59:00Z")
order = utc("2026-01-05T20:59:30Z")
fill = utc("2026-01-06T14:30:00Z")
assert available <= decision <= order <= fill, "Information was unavailable at decision time"Read the source filing calendar
Inspect the timestamp audit and filing request
Submit this read request through your connected NexusTrade client. Check the returned filing dates before joining fundamentals into historical screening. It does not run a backtest or establish a point-in-time fundamentals series by itself.
{
"ticker": "GOOG",
"action": "list_filings",
"forms": [
"10-K",
"10-Q"
],
"limit": 5
}A timestamp on a row is not always its availability time
Read a timestamp on a row is not always its availability time
Lookahead bias occurs when a historical decision uses information that was not available when the decision could have been made. The date attached to a daily close, financial quarter or revised series may differ from the time that value became usable.
For a moving-average strategy, decide when the close and indicator become known and which subsequent fill is eligible. An engine can preload future rows for efficient evaluation; correctness still requires every condition and fill to respect its evaluation timestamp.
Worked example: close information versus executable order
Read worked example: close information versus executable order
This is a timing example, not a measured fill-price series. Buying at the same final close used to decide the order needs an explicit executable order protocol; knowing the closing value after the fact does not establish one.
Scroll sideways to compare all columns. Select a heading to sort.
| Before session close | Current incomplete session; prior completed closes | Evaluate only the information your rule explicitly permits |
| Closing auction completes | Final close becomes known | Compute close-based signal after availability |
| Next eligible execution point | Signal already known; fill contract applies | Execute under declared next-fill rule |
No matching rows. Clear the filter to see all records.
Reject a same-row join
Inspect the timestamp audit and filing request
Write the timestamps into your audit output. Shifting a column by one row is sufficient only if its actual availability and your fill protocol match that shift.
BAD: decision at t uses close(t) finalized after the order cutoff
CHECK: signal_available_at <= decision_at <= order_at <= eligible_fill_at
CHECK: every operand.available_at <= decision_at
CHECK: forward return belongs to the label, never the signalWorked example: financial period end versus filing availability
Read worked example: financial period end versus filing availability
A company quarter ending June 30 does not make the filed revenue available on June 30. A historical stock screen must use the filing release or acceptance time and the version available at that time. Joining all June-quarter values onto June 30 decisions leaks reports that arrived later.
Store period end, filed/accepted timestamp and any later amendment separately. At decision time, filter available_at <= decision_at before selecting the latest eligible record. Today’s revised fundamentals are not automatically the values a trader could have observed then.
The first fold's information boundary
Exact recorded date boundaries (advanced)
Scroll sideways to compare all columns. Select a heading to sort.
| Training | 2016-01-01T05:00:00Z to 2021-10-03T03:59:59.999Z | Develop or fit candidates |
| Embargo | 2021-10-03T04:00:00Z to 2021-10-17T03:59:59.999Z | Excluded gap between training and validation |
| Validation | 2021-10-17T04:00:00Z to 2023-03-30T03:59:59.999Z | Choose a candidate before its outer test |
| Outer test | 2023-03-30T04:00:00Z to 2023-12-07T04:59:59.999Z | Evaluate the frozen candidate |
No matching rows. Clear the filter to see all records.
Dates come from the actual plan. UTC boundaries reflect the generated market calendar; preserve them instead of hand-rounding an adjacent day into both windows.
An embargo does not repair every leak
Read an embargo does not repair every leak
The actual first GOOG fold has a 14-calendar-day gap between training and validation. A gap separates adjacent samples; it cannot make a future filing available earlier or turn a post-close signal into an executable pre-close order. Indicator warmup, label overlap, universe membership and revisions need their own checks.
Audit a few actual signals near date boundaries, then trace all operands and the selected fill. Compare the recorded rules with the engine’s evaluation interval. Daily indicators and daily backtest evaluation do not establish a broker’s deployment cadence.
Report what was verified
Read report what was verified
Retain signal timestamps, source availability timestamps, eligibility rules and fill assumptions with the result. If the source lacks historical availability or revisions, state that limitation. A chronological train/test split can still contain lookahead leakage inside either window.
No comments yet.