Bind the proposal to one rule and revision
Record the 40- or 64-character revision identifier, repository, source path, exact rule identifier or reviewed diff digest, recognized IANA time zone, boundary fixture, and human reviewer. State a parseable local date and time paired with that named zone, plus a valid UTC instant that the approved test will inspect. The receipt does not calculate a local-to-UTC mapping or prove a daylight-saving transition. Do not accept a label such as “fix DST” in place of a rule, fixture, and result. A revision-shaped value does not prove that it belongs to the repository; the reviewer must verify that separately.
RFC 5545 is a standard calendaring specification, and the IANA Time Zone Database publishes time-zone data and procedures. Neither source proves that a generated change matches your product policy, that a library has current data, or that a provider expands a recurrence as you intend.
Exercise the declared boundary
Use an approved non-production fixture at the boundary the change is meant to affect. A reviewer should be able to see the input zone, the named local expectation, the expected service observation, the code revision, and what a failed result means. Keep migration and compatibility questions explicit: a corrected rule may still need a decision about existing appointments.
The included checker makes a minimally complete receipt inspectable:
node --test sites/odexing.com/evidence/P137/scheduling-change-receipt.test.mjs
It does not parse a calendar file, calculate a daylight-saving transition, call an API, or approve a merge.
Keep reversal human-owned
Record the rollback owner and procedure, then the post-reversal fixture check. Stop if the changed rule, zone, boundary fixture, expected observation, reviewer, rollback owner, procedure, or post-reversal check is unknown.
For a pipeline change, see Gate an Agent-Generated CI Workflow Change Before Merge. For a non-code configuration boundary, see Gate an Agent-Generated Feature-Flag Change Before Merge.
Does recording one local and UTC expectation prove scheduling is correct?
No. It makes one review boundary explicit. Provider behavior, recurrence expansion, historical appointments, permissions, and production verification remain separate work.