How should an environment represent when a correction happened and when it took effect?

A generated environment can distinguish `event_at`, `discovered_at`, `posted_at` and `effective_date`. These fields answer different questions: when the underlying activity occurred, when an error became known, when the correction was recorded and which reporting date it affects.

Link an adjustment to its source through `source_record_id`, and retain the original timestamps. A late discovery should not silently alter the recorded time at which the organisation first knew about the problem. Represent date-only reporting fields separately from timestamp fields, with timezone conventions documented in the schema.

Tool actions can include `read_record_as_known_at` and `read_position_for_effective_date`. The first reconstructs available knowledge; the second returns a position under the configured reporting rules. They need not return the same view.

Reset fixtures can restore a state before discovery or after posting. An evaluation hook can ask the agent to explain both views without conflating them. For model labs, this makes temporal reasoning a visible part of business competence, rather than an accidental consequence of whichever timestamp a model notices first.