Backtesting & Point-in-Time Integrity
Most financial data services answer one question: what happened? Ultralayer is built to also answer a harder one: what did you know, and when did you know it? That second question is the foundation of every honest backtest, every trustworthy agent evaluation, and every "replay the session" workflow — and it's why timestamps are treated as a first-class part of the platform's design rather than a metadata afterthought.
The clocks
Every record on the platform carries more than one timestamp, because "when did this happen?" genuinely has more than one answer. These are independent clocks — they are not a sequence. occurrence_timestamp can sit before, after, or well into the future of the other two.
When it happened (or will)
The estimated real-world time of the event itself — the earnings call, the strike, the resignation. Can be in the future for scheduled or announced events. Carried on developments.
When it was published
The time the source published the information — the publisher's clock, not ours.
When it was knowable
The time the record entered Ultralayer and became queryable. This is the clock that time filters and backtests run on.
A concrete example of the past-event case. A CEO resigns at 13:00 UTC (occurrence_timestamp). A newswire prints the story at 13:04 (source_timestamp). The item is processed onto the wire moments later (timestamp). If you replay a strategy against a window ending at 13:02, that resignation must not appear — nobody querying the platform at 13:02 could have seen it. Ultralayer enforces exactly that, because time filters run on timestamp, the knowledge clock.
Future occurrences are first-class too. A company announces earnings for next Thursday: the development is ingested now (timestamp / source_timestamp are today), while occurrence_timestamp is next Thursday. That means you can query for upcoming developments — scheduled earnings, product launches, policy decisions — not only what already printed. Example:
Code
Not every record carries all three clocks. Wire items and search results carry timestamp and source_timestamp; developments additionally carry occurrence_timestamp.
The guarantee
The point-in-time guarantee is simple to state: a query with end_timestamp = T returns only what was in the system at time T. Three design decisions make it hold:
timestamp is set once and never rewritten — including when the source later edits or republishes the underlying content.timestamp. Asking as-of a past time returns the version that existed then — not today's revised view. See as-of retrieval.Realtime and backtest are the same API
There is no separate "historical" product. Every time-aware endpoint runs in one of two modes, selected by end_timestamp:
end_timestamp | Mode | Behavior |
|---|---|---|
Omitted, null, or in the future | Realtime | No upper time bound — you get the live view |
| In the past | Backtest / as-of | Results clamped to what was knowable at that moment |
This symmetry is deliberate and it is the property that matters most in practice: the query you backtest is byte-for-byte the query you deploy. Change one parameter and yesterday's research becomes today's monitor. A few endpoints are realtime-only where an as-of version wouldn't be meaningful (for example entity retrieval); each capability page states which timestamps it accepts and what they filter on.
One practical note: some surfaces filter on timestamp but display or sort by source_timestamp (the Wire does this). When backtesting tight windows, prefer slightly wider bounds and read each capability page's timestamp semantics.
What this enables
- Strategy research without lookahead bias. Replay any window and see the exact information flow — headlines, developments, scores — available to a participant at each moment.
- Upcoming-event queries. Filter developments by future
occurrence_timestampto surface scheduled earnings, launches, and other known-ahead events for a ticker or theme. - Agent evaluation. Run an agent against a historical window and grade its conclusions against what actually followed, knowing it couldn't peek.
- Signal research. Test whether wire importance scores, sentiment shifts, or development impact scores at time T predicted anything at T+n — with the guarantee that the score you see at T is the score that existed at T.
- Reproducible analysis. An as-of query returns the same answer every time you run it. Analyses can be audited, shared, and re-derived.
See it in the capabilities
- Wire — backtest a window
- Semantic search — corpus as of a window
- Developments — as-of search and as-of retrieval
- Stakeholder identification — historical mode