title: Point-in-time and as-of queries description: What we knew on a date, not merely what is true now. The concept that makes a backtest trustworthy.

Every resource accepts an optional asOf parameter. It answers a specific question:

What did this system know on that date?

That is a strictly different question from "what was true on that date", and the difference is the single most common way a backtest lies to you.

The problem: lookahead bias

A backtest has lookahead bias when it makes a decision using information that did not exist at the moment of the decision. It is rarely deliberate. It is usually a database that silently overwrote yesterday's answer with today's.

Consider a stock split that took effect in March but was only detected and ingested in June.

• A database that stores only "what is true now" will apply that split to March's prices, because the split is a fact and facts get backfilled.
• Your March backtest then trades on adjusted prices that nobody could have seen in March.
• The strategy looks better than it was. You find out with real money.

The same mechanism applies to restated fundamentals, revised earnings dates, reclassified instruments, and reused tickers.

How the guarantee works

The schema separates two timestamps that most systems collapse into one:

| Column | Meaning | |---|---| | effective_date | when the event took effect in the market | | created_at | when this system learned of the event |

An asOf read filters on created_at, never on effective_date. A corporate action ingested after your asOf date is invisible to that read, even though its effective date is earlier. That is the whole mechanism, and it is why the March split above cannot leak into a March query.

effective_date is still yours to filter on. It is an orthogonal concern: use from and to to bound the window of events you care about, and asOf to bound what was knowable.

Seeing it work

Run the same query twice with different asOf values. If a restatement landed between the two dates, the answers differ.

curl -H "Authorization: Bearer $PULSE_SANDBOX_KEY" \
  "https://markets.pulseline.io/v1/instruments/{id}/corporate-actions?asOf=2026-03-01"

curl -H "Authorization: Bearer $PULSE_SANDBOX_KEY" \
  "https://markets.pulseline.io/v1/instruments/{id}/corporate-actions?asOf=2026-07-01"

The second response may contain an action the first does not. Both are correct. The first is what your March strategy was entitled to see.

Reproducibility: actionSetVersion

Price responses carry meta.actionSetVersion, the version of the corporate action set used to adjust them. Record it alongside your results. Re-requesting the same instrument, window and version returns the same numbers even after a later restatement changes the current answer, which is what makes a published backtest auditable rather than merely repeatable in spirit.

Honest scope of the guarantee

This matters more than the marketing, so it is stated plainly.

The point-in-time guarantee is strongest going forward from our own ingest. created_at records when this system learned a fact, so it is exact for every fact we ingested ourselves, and the guarantee has been in force since ingest began.

For history predating our own ingest, created_at reflects when we backfilled the record, not when the wider market first learned it. That means deep historical as-of reads are not equivalent to a true vendor point-in-time archive. Achieving that for older history requires a data source that itself retains the original knowledge timestamps, which is a subscription we do not currently hold.

We would rather tell you the boundary than let you discover it inside a backtest. If you need certified point-in-time depth over decades, ask us before you build on this, and we will tell you honestly whether we cover your window.

Practical guidance

• Backtests: set asOf to the simulated decision date, and step it forward with your loop. Never leave it unset.
• Live trading: leave asOf unset. You want the current best answer.
• Research you intend to publish: record both asOf and actionSetVersion so a reviewer can reproduce your numbers exactly.
• Reconciliation: when a number changed under you, query both asOf dates and diff. The API can always tell you when it learned something.