Time-Based Reminder¶
Scheduling tool — instantiates Cue-Triggered Intention Execution
Holds an intention dormant in a scheduler and surfaces it at a predetermined clock or calendar moment, with a rule for when it goes stale.
A Time-Based Reminder stores a deferred action in a scheduler and surfaces it at a predetermined moment on the clock or calendar. Its defining property is that the passage of time is the trigger: no condition need be watched, no event awaited, because a scheduled instant arrives on its own. You set a when, the intention sleeps until then, and time itself does the retrieving. This is precisely what distinguishes it from an event-based reminder: a time-based reminder fires on the clock whether or not the world is ready — it cannot know if the lab is back or the package has arrived; it only knows the appointed minute has come. Its natural companion is a staleness rule, because a purely timed cue can fire at a moment that has already passed its usefulness, and something must decide whether it re-nags, rolls over, or lapses.
Example¶
Someone renews their passport once a decade and will certainly have forgotten the deadline by the time it matters. There is no event that will announce "renew now" — the passport does not notify anyone; it simply expires. So the action is bound to a time instead of an event: a calendar reminder set for nine months before the expiry date, "Renew passport — processing takes 8 weeks." The intention is now offloaded entirely; it occupies no attention for years. When the scheduled date arrives, the reminder surfaces on its own, unprompted by anything in the world. If that morning is a bad time, a staleness rule governs what happens next — snooze a week, or, if the date has slipped past with no action, re-nag daily until closed rather than vanishing. Nothing was watched; the clock did all the work. This is the relief of cognitive offloading: handing a future intention to an external clock frees the mind from holding it.[n1]
How it works¶
- Name the moment. The trigger is a specific time or date (absolute, or relative to a known anchor like "9 months before expiry"), not a world condition.
- Store it dormant. The intention sleeps in the scheduler, out of working memory, until its moment — no rehearsal, no monitoring.
- Surface on schedule. The clock reaches the set time and the reminder fires unconditionally, because time arrives regardless of readiness.
- Apply the staleness rule. A snooze/expire/roll-over policy decides what happens to a reminder that fires at a bad moment or is left unacknowledged, so a timed cue doesn't silently lapse or nag forever.
Tuning parameters¶
- Lead time — how far ahead of the true deadline the reminder fires. Too early and it's dismissed and forgotten; too late and there's no time to act.
- Recurrence — one-shot versus repeating on an interval. Recurrence suits genuinely periodic actions but breeds habituation and dismiss-reflex.
- Snooze / expiry policy — whether a passed or ignored reminder re-nags, rolls forward, or lapses. Persistent re-nagging resists omission but risks alert fatigue; silent expiry keeps things clean but drops real intentions.
- Anchor type — a fixed calendar date versus an offset from an external date. Offsets stay correct when the anchor moves but require the anchor to be known.
When it helps, and when it misleads¶
Its strength is total simplicity and independence: it needs no monitor, no event source, and no watching, and it works precisely where there is no world-event to key on — deadlines, appointments, periodic obligations. Offloading the intention to a clock reliably relieves the mind of holding it and closes the intend-versus-remember gap for time-bound actions.
Its failure mode is the flip side of firing on the clock: it fires whether or not the moment is right. A timed reminder for "take out the trash Tuesday 7am" fires on the holiday when collection is cancelled; one set for "call back in 2 hours" fires whether or not the callee is now available. Timed cues are also more easily dismissed than event cues — the buzz arrives dislocated from any action context, easy to swipe away and forget. And a reminder set once, for years out, silently rots if the underlying deadline changes. The discipline is to prefer an event cue when a real event exists, tune lead time to actual action needs, and pair long-horizon reminders with a staleness rule so a stale timed cue is caught rather than trusted.
How it implements the components¶
Time-Based Reminder fills the store-it-and-fire-on-the-clock side of the machinery:
future_intention_payload— the reminder text names the deferred action to be surfaced, in terms actionable at the scheduled moment.latent_intention_store— the scheduler holds the intention dormant, out of working memory, until its time, offloading it entirely.expiry_and_staleness_rule— a snooze/expire/roll-over policy governs a reminder that fires late or is ignored, so a timed cue neither nags forever nor lapses silently.
It watches nothing and binds no world-event: the parallel_cue_monitor that watches a condition and the cue_action_binding that ties the action to an event's occurrence belong to Event-Based Reminder, whose trigger is the event itself rather than the clock.
Related¶
- Instantiates: Cue-Triggered Intention Execution — it supplies the time-cue variant, firing on a scheduled moment rather than a world event.
- Sibling mechanisms: Event-Based Reminder · Deferred-Action Checklist Marker · Missed Trigger Review · Environmental Prompt Placement · Callback Registration · Event Listener or Monitoring Daemon · Cue Disambiguation Test · Execution Acknowledgement Loop
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Time Based Reminder is defined in the frozen evidence as: Holds an intention dormant in a scheduler and surfaces it at a predetermined clock or calendar moment, with a rule for when it goes stale. Its operative deployed or enacted form is therefore Control, Automation & Runtime.
Nearest alternative: Interface, Display & Cue — Interface, Display & Cue can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: The defining operation is: Holds an intention dormant in a scheduler and surfaces it at a predetermined clock or calendar moment, with a rule for when it goes stale. In the human_computer_interaction lineage, that operation is specifically evidenced by authoritative or primary work that shows that explicit externally scheduled reminders improve execution of intentions tied to a future clock time. This makes human_computer_interaction the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins.
Related originating lineages:
- Computer Science & Software Engineering — Computer science and software-engineering practice supplies a parallel or contributing lineage for the mechanism's defining operation: holds an intention dormant in a scheduler and surfaces it at a predetermined clock or calendar moment, with a rule for when it goes stale.
- Organizational & Management Science — organizational_management supplies a historically relevant parallel or contributing practice for the defining operation—Holds an intention dormant in a scheduler and surfaces it at a predetermined clock or calendar moment, with a rule for when it goes stale—but the evidence does not make it the best primary lineage.
- Psychology — Experimental, clinical, and behavioral psychology supplies a parallel or contributing lineage for the mechanism's defining operation: holds an intention dormant in a scheduler and surfaces it at a predetermined clock or calendar moment, with a rule for when it goes stale.
- Systems Thinking & Cybernetics — Systems science's feedback, stock-flow, boundary, and regulation tradition provides a formative adjacent lineage for the same time based reminder operation.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus human_computer_interaction), so I adjudicated the mechanism rather than inheriting either label. The defining operation is: Holds an intention dormant in a scheduler and surfaces it at a predetermined clock or calendar moment, with a rule for when it goes stale. In the human_computer_interaction lineage, that operation is specifically evidenced by authoritative or primary work that shows that explicit externally scheduled reminders improve execution of intentions tied to a future clock time. This makes human_computer_interaction the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins. The cited Black & McBride, Effects of reminders on time-based prospective memory directly supports the mechanism-specific operation and its disciplinary lineage. I retain all independently explained historical alternates without a numeric cap. origin_mode=cross_disciplinary_synthesis records how the mechanism arose; domain_reach=universal separately records how broadly it can now be applied.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Cognitive offloading — using an external aid (a note, an alarm, a calendar) to hold information or an intention so the mind does not have to, studied by Risko and Gilbert among others. A time-based reminder is a paradigm case: the scheduler, not the person, keeps the future action, and the mental burden of remembering is discharged. ↩