Mersal Before, Never After
A reminder that arrives late is not a reminder
A notice that fires the morning after a filing was due is a condolence, not a warning. It tells you what you already know: the window closed and no one was watching it. The purpose of a reminder is to change an outcome. A reminder that cannot change the outcome is documentation of a failure.
This sounds obvious. It is violated constantly. Many calendaring habits attach an alert to the deadline itself, so the signal and the event share a moment. By the time the signal sounds, the work that the signal was meant to prompt can no longer be done. The only defensible design places every warning in front of the date, with room to act.
Lead time is a property of the deadline class, not the deadline
How far in front depends on what kind of deadline it is. A limitation date and a routine filing do not deserve the same lead time. One is fatal and irreversible; the other is recoverable. Set lead times by class, once, and let every deadline inherit them.
Consider three broad classes and the questions that set their lead time:
| Deadline class | Consequence of a miss | Reasonable first warning |
|---|---|---|
| Limitation and prescription dates | Right extinguished, no cure | Weeks, then a rising cadence |
| Filing and procedural deadlines | Adverse ruling, possible relief | Days, escalating daily |
| Hearings and appearances | Default or wasted preparation | A week, then day-before |
The rule is simple: the graver and less reversible the consequence, the earlier the first warning and the steeper the escalation.
Escalation, and why the clock must be the server's
One warning is a single point of failure. A person is traveling, a notification is dismissed in a crowded inbox, a phone is silent in a hearing. So the warning should repeat and grow louder as the date approaches: an early quiet note, then firmer ones, then an insistent final prompt. Escalation is what survives a missed first signal.
None of this holds if the clock lives on someone's device. Local reminders drift, get muted, and die with the machine. The authoritative countdown has to run server side, in the deadline's own jurisdiction and each member's local time, indifferent to whether anyone opened an app. In Mersal, the docket computes hearings, filing deadlines and limitation dates in each member's local time and fires reminders before the event, escalating as it approaches, never after.
Set your lead times deliberately, by class, and let the graver deadlines shout earlier and louder than the routine ones. Audit them the way you audit anything that can end a matter: does every fatal date have a first warning far enough out to act, and a rising cadence behind it. A reminder is a promise about the future, and a promise you can only keep before the date is the only one worth making.
Matters, conflicts, VAT billing, sealed receipts and the docket, in one defensible system.