A Booking Reminder Regenerated Its Actual-Send-Time Map After Delivery: Recalculate the Notice Window

A regenerated actual-send-time map can change the notice-window result for a reminder that was already delivered. The safe response is a bounded reconciliation: identify delivered reminders whose corrected actual-send timestamp differs from the prior value while every identity and content field remains fixed.

Do not treat a delivery receipt as proof that the reminder met the approved notice window. It establishes a delivery event in the provider's lifecycle. The notice calculation still depends on the timestamp selected as the actual send.

• Start from delivered reminders only.
• Compare old and new actual-send timestamps in one timezone-normalized format.
• Hold fixed the booking ID, reminder ID, recipient set, content hash, locale, and delivery receipt ID.
• Route only out-of-window results to a controlled confirmation queue.

Which delivered reminders belong in the reconciliation set?

Include a reminder when its delivery status is unchanged, its receipt still maps to the same reminder, and the regenerated map produces a different actual-send timestamp. Exclude records where the booking changed, recipients changed, content changed, the locale changed, or the delivery receipt no longer matches. Those are separate data-integrity cases.

For SMS, Twilio's Message resource defines `dateSent` for an outgoing message as the time Twilio sent it. Its `delivered` status means Twilio received delivery confirmation from the upstream carrier and, where available, the destination handset. That is useful evidence for a timestamp reconciliation, but it does not replace your own approved notice-window rule.

For email, scope the receipt to the provider's definition. Twilio SendGrid documents a `delivered` event as successful delivery to the receiving server. Do not rewrite that event into a claim that a person saw the reminder.

How do you recalculate the notice window?

Use one formula for every row: meeting start timestamp minus actual-send timestamp. Calculate it once with the old map value and once with the regenerated map value. Apply the approved notice-window policy only to the corrected result.

The corrected timestamp decides the ruling. The old result is retained in the ledger as audit evidence, not as the basis for a new confirmation.

Normalize both timestamps before subtraction. Store the original timestamp and offset, the normalized calculation timestamp, and the booking's locale. A timezone conversion is a transformation to document, not a reason to overwrite the provider value.

• Read the meeting start from the booking record.
• Read the corrected actual-send timestamp from the regenerated map.
• Calculate the corrected notice window.

• Compare it with the approved window.
• Write the ruling before any attendee-facing action.

When should an attendee receive a controlled confirmation?

Send one controlled confirmation when the corrected notice window falls outside the approved window and the attendee has not already received the same recovery action. The confirmation should identify the meeting time and offer a clear way to confirm, reschedule, or decline. It should not claim that the attendee read the original reminder.

Use a duplicate guard made from the booking ID, reminder ID, corrected ruling, and confirmation type. Record the confirmation message ID and timestamp in the same ledger. If the corrected record remains inside the approved window, close the row without sending anything.

Provider status transitions can continue after creation. Twilio's status-callback guide describes outbound messages moving through statuses after creation, including `sent`, `delivered`, `undelivered`, and, on supported channels, `read`. Reconciliation should preserve the receipt used for the decision rather than assume an earlier status is final.

What should the reviewer verify before closure?

The reviewer should be able to reproduce the ruling without opening an inbox or guessing which version of a timestamp is right. The ledger needs immutable identifiers, the two timestamp values, the calculation, the receipt, the duplicate guard, and the final closure.

For mobile push systems, delivery logs can also distinguish provider handoff from a broader recipient outcome. AWS SNS documentation describes delivery-status logs as a way to determine delivery from SNS to the push notification service and to inspect dwell time before handoff. Keep that channel boundary intact when reviewing push reminders.

A delivery receipt can be strong operational evidence without being absolute proof of recipient receipt. Vonage's delivery-receipt guide says delivery receipts can represent different stages and cannot be completely guaranteed as accurate across countries and providers. That is why the controlled confirmation is a recovery action, not a claim about what the attendee saw.

• Verify every fixed field still matches the original reminder.
• Verify the corrected timestamp has a traceable source.
• Verify the notice-window calculation uses the corrected value.
• Verify the duplicate guard before sending a confirmation.
• Record the reviewer and closure outcome.

How do you keep the next reconciliation small?

Save an immutable snapshot of the actual-send timestamp used for each prior ruling, then retain the regenerated value beside it. A future run only needs to inspect records where those values differ and the fixed fields still match.

Keep exception classes separate. A changed timestamp with fixed identity and content is a notice-window reconciliation. A changed recipient set, changed content hash, missing receipt, or changed booking is a different incident and needs its own review path.

Close the batch only after every affected row has a ruling and every required confirmation has either been sent once or explicitly suppressed by the duplicate guard.