--- title: "Point-in-Time Data | Altss Glossary" description: "Point-in-time data is data that can be reproduced exactly as it was known on a past date, including values later corrected and entities that later…" canonical: "https://altss.com/glossary/point-in-time-data" --- Glossary · Evidence & data # Point-in-Time Data Also called: PIT data · as-of data Point-in-time data is data that can be reproduced exactly as it was known on a past date, including values later corrected and entities that later disappeared, so that analysis of that date uses only information available then. Publisher: Altss LLCContent modified 2026-10-01 ALTSS-DATA-012 Backtests, benchmark studies and audits ask what was known at the time. A database that overwrites corrections and deletes defunct funds answers a different question: what we believe now about the past. Using it to judge a 2022 decision leaks later information into the test (look-ahead bias) and drops the funds and firms that did not survive (survivorship bias). ## Three views of the past A reconstruction chooses two dates: the date the facts are about (valid time, S) and the date of knowledge (transaction time, K). | View | S | K | Answers | | --- | --- | --- | --- | | Current | today | today | What is believed true now | | As-was | a past date | today | What is now believed to have been true then, including later corrections | | As-known | a past date | the same past date | What was recorded then, as it was recorded | Point-in-time data is the as-known view. It needs both axes of time: valid time for the facts and transaction time for the record, which is what [bitemporal data](https://altss.com/glossary/bitemporal-data) provides. The 2011 edition of the Structured Query Language (SQL) standard, SQL:2011, lets a query on a table that keeps both ask for the rows valid on one date as recorded in the database on another (FOR SYSTEM_TIME AS OF combined with a condition on the application-time period). ## Look-ahead bias Look-ahead bias is the use, in a historical analysis, of information that was not available at the date being analysed. Common causes in private markets: - **Reporting lag.** A fund's year-end NAV is reported in the following quarter. An analysis "as of 31 December" built later uses a NAV no investor had on 31 December. See NAV reference date. - **Restatements.** Corrected values replace the originals, so a backtest sees numbers that were never reported at the time. - **Late additions to datasets.** Funds that join a dataset bring their earlier history with them, which changes the past composition of a peer group, a form of reporting bias. See benchmark universe. - **Revised classifications.** A strategy label applied today to a fund that was classified differently when the decision was made. ## Survivorship in snapshots A list "as of" a past date must include the entities and relations valid on that date, including those that have since closed, merged or been wound down. Building it from today's active records drops them, and any average across the list is biased towards survivors. See survivorship bias. The same applies to people: the investment committee that approved a 2021 commitment is the 2021 committee, not today's. ## How point-in-time data is kept - **Append, never overwrite.** A change or a correction adds a version and closes the previous one; nothing is deleted. - **Record availability dates.** For each value, keep when it was received or published, not only the period it describes. - **Snapshots or versioned tables.** Periodic snapshots are simple but miss changes between snapshots and duplicate unchanged data. System-versioned tables keep every version with system-maintained time stamps, and SQL:2011 queries can ask for any past state (FOR SYSTEM_TIME AS OF, FROM ... TO, BETWEEN ... AND). - **State the view.** Every historical table or chart says whether it is current, as-was or as-known. ## How Altss applies this (Altss methodology) Altss methodology reconstructs any past state from the two dates S and K, and names the three views current, as-was and as-known. The as-known view is the one used for audits, for explaining past decisions and for backtests; the as-was view is used for history. Every reconstruction states which view it is, and a list as of a date includes entities that have since ceased. Each reconstructed claim version keeps the evidence origin, derivation status and validation status it carried when it was recorded; a validation status is read as of its validation date and does not carry forward to a later version. A content edit never moves the dates of the claims on a page. See the [Temporal Data & Freshness Methodology](https://altss.com/knowledge-center/frameworks/temporal-data-and-freshness-methodology). ## Worked example ### Illustrative NAV with three answers Fund X's NAV for 31 December 2022 is first reported on 15 March 2023 as 100. In 2024 the manager restates it to 92. - **As-known on 31 March 2023**: 100. That is what the LP's records showed. - **As-was, today**: 92. The best current knowledge about 31 December 2022. - **For a decision taken on 20 February 2023**: neither figure. The year-end NAV had not been reported, so the latest value available was the most recent NAV already reported, for example the 30 September 2022 figure. An analysis of the February 2023 decision that uses 92, or even 100, credits the decision-maker with information they did not have. Examples are illustrative; figures are not market data. ## Not the same as - [Bitemporal Data](https://altss.com/glossary/bitemporal-data): Bitemporal data is the storage model; point-in-time data is the capability it provides: reproducing what was known at a past date. - [Temporal Validity](https://altss.com/glossary/temporal-validity): Valid time alone answers what is now believed true at a past date (as-was), not what was known then (as-known). - Survivorship Bias: Survivorship bias is one error that point-in-time data prevents, by keeping entities that later disappeared. ## Common mistakes - Overwriting corrected values, so the originally reported figures cannot be recovered. - Backtesting on today's database and calling the result point-in-time. - Treating a reporting period's end date as the date the data became available. - Building historical peer groups from currently active funds only. - Mixing as-was and as-known figures in one table without saying which is which. ## Edge cases - A restatement published after an analysis: the analysis remains correct as-known, and a new as-was version can be produced alongside it. - Data deleted by the source: a captured copy keeps the as-known view possible. - Late-arriving data with a past effective date changes the as-was view but not earlier as-known views. - Knowledge dates need a time zone and a cut-off time when data arrives on the boundary day. ## Questions ### What is look-ahead bias? Using information in a historical analysis that was not available at the date being analysed, such as a NAV reported months after its reference date or a value restated later. ### Is a monthly snapshot point-in-time data? Partly. It reproduces what was held at each snapshot, but not changes between snapshots, and only if snapshots are never edited afterwards. ## Sources - [Temporal features in SQL:2011](https://doi.org/10.1145/2380776.2380786). Krishna Kulkarni; Jan-Eike Michels, ACM SIGMOD Record, Vol. 41(3), pp. 34-43. Status: Published (checked 2026-10-01). Sections 2.3 (system-versioned tables, AS OF / FROM ... TO / BETWEEN queries) and 2.4 (bitemporal queries) — supports: Querying past states and combining system-time and application-time conditions - [Developing Time-Oriented Database Applications in SQL](https://www2.cs.arizona.edu/~rts/tdbbook.pdf). Richard T. Snodgrass, Morgan Kaufmann, Morgan Kaufmann Series in Data Management Systems; ISBN 1-55860-436-7. Status: Out of print; author-hosted PDF (checked 2026-10-01). Sec. 1.1 (kinds of time); ch. 2, secs. 2.1-2.3 (valid-time, transaction-time and bitemporal tables) — supports: Valid time and transaction time are orthogonal; a table supporting both is bitemporal ## Related terms 4 terms - [Bitemporal Data](https://altss.com/glossary/bitemporal-data) - [Temporal Validity](https://altss.com/glossary/temporal-validity) - [Evidence Dates](https://altss.com/glossary/evidence-dates) - [Data Provenance](https://altss.com/glossary/data-provenance) ## Referenced by 1 term - [Data Freshness](https://altss.com/glossary/data-freshness) ## Concept record Concept ID ALTSS-DATA-012 Classification Evidence & data Topics Private markets data & OSINT · Performance & benchmarking Version 2.0.0 Last reviewed 2026-10-01 Structured data [JSON](https://altss.com/reference/concepts/point-in-time-data.json) ## Canonical URL https://altss.com/glossary/point-in-time-data