Explore more topics
Strategy research methods

Spot a signal that knows the future

Follow one decision made before its input existed. Compare the early and corrected timelines, then ask Aurora to check the exact timestamps.

As of 2026-10-10

Jump to a section

A real filing arrived after its reporting period

Returned fieldRecorded result
CompanyApple Inc.
Form10-Q
Filing date2026-07-31
Period ended2026-06-27
Accession0000320193-26-000020

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.

JSON
{
  "action": "list_filings",
  "ticker": "AAPL",
  "limit": 1
}

Follow the minute that changes the decision

A chronological close, decision, order and fill timeline, with an early decision rejected
Illustrative timestamps from this guide. January 5 and 6, 2026 are shown in UTC. This diagram describes information ordering, not a recorded market fill.
Step 1 of 3

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.

What you should see

The timestamp check rejects this ordering with “Information was unavailable at decision time.”

Final close availability at 21:00 precedes a 21:01 decision and later eligible fill
Illustrative timestamps from this guide. January 5 and 6, 2026 are shown in UTC. This diagram describes information ordering, not a recorded market fill.
Step 2 of 3

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.

What you should see

This corrects the ordering in this example. A real audit must also check every input used by the signal.

Step 3 of 3

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.

What you should see

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.

Python
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.

JSON
{
  "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 closeCurrent incomplete session; prior completed closesEvaluate only the information your rule explicitly permits
Closing auction completesFinal close becomes knownCompute close-based signal after availability
Next eligible execution pointSignal already known; fill contract appliesExecute under declared next-fill rule

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 signal

Worked 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.

Training2016-01-01T05:00:00Z to 2021-10-03T03:59:59.999ZDevelop or fit candidates
Embargo2021-10-03T04:00:00Z to 2021-10-17T03:59:59.999ZExcluded gap between training and validation
Validation2021-10-17T04:00:00Z to 2023-03-30T03:59:59.999ZChoose a candidate before its outer test
Outer test2023-03-30T04:00:00Z to 2023-12-07T04:59:59.999ZEvaluate the frozen candidate

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.

Continue exploring

Discussion

Sign in or create a free account to join the discussion.

No comments yet.

Aurora · AI research assistant

Try this in Aurora

Edit the request, then open it in Aurora. You choose when to send it.