Altss Temporal Data & Freshness Methodology

1. Purpose

Most errors about time in private-markets data come from one date being read as another. A page updated yesterday is taken to mean its facts were checked yesterday. A figure in a 2026 brochure is taken to be a 2026 figure when it was measured in 2023. A person is shown in a role because nobody recorded that they left. A backtest uses a classification that was only made later.

This methodology sets out how Altss records time for each claim so these errors cannot happen silently. It separates when something was true from when it was known, defines how a past state is reconstructed, makes freshness a property of each claim, and states the rule that editing content never implies that a fact was verified.

2. Scope

In scope

• Time attributes of claims, relations and roles about private-markets entities and events.
• The two time axes (valid time and transaction time) and point-in-time reconstruction.
• As-of statements on claims, lists and aggregates.
• Freshness, review horizons, decay and change detection.

Out of scope

• The definitions of individual date types, which are fixed in the Evidence & Provenance Standard (section 6.5), together with the evidence dimensions, including validation status and its validation date (sections 3.2 and 6.7). This methodology governs how the dates are used.
• Confidence labels and volatility classes, defined in the Source Reliability & Confidence Methodology. This methodology applies them to time.
• Time conventions inside financial calculations (day-count bases, IRR date conventions, vintage-year definitions), which belong to the performance and benchmarking publications.
• Any refresh schedule. No population-wide refresh cadence or universal verification deadline is established by this methodology.

3. Definitions

• Valid time. The period during which a fact is true in the world. Also called effective time or application time. See temporal validity.
• Transaction time. The period during which a given version of a claim is held in the record, from when it was recorded until it is superseded. Also called system time or recorded time.
• Bitemporal record. A record that carries both axes for every claim version. See bitemporal data.
• As-of date. The date at which a source states a value.
• Point-in-time reconstruction. Recreating the state of the record for a chosen valid time, as it was known at a chosen transaction time. See point-in-time data.
• First observed / last observed. The capture dates of the earliest and latest artefacts that state a claim.
• Age of evidence. The time between a claim's last observed date and the date of assessment.
• Freshness. Whether a claim's age of evidence is within its review horizon. A property of a claim, never of a page or a record. See data freshness.
• Review horizon. The period, set by an attribute's volatility class, within which a time-varying claim may be read as current without a recheck.
• Decay. Loss of support for reading a claim as current as its age of evidence grows. See Evidence Decay, an Altss-defined concept.
• Verification event (review). A deliberate check of stated claims against evidence, with a date, a scope and an outcome for each claim. A review that confirms a claim sets its validation status to RESEARCH_VALIDATED, with the review date as its validation date; that date is the claim's "entity verified" date (Evidence & Provenance Standard 6.7). See last verified.
• Validation date. The date on which a claim version's current validation status was assigned (Evidence & Provenance Standard 6.5 and 6.7).
• Change detection. Comparing successive captures of a source to find what changed between them. See change detection.
• Restatement. A source's replacement of a value it earlier gave for the same as-of date.

4. Inputs and source types

The inputs are the date fields that the Evidence & Provenance Standard requires each evidence item and claim to carry:

Sources differ in which dates they provide. Registry entries and filings usually give a filing date and often an as-of date; announcements give a publication date and sometimes an effective date; web pages often give no date at all.

5. Method

5.1 Two axes on every claim version. Each version of a claim carries a valid-time interval and a transaction-time interval. The valid-time interval says when the fact holds in the world. The transaction-time interval says when this version was the one held.

5.2 Valid time comes from evidence. Valid-time bounds are taken from dates the sources state: an effective date, a completion date, an as-of date. Where a source gives no effective date, the bound is recorded as unknown and the as-of or publication date is kept as a separate field. A capture, filing, publication or recorded date is never copied into a valid-time bound.

5.3 Intervals are explicit about what is unknown. Intervals are closed at the start and open at the end. An unknown bound is recorded as unknown, not left empty and not treated as open-ended. "Valid to: unknown" means no end has been observed; it does not mean the fact is still true. Whether the fact may be read as current is decided by its freshness (5.7).

5.4 Transaction time is append-only. When a claim changes, the new version is added and the old version's transaction interval is closed. Nothing is deleted or overwritten. A correction to a past value is recorded as a new version with the same valid time and a later transaction time. See audit trail.

5.5 Point-in-time reconstruction. Any past state is retrieved by choosing two dates: the valid time of interest (S) and the knowledge date (K). The reconstruction returns, for each claim, the version recorded on or before K and not superseded by K, whose valid interval covers S. Three views follow:

The as-known view is the one to use for audits, for explaining past decisions and for backtests. The as-was view is the one to use for history. Every reconstruction states which view it is.

5.6 As-of reporting. Every figure, list and aggregate states its as-of date and its view:

• a claim shows the as-of date or effective period of its value;
• a list "as of" a date includes the entities, relations and roles valid at that date, including entities that have since ceased, so the list is not distorted by survivorship;
• an aggregate (a count, a rate, a total) states when it was measured and the population it covers; that date applies to the aggregate only, not to each member.

5.7 Freshness belongs to the claim. For each claim read as current, the age of evidence is computed as the assessment date minus the last observed date. The claim is fresh if that age is within the review horizon for its attribute's volatility class. Freshness is never computed from a record's last-updated date or a page's modified date, and a record is never described as fresh as a whole.

5.8 A content edit never implies verification. Editing a page, changing its template, correcting a typo or adding a section changes the page-modified date and nothing else. No claim's observed, validation or as-of date moves, and no validation status changes, because a page was edited. A page date is shown as "page modified", never as "updated" or "verified" in a way that a reader could take as a statement about its facts.

5.9 Verification events are scoped. A review records its date, the claims it covered and its outcome for each:

• confirmed unchanged: the claim's validation status becomes RESEARCH_VALIDATED with the review date as its validation date (the "entity verified" date), and its last observed date moves to the capture date of the confirming evidence;
• changed: a new claim version is added under 5.4; it carries its own validation status, and the earlier version keeps the status and date it held;
• contradicted: another source asserts an incompatible value for the same as-of date or period, and the conflict pre-checks confirm it; the claim's validation status becomes CONFLICTING (Evidence & Provenance Standard 7.2);
• not found: recorded as negative evidence under the Evidence & Provenance Standard section 6.4; it does not end the claim's valid time and does not change its validation status;
• source unavailable: recorded; no date moves and the validation status is unchanged.

A review of some claims does not change the validation status or date of other claims on the same record. Where a claim has no validation date, its validation status is unknown: it is read neither as UNVERIFIED nor as validated.

5.10 No implied cadence. Refresh is source-specific. No date on a claim, record or page implies that other claims were refreshed on a schedule, and no population-wide refresh interval is implied by this methodology. The date attached to a claim is the statement; a reader checks that date.

5.11 Change detection brackets, it does not date. When successive captures of a source differ, the change is recorded as having occurred after the earlier capture and on or before the later one. That bracket is not the effective date. If a source later states the effective date, the claim takes it.

5.12 Decay applies to the current reading. Under the Source Reliability & Confidence Methodology, decay lowers support for reading a claim as current once its review horizon passes. It does not alter the dated claim or its validation status: "X held role Y as of D" keeps its support indefinitely.

6. Classification rules

6.1 Age and freshness.

• Age of evidence (days) = assessment date − last observed date.
• Fresh: age ≤ review horizon of the attribute's volatility class.
• Beyond horizon: the current reading is lowered one confidence step and flagged for recheck; the dated claim, its validation status and its validation date are unchanged.
• STATIC attributes (a founding date, a vintage year, a dated past event) have no horizon and never become stale.

6.2 Date precision is preserved. A date is stored and compared at the precision the source gives (year, quarter, month or day). A year-only date is not padded to 1 January or 31 December. Comparisons respect precision: "2019" and "30 June 2019" overlap; neither is before the other.

6.3 Periods and fiscal years. A value stated for a period (a fiscal year, a quarter) records the period, not just its end date. A fiscal year is recorded with its stated end date; it is not assumed to be the calendar year.

6.4 Scheduled facts. A claim whose effective date is in the future (an appointment effective next quarter, a fund term ending on a stated date) is recorded with that valid-from or valid-to date and is labelled scheduled until the date passes. It is not shown as current before then.

6.5 Time zones. Calendar dates are recorded as the source states them. Timestamps for captures and recorded dates are kept in UTC.

6.6 Repeated stale figures. A figure repeated unchanged in a later document keeps its original as-of date if that date can be established. If it cannot, its as-of date is unknown. The later document's date is never adopted as the figure's as-of date.

7. Conflict handling

7.1 Different dates for one event. Two sources giving different dates for "the same" event often describe different events: an announcement, a signing, a regulatory approval and a completion. Each is recorded as its own dated event before any conflict is declared.

7.2 A later as-of date is a new state, not a correction. Values with different as-of dates are successive points in a series. The later one does not overwrite the earlier one in valid time.

7.3 Restatements are corrections. A source that replaces its value for the same as-of date (an amended filing, a restated net asset value) creates a new version in transaction time. The as-known view before the restatement still returns the original value.

7.4 Genuine conflicts. Where two sources state different effective dates for the same event, both are kept, the claim's validation status is CONFLICTING (Evidence & Provenance Standard 7.2), and the conflict is resolved by a review under the Source Reliability & Confidence Methodology, in which the source authoritative for the event (usually the party that performed the act, or the register that recorded it) is preferred.

8. Confidence and limitations

• Captures are samples. A source captured in January and April says nothing about what it showed in February. Changes between captures are bracketed, not observed.
• First observed is not first true. A fact may have been true long before it was first observed.
• Disclosure lags are structural. Many filings are made weeks or months after the period or event they describe, and a form can report figures calculated at a date other than its filing date or the filer's fiscal year end. A Form D is a notice about an offering of securities, so its dates track the offering, not the fund's closings. The timing rules of each filing are stated on its concept page (for example Form ADV). Filing dates and as-of dates are both kept so that the lag is visible.
• Unknown bounds are common. Many claims have an unknown start, an unknown end or both. The method records that honestly rather than inventing dates.
• Reconstruction is bounded by what was recorded. An as-known view can only return what had been recorded by the knowledge date. Evidence captured later, even about earlier events, appears only in as-was views.
• Freshness is not accuracy, and not validation. A recently observed claim can be wrong, and an old static claim can be right. A claim can be fresh and UNVERIFIED, or RESEARCH_VALIDATED long ago and now beyond its review horizon.

9. Temporal rules

What every output states:

10. Edge cases

• Backdated effective dates. An announcement published in March of an appointment effective in January sets valid-from to January. The as-known view for February still shows the previous state, because nothing had been recorded.
• Future-dated departures. A departure announced in November, effective at year end, keeps the person in the role until that date; from the announcement the claim is labelled as ending on that date.
• Retroactive corrections by registers. A register that corrects an entry's historical date produces a new version in transaction time with the corrected valid time.
• Sources with no date. An undated page gives no as-of date. Its capture date gives an upper bound ("stated no later than"), recorded as such.
• Dissolved entities and closed funds. Their records end in valid time and remain retrievable; lists as of earlier dates include them.
• Changed fiscal year ends. A short transitional period is recorded as stated, not stretched to a full year.
• Recurring events. Annual commitments, re-ups or board meetings are separate dated events, not one event with many dates.
• Archive captures. A web-archive capture supplies a capture date for what the page showed at that time and can extend first-observed dates backward.

11. Worked examples

Example 1: one appointment, six dates (illustrative). An allocator announces on 15 February 2024 that a new chief investment officer will start on 1 March 2024. The announcement is captured on 16 February and the claim recorded on 17 February. A review on 10 January 2025 confirms it against the allocator's staff page, captured that day. The page displaying it is edited on 1 June 2025.

The page edit on 1 June 2025 says nothing about the appointment and changes no validation status. Between 17 February and 1 March 2024, the claim is scheduled, not current. From 17 February 2024 the claim's validation status was UNVERIFIED (one evidence item, no review); from 10 January 2025 it is RESEARCH_VALIDATED, dated 10 January 2025. That status says the claim was confirmed on that date. It does not say the person still holds the role, which is a question of freshness (5.7).

Example 2: a restatement in two axes. A fund's annual report, recorded on 1 April 2025, states a net asset value of $1.2 billion as of 31 December 2024. A restated report, recorded on 15 June 2025, states $1.1 billion for the same date.

As-known on 1 May 2025 returns $1.2 billion. As-was today returns $1.1 billion. Both are correct answers to different questions.

Example 3: freshness. A manager's head of investor relations was last observed on 10 April 2025. On an assessment date of 1 October 2026 the age of evidence is 539 days. Role claims are in the FAST volatility class; if 539 days exceeds the horizon set for that class, the claim "currently head of investor relations" is lowered one confidence step and flagged for recheck, while "head of investor relations as of 10 April 2025" is unchanged. A second person on the same record last observed on 20 July 2026 has an age of 73 days and is assessed on its own; the two claims do not share a freshness.

Example 4: a detected change. A team page captured on 15 January 2026 lists a partner; the capture on 15 April 2026 does not. The change is bracketed between the two dates. The partner's last observed date is 15 January 2026. No end date is set until a source states one.

Example 5: avoiding look-ahead in a backtest. An analyst studies allocators that committed to infrastructure funds in 2022. One allocator was reclassified from "corporate investor" to "single-family office" in 2024 after new evidence. An as-known view with K at the end of 2022 groups it as it was understood then; an as-was view groups it by today's understanding. A study of 2022 decisions made on 2022 information must use the as-known view and say so.

12. External references

• Temporal databases. Snodgrass (2000) defines valid time as when a fact was true in reality and transaction time as when it was stored in the database, and calls a table supporting both bitemporal. The SQL standard (ISO/IEC 9075) added application-time period tables (valid time) and system-versioned tables (transaction time) in SQL:2011, described by Kulkarni and Michels (2012), and carries them in SQL:2023. In that model a period is closed-open, and a current row's end is set to the highest value of the column's data type. This methodology uses the same two axes and closed-open intervals. It differs in recording an unknown bound as unknown rather than as an open end, and in adding observation dates and review horizons, which the SQL model does not define.
• ISO 8601. Dates, times and intervals are written in ISO 8601 form at the precision the source gives.
• W3C PROV-O. Record history (when a claim version was generated and superseded) corresponds to PROV-O generation and invalidation times; valid time in the world is outside PROV-O's scope and is carried separately, as the Evidence & Provenance Standard sets out.

13. Version and change log

• Version 1.2 (2026-10-01). Independent review. Section 8 no longer states filing deadlines and no longer says that Form ADV figures describe the prior fiscal year (regulatory assets are calculated shortly before filing); filing timing is left to the concept pages. Example 2 uses a restated fund report. The comparison with the SQL temporal model is stated from Kulkarni and Michels (2012).
• Version 1.1 (2026-10-01). Terminology aligned with the evidence dimensions of the Evidence & Provenance Standard version 1.1 (Altss methodology): "verification date" is now the validation date; "entity verified" is the validation date of a RESEARCH_VALIDATED status; review outcomes state their effect on validation status, including CONFLICTING for a contradiction; a claim without a validation date has an unknown validation status. No change to the time axes, the three views or the freshness rules.
• Version 1.0 (2026-10-01). First publication. Establishes the two time axes, append-only transaction time, point-in-time views, as-of reporting, claim-level freshness, scoped verification events, change-detection brackets, date precision and the rule that a content edit never implies fact verification.

Change control. Any change to the meaning of a time axis or of the three views is a major change. Changes to individual review horizons are made in the Source Reliability & Confidence Methodology and versioned there.

Concepts used

• Temporal Validity
• Bitemporal Data
• Point-in-Time Data
• Data Freshness
• Evidence Dates
• Last Verified
• Change Detection
• Evidence Decay
• Survivorship Bias
• Audit Trail

Sources

1. Developing Time-Oriented Database Applications in SQL. 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). Definitions of valid time, transaction time and bitemporal tables
2. Temporal features in SQL:2011. Krishna Kulkarni; Jan-Eike Michels, ACM SIGMOD Record, Vol. 41(3), pp. 34-43. Status: Published (checked 2026-10-01). Vol. 41(3), pp. 34-43, sections 2.1-2.4
3. ISO/IEC 9075-2:2023 Information technology - Database languages SQL - Part 2: Foundation (SQL/Foundation). ISO/IEC JTC 1/SC 32, ISO/IEC, Edition 6, June 2023 (SQL:2023). Status: Current (paywalled) (checked 2026-10-01). ISO/IEC 9075-2:2023 (SQL/Foundation), temporal tables
4. PROV-O: The PROV Ontology. Timothy Lebo; Satya Sahoo; Deborah McGuinness (eds.), W3C, W3C Recommendation, 30 April 2013. Status: Current Recommendation (checked 2026-10-01). generatedAtTime, invalidatedAtTime
5. Form D - Notice of Exempt Offering of Securities (form and instructions, paper version). U.S. Securities and Exchange Commission, SEC1972 (5/17); OMB No. 3235-0076, expires 2027-07-31. Status: in force (checked 2026-10-01). Form title and Item 13