Tensions in Practice: A clock and a context fire at different times¶
A stored intention to send a parcel update
At 09:00, a clerk stores the intention to send one status update. In the fixed example, noon arrives before the parcel, which arrives at 14:00. A clock-based cue retrieves the intention at noon and the update says “not arrived.” An arrival-based cue retrieves it at 14:00 and the update says “arrived.” Both reports are accurate when sent. The choice is whether the intended service is a regular status report or notification of a particular event.
Keep a promised reporting time
Send an update at noon whether or not the parcel has arrived.
Report when the situation changes
Send the update when the parcel actually arrives.
Why these aims pull against each other
The two cues coincide only if the event occurs at the scheduled time. A clock cue can fire without a changed situation; an event cue can leave a scheduled report unsent.
Choose an arrangement to see what changes and what remains difficult.
Arrows bind the stored intention to one cue and retrieve the action from that cue. Clock and parcel nodes are both present in the same fixed trace; an unconnected cue does not trigger this intention.
What this choice protects
What it costs
When it fits
Compare the arrangements
Cue at noon
Bind the stored intention to the noon clock cue. Retrieve it once and send the current status; the later parcel arrival does not trigger another report in this arrangement.
- What it protects
- The recipient receives the scheduled status update even if nothing has arrived.
- What it costs
- The update can precede the useful arrival event, and somebody or something must detect the scheduled time.
- When it fits
- Plausible when a regular reporting commitment matters independently of whether the parcel arrives.
Illustration note: This is an editorial, deliberately bounded illustration. Its stated rules and any numbers are invented, not observations, recommended settings, or predictions.
Cue on arrival
Bind the intention to detection of the parcel’s arrival. Retrieve it once at 14:00 and send the arrived status; noon alone does not fire it.
- What it protects
- The report is directly associated with the event the recipient may need to act on.
- What it costs
- A late or absent arrival yields a late or absent report; arrival recognition must work, and no noon-status promise is fulfilled.
- When it fits
- Plausible when arrival notification is the purpose and a report is not owed merely because noon passes.
Illustration note: This is an editorial, deliberately bounded illustration. Its stated rules and any numbers are invented, not observations, recommended settings, or predictions.
What this illustration does—and does not—establish
The source establishes the structural tension; the concrete alternatives and their conditional costs are editorial synthesis. No arrangement is a universal recommendation.
- The event times and successful cue detection are invented. No human forgetting rate, attention estimate or software reliability claim is made.
- Both arrangements store the intention without continuous active rehearsal. Clock detection still needs a monitoring mechanism; event detection is not infrastructure-free.
- This compares two purposes, not a rule that they must never be combined. Combining them would send more than the single update modeled here.
Source entries
Prospective Memory
Prospective memory Time-Based versus Event-Based Cue (measurement) supplies the local tension. The setting, alternative arrangements, and stipulated consequences are editorial applications.
Time-Based versus Event-Based Cue (measurement)
Diagnostic: ask whether the action must fire at a *time* (accept continuous monitoring, use time-based) or in response to a *situation* (accept recognition load, use event-based) — mismatching the cue type to the trigger's nature either wastes monitoring effort or misses a deadline that no context announced.