AI trading event time, publication time and ingestion time answer different questions: when something happened, when a source released a claim, and when your system received that specific version. A historical decision may use only the evidence available before its cutoff. Preserve article versions and local receipt records; an old publication date does not make a later correction available in the past.
An article can correctly describe yesterday's event while containing details added this morning. If a news backtest retrieves today's text and attaches yesterday's publication timestamp, its sentiment feature may know the outcome before the original reader did. The problem is the pairing of content and time.
Three timestamps, one decision cutoff
Choose a precise decision cutoff first. Then give each timestamp a defined meaning rather than assuming every field named “date” describes availability.
| Timestamp | Question it answers | What it does not establish |
|---|---|---|
| Event time | When did the reported occurrence happen, or when is it scheduled? | When anyone reported it |
| Publication time | When did this source first release the article or claim? | When your particular system obtained it |
| Ingestion time | When did your system capture this exact version? | When its extraction or summary became usable |
Source modification time belongs beside these fields as version metadata. Schema.org defines datePublished as first publication or broadcast, while dateModified describes the latest modification. Those definitions distinguish an article's original release from a later edit. They do not authenticate a publisher's timestamps or supply your local receipt log. An update marker can also reflect formatting or metadata rather than a new event; compare the retained versions before describing what changed.
Do not require event time to precede publication time. A maintenance announcement can be published before a scheduled outage. An investigation can also establish an event's true start time only afterward. The later discovery belongs to the later information set, even if the event occurred earlier.
This article concerns news and document versions. The market-data freshness guide separately checks observation age, feed continuity and completeness. A fresh quote cannot repair a news article that contains a future correction.
How an updated article leaks into an earlier decision
A real API illustrates why field names need inspection. Alpaca's news-stream schema includes an article ID, content, created_at and updated_at. Its definitions describe article creation and update dates. Neither field is your collector's ingestion time, and creation should not automatically be renamed first public availability without supporting provider semantics.
The following case is hypothetical. It describes no actual exchange, outage or trading result. Assume a fictional venue experiences an outage at 10:00 UTC. One article retains the same ID and original publication time through two versions.
| Captured version | Source release for this version, UTC | Local ingestion | Summary ready | Content available in that version |
|---|---|---|---|---|
| V1 | First publication: 10:04:00 | 10:04:18 | 10:04:24 | Outage began at 10:00; investigation continues |
| V2 | Update: 10:12:00 | 10:12:07 | 10:12:15 | Adds that service was restored at 10:11 |
At a 10:05 cutoff, this system has V1 and its summary. It cannot use the restoration claim. An archive downloaded later might present V2 alongside the unchanged 10:04 first-publication field. Joining only on that field would incorrectly put restoration into the 10:05 information set.
The missing delay is material even in this tiny example. V1 takes four minutes to be published after the outage and another 18 seconds to arrive. V2 arrives seven seconds after its update. Using V2 at 10:05 borrows raw information from 7 minutes and 7 seconds later.
Processing creates another boundary. At 10:12:10, V2's raw text is present, but the illustrated summary is still unavailable for five seconds. At 10:13, both are available. A replay of summary-driven decisions must respect summary readiness as well as receipt; it cannot move a completed output backward to its input timestamp.
These delays are teaching inputs, not recommended thresholds. They show why “the event already happened” and “the article already existed” are insufficient tests for a particular feature.
Preserve a version before extracting a feature
Treat the article ID as a continuing story and each captured payload as a separate observation. Keep the source identity, URL, ID, original publication field, update field, captured bytes, content fingerprint and local receipt time together. Preserve the source's field names and definitions alongside normalized fields. Define ingestion at complete payload receipt, rather than the start of a request that has not returned its contents.
Retain extraction and summary readiness separately, with their input version, configuration and output. If a summary depends on several documents, every material dependency needs an availability record. One eligible article cannot make a later corroborating document available sooner.
A fingerprint helps establish whether retained bytes differ; it does not prove the claim is true or show which version came first. Use a documented source revision identifier or update ordering when available. If that ordering is absent or contradictory, record the ambiguity instead of interpreting a hash as a revision number.
Append corrections rather than replacing V1 with V2. The earlier copy may contain a claim later shown to be wrong. Preserving it is necessary to reconstruct what the system saw, while present-day analysis should recognize its corrected status. Historical availability and factual accuracy remain separate questions; the news source-verification ledger addresses the latter.
Retain source material according to applicable access and retention terms. When only derived excerpts can be retained, document that limitation because a fingerprint alone cannot reconstruct the missing article body.
Build the as-of view from eligible versions
An as-of view answers: “What evidence could this recorded system use by cutoff D?” It should not mean “What does today's database say about events dated before D?”
For a replay of the recorded collector, first exclude versions received after D. Then apply the relevant processing boundary: if the decision consumes a summary, that summary must also have been ready by D. Select the applicable source revision among the remaining versions using its documented ordering.
Declare what a newly received revision does to older derived outputs. If V2 invalidates V1's summary on arrival, the feature is pending from 10:12:07 until 10:12:15; do not silently fall back to V1. This choice must match the recorded system behavior.
Do not simply select the last packet received. A reconnect can deliver an older version after a newer one. A repeated V1 message must not downgrade V2 merely because its local receipt timestamp is later. Preserve duplicates for delivery diagnosis while keeping version selection explicit.
At exact timestamp ties, use a declared ordering rule or captured sequence that establishes whether receipt and readiness preceded the decision. If the timestamp precision cannot resolve the order, classify that boundary as uncertain rather than assuming access.
Alpaca's news endpoint reference states that results are sorted by updated date. This is a concrete reason to inspect ordering instead of assuming publication order. The reference does not establish that an arbitrary historical query reconstructs every earlier article body. Obtain explicit version-history semantics before making that claim about any provider.
The broader look-ahead bias audit checks unavailable inputs throughout a strategy. Version selection is one specific input check; correct execution assumptions and model evaluation require their own evidence.
Validate the boundary with a delayed correction
Use the fictional two-version fixture before applying the method to a large archive. Freeze the cutoff at 10:05 and preserve the selected payload, feature inputs and recorded summary. Append V2 with its later receipt and readiness times, then reconstruct the same cutoff. The selected source should remain V1, and the earlier recorded output should remain unchanged.
Next move the cutoff forward. At 10:12:03, V2 is published but has not arrived locally. At 10:12:10, only its raw text has arrived. At 10:13, its summary is eligible. Check those three states separately rather than inspecting only a final trade count. Under a policy that invalidates old summaries, the middle state is pending rather than permission to reuse V1.
Finally, deliver a duplicate V1 after V2 and confirm that the declared revision order prevents a downgrade. Remove V2's receipt evidence and confirm that the replay reports an unknown boundary instead of silently substituting its event time.
A failure directs the investigation toward a join, overwritten payload or processing timestamp. Passing this fixture supports only the behavior exercised. It supplies no evidence of profitable signals or complete historical coverage.
For AI outputs, preserve the original response and model configuration where possible. Regenerating a summary today with a different model, current browsing or later training knowledge does not recreate the original information set merely because its supplied article has an old date. Label a reconstruction as a reconstruction.
Missing times require a narrower conclusion
A first local capture proves that your collector had those bytes by that capture time, subject to the reliability of its log. It does not establish the first moment the public could access them. Conversely, a publisher's timestamp cannot prove that your collector had already received them.
Keep unknown values explicit. A date without a timezone or time of day should not become midnight UTC by convenience. RFC 3339's timestamp format specifies an offset, including Z for UTC. Preserve the original representation while normalizing comparable instants, and record uncertainty when source precision or clock quality is insufficient. If a claimed update falls after its local receipt under the normalized clocks, inspect clock error and field meaning instead of quietly rewriting the discrepancy.
Where receipt history is missing, test declared publication-delay assumptions as scenarios. Report them as modeled availability. A conservative assumed delay can be useful, but it cannot recover an overwritten article or establish when a historical system received it.
Availability also grants no account authority. A research collector can have only the tool permissions needed to retrieve and inspect evidence. After a valid summary enters a queue, queued-signal expiry determines whether a later action still has a usable decision window.
Choose one historical summary and reconstruct its exact source version, receipt and readiness before its decision cutoff. If the archive cannot supply that record, narrow the historical claim before trusting the larger backtest.