Core concepts
Understanding Arche requires understanding how financial data evolves over time.
Historical drift
Financial statements do not stay fixed forever.
They change because of:
- amended filings
- accounting corrections
- new disclosures
- vendor-side data revision pipelines
When a dataset exposes only the latest corrected state, the same historical query can return a different answer later.
Statement lineage
Arche keeps each SEC filing's statement as filed. When a later filing restates a period, the earlier filing's statement is kept alongside it rather than overwritten.
Axon's fiscal 2024 balance sheet, for example:
Filing (accession_id) | Event | Accepted at |
|---|---|---|
| 0001069183-25-000019 | Original 10-K | 2025-02-28T21:22:06Z |
| 0001069183-25-000075 | Restating 10-K/A | 2025-05-07T20:38:11Z |
That lets you ask both:
- what the latest filing reports for the period
- what was known on a specific historical date
Point-in-time retrieval
A point-in-time query returns the state that was knowable at the specified boundary.
A date includes every filing the SEC dated on or before it. EDGAR dates a filing accepted after
5:30 pm Eastern the next business day, so a filing made after the close is not known on the day it
was accepted. For a tighter cutoff, pass a timestamp with an offset, such as
2023-11-02T16:00:00-04:00: it includes every filing the SEC accepted at or before that instant.
GET /v1/edgar/as-of/2024-01-01/financials/0000320193
This is different from asking for the latest record today.
Point-in-time correctness is a retrieval property, not just a timestamp field. The request must constrain the historical boundary directly.
Deterministic research
Research is deterministic when the same request yields the same historical answer later.
That matters when you need to:
- reproduce a backtest
- audit an analyst workflow
- compare research runs across time
- explain why a company was included in a model at a historical point