What criteria should an application use to finalize Twilio messages that remain in the 'sent' state?

Goal: Determine a reliable point at which an application can consider a Twilio outbound message that remains in the 'sent' state as finally processed, given that no carrier delivery receipt may ever arrive.

Constraints: Twilio treats 'sent' as a non‑terminal state; delivery receipts are optional and vary by carrier and country. Status callbacks may be delayed, retried, or arrive out of order, and there is no built‑in job that automatically finalizes stuck 'sent' records. Any decision must therefore be based on a business‑defined reconciliation window, idempotent handling of callbacks, and optional polling of the Message resource.

Should the application treat 'sent' as final after a configurable timeout? Should it periodically poll the Messages API for updates until a terminal state appears? Should it rely solely on status callbacks and accept 'sent' as an indefinite but acceptable final state?