How should an environment represent when a customer change takes effect?

A customer change needs more than a single update timestamp. An environment can distinguish `received_at`, when the request arrived; `recorded_at`, when the system stored it; and `effective_from`, when the new value should govern operations. An optional `effective_to` can close a period without deleting its history.

For a utilities account, a future correspondence change should not redirect a notice issued before the effective date. A backdated correction raises a different question: which historical views should reflect corrected knowledge, and which issued artefacts remain fixed?

MirrorFirm could generate dated value histories and operations that query them. An action such as `read_contact(account_id, effective_at, known_at)` makes the distinction between business time and recorded knowledge inspectable. An `advance_clock` action can expose a scheduled change becoming active.

JSONL events or Parquet history tables can carry these fields, provided their semantics are documented. Reset should restore both the clock and pending scheduled changes. Evaluation can then inspect the state before and after the boundary, rather than assuming that a final value proves the change happened at the correct time.