Event-Based Reminder¶
Reminder tool — instantiates Cue-Triggered Intention Execution
Fires an alert the instant a specified real-world event or state-change occurs, delivering the bound action to whoever must act.
An Event-Based Reminder ties a deferred action to the occurrence of a specified event or state-change — not to a time. Something in the world flips (a result posts, a package is scanned, a value crosses a line), a monitor notices, and the reminder surfaces the bound action to the person who must act. Its defining property is that the trigger is contingent on the world, not on the clock: it fires whenever the event happens — this afternoon, next week, or never — because the cue is the event itself. That is precisely what distinguishes it from a time-based reminder, whose trigger is a scheduled moment that arrives on its own. An event-based reminder can fire early, late, or not at all, and it delivers the action to a human, which is what separates it from a daemon that would act on the event without ever surfacing it.
Example¶
A hospitalist is covering thirty patients and orders a potassium check on one whose level was borderline. She cannot productively hold "recheck Mr. Okonkwo's potassium" in mind for the four-to-six hours until the lab runs — she'll be in a dozen other rooms by then. So she sets an event-based reminder in the EHR: when a serum potassium result posts for this patient, page me with the follow-up. The intention now sleeps against a condition, not a time. Whenever the lab finishes — whether that's in three hours or seven — the result posts, the EHR's rule engine catches the state-change, and a page arrives carrying the bound action: "K+ resulted for Okonkwo — review and adjust replacement." She acts on it the moment the information exists, no earlier and no later. Had she instead set a timed reminder for "5 hours from now," it would have fired whether or not the lab was back — too early if the lab was slow, too late if it was fast. The event, not the clock, is what makes this fire at the right instant.
How it works¶
- Name the event as the cue. The trigger is a discriminable state-change with a precise condition — "K+ result posted," "shipment marked delivered," "queue depth > 500" — not a timestamp.
- Watch the condition in parallel. A monitor (a rules engine, a subscription, a sensor) evaluates the world continuously while the actor works, so no rehearsal is needed.
- Bind the action to the event. The alert carries the intended follow-up action tied to that specific event, so the right response surfaces with the cue rather than as a bare notification.
- Deliver to the actor. The reminder is routed to the human who holds execution authority, who then decides and acts.
Tuning parameters¶
- Condition tightness — how narrowly the triggering event is defined. Loose conditions fire on near-misses (false alarms); tight ones can miss legitimate variants of the event.
- Detection latency — how fast the monitor notices the state-change after it occurs. Lower latency means acting sooner, at the cost of more frequent evaluation.
- Payload richness — how much of the event's context the alert carries. Richer alerts let the actor respond without digging, but risk information overload.
- Routing and escalation — who is paged, and whether an unacknowledged alert re-routes. Broader routing catches misses but spreads alert load.
When it helps, and when it misleads¶
Its strength is that it fires when the world is actually ready, which a clock cannot know — the action lands the moment the enabling event exists, neither wastefully early nor dangerously late. This is the essence of event-based prospective memory: remembering to act when a particular event occurs rather than at a particular time.[n1]
Its failure mode is that it depends entirely on the monitor and the event's detectability: if the event is never emitted, or the condition is defined so it never quite matches, the reminder silently never fires and — because it was contingent — nothing flags the omission. Over-loose conditions flood the actor with false triggers until real ones are ignored, and an alert that arrives without enough context leaves the actor unsure what was intended. The discipline is to validate the event's detectability before relying on it, pair the reminder with a backstop sweep for events that should have fired but didn't, and keep the bound action explicit in the alert.
How it implements the components¶
Event-Based Reminder fills the watch-the-world-and-surface-it side of the machinery:
triggering_cue_specification— the trigger is defined as a discriminable real-world event or state-change with a precise firing condition.parallel_cue_monitor— a background monitor evaluates that condition continuously while the actor is occupied elsewhere, requiring no rehearsal.cue_action_binding— the alert carries the intended action bound to the event, so the right response is retrieved along with the cue and delivered to a person.
It does not fire on a schedule: the dormant-until-a-clock-moment latent_intention_store and the expiry_and_staleness_rule belong to Time-Based Reminder, whose trigger is time itself; nor does it gate and execute the action autonomously — that retrieval_and_execution_gate automation is the Event Listener or Monitoring Daemon's.
Related¶
- Instantiates: Cue-Triggered Intention Execution — it supplies the event-cue variant, firing on a world state-change rather than a time.
- Consumes: Cue Disambiguation Test validates that the chosen event is discriminable and timely before this reminder relies on it.
- Sibling mechanisms: Time-Based Reminder · Event Listener or Monitoring Daemon · Callback Registration · Environmental Prompt Placement · Deferred-Action Checklist Marker · Execution Acknowledgement Loop · Missed Trigger Review
Editorial Notes¶
Form Classification¶
Form family: Monitoring, Sensing & Alerting
Rationale: Event-Based Reminder operates as an ongoing sensing arrangement that repeatedly observes actual state and surfaces changes or alerts because it fires an alert the instant a specified real-world event or state-change occurs, delivering the bound action to whoever must act.
Independent corroboration: The frozen evidence defines Event-Based Reminder as 'Fires an alert the instant a specified real-world event or state-change occurs, delivering the bound action to whoever must act', so its operative form is Monitoring, Sensing & Alerting.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Psychology
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Prospective-memory research cohered event-based intentions in which a situational cue triggers a remembered future action rather than a clock time.
Related originating lineages:
- Human-Computer Interaction — Notification and automation design operationalized real-world event triggers that deliver bound actions to users.
Review resolution: The current reviewers agree that psychology is primary. For the reported differences (reported_ambiguity, alternate_origin_disagreement, origin_mode_disagreement), the evidence supports convergent, multi_domain, and human_computer_interaction; these choices preserve materially formative origins without conflating later domain reach.
Attribution caveat: The cognitive event-based reminder and software event trigger are parallel implementations of the same cue structure.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Event-based prospective memory — in the memory literature (McDaniel and Einstein), remembering to perform an intended action when a particular external event occurs, as opposed to time-based prospective memory, where the trigger is a target time. Event-based cues are generally retrieved more reliably because the environment itself supplies the trigger. ↩