Which schema supports backdated and future-dated customer changes?

A generated temporal schema can distinguish when a change applies from when it becomes known to the system. Useful fields include `change_id`, `subject_id`, `attribute_name`, `valid_from`, `valid_to`, `recorded_at` and `supersedes_change_id`. The valid interval describes business effect; `recorded_at` describes entry into the record history.

In professional services, a customer supplies a purchase-order reference that applies from an earlier billing period. A generated release can retain the reference previously known during invoice preparation while also representing the later correction. This supports questions about both current state and historical knowledge.

Parquet tables can hold attribute history and change requests, linked through stable identifiers. Specify interval boundary conventions, timezone handling and the meaning of an absent end date. A loader should not have to guess whether two adjacent intervals overlap.

An environment can expose `get_state(effective_at, known_at)` to make both dimensions queryable. Resellers should preserve those dimensions through conversion and publish a small set of expected query results. Collapsing them into a single `updated_at` field would remove the backdating behaviour that downstream buyers licensed the material to study.