Can a Phone Really Tell When You’re Interruptible?

What's Inside

• Why Do Notification Systems Misjudge Cognitive Load?
• How Motion, Screen Activity, and Calendar Signals Predict Availability
• Pacing, Tab-Hopping, and Stale Meetings: Where the Guesses Go Wrong
• Running a Personal Experience Sampling Study on Your Own Device
• Auditing Your Confusion Matrix to Tune Notification Rules

Why Do Notification Systems Misjudge Cognitive Load?

When your phone buzzes mid-thought, is it making a calculated decision about your focus, or just firing blindly into your day?

Most people assume the former. The log usually suggests otherwise. An alert appearing on screen proves only that something was delivered. It says nothing about whether the device weighed your workload before it lit up.

In lifelogging and context-aware computing, interruptibility is best defined as the cost of switching attention at a particular moment. That cost lives in your head. The phone can only see proxies: whether the screen is on, whether you are moving, whether your calendar says you are booked.

Here is where the gap opens. Digital availability describes the device: idle or active, locked or unlocked. Cognitive load describes the person: deep in thought, mid-conversation, or halfway through a physical transition. The two drift apart constantly. A locked phone resting beside someone rehearsing a difficult conversation looks idle and therefore available. An unlocked phone showing a grocery list looks busy. In practice, the person with the grocery list is far easier to reach.

Anyone serious about the quantified self should separate three events in their own data: when a notification arrived, when it was presented, and when (or whether) the user responded. Delivery time alone establishes neither receptiveness nor interruption cost. And task boundaries are candidate openings, nothing more. No universal waiting interval or magic sensor threshold makes them safe.

How Motion, Screen Activity, and Calendar Signals Predict Availability

A useful availability estimate gets built in layers. Each layer has a job, and each one overreaches if you let it.

Motion as a breakpoint nominator

An accelerometer measures acceleration, including gravity's pull; a gyroscope measures angular velocity. Activity-recognition services on modern phones combine these signals into coarse labels such as still, walking, or in a vehicle, and hand those labels to automations without exposing a raw sensor stream.

A sitting-to-walking transition is a candidate breakpoint because it often accompanies leaving a task. The reverse transition, walking to still, cuts both ways: it might mark arrival at a desk, or the opening seconds of a conversation. Motion should nominate a moment for scrutiny. It should not declare you free.

Screen state and app switching

Unlocking a device or switching away from an app hints at a cognitive boundary. Sustained typing or long-form reading suggests a task still in progress. Both readings deserve caution, though. An app moving to the background does not prove the task is finished, and a screen-off event does not prove the app was closed.

Calendar metadata as a prior

Calendars contribute coarse-grained priors rather than live evidence. Record busy/free status, whether the location field is filled in, and attendee count as separate fields. A busy block with one attendee and no location is weak evidence. A multi-attendee appointment with a booked room is strong evidence. Collapsing both into "busy" throws away most of what the calendar knows.

What the Phone Can't See

Platform access caps all of this. Battery optimization and background throttling rule out continuous, fixed-frequency sampling. Ordinary automations may surface selected app-open events instead of full foreground history. Without ambient audio or physiological sensors, the log holds no direct record of room dynamics or emotional state.

Pacing, Tab-Hopping, and Stale Meetings: Where the Guesses Go Wrong

Calling a heuristic "inaccurate" teaches nothing. The productive move is to name the specific mistaken inference. Each failure below confuses one kind of transition with another, and keeping them separate makes each one fixable on its own terms.

The pacing case deserves a closer look because nothing in the pipeline technically malfunctions. The walking classification is correct. A correctly detected walking transition simply becomes an incorrectly inferred break in thought, and the alert lands at peak cognitive load. Movement onset is the misleading feature.

Screen activity fails in a similar way. Rapid hopping between a browser and a notes app looks like low-focus browsing to a rule that counts switches. Often it is the most concentrated work of the day, with both app categories serving one sustained task. An empty calendar gap compounds the problem: it supplies no affirmative evidence that a browser-to-notes synthesis session has ended.

One more distinction matters. Urgency and receptiveness are different questions. A stale busy block should never disable an explicitly configured emergency bypass, because an urgent interruption and a well-timed interruption are separate decisions.

Running a Personal Experience Sampling Study on Your Own Device

Theory only gets you so far. The real answer to "when am I interruptible?" sits in your own data, and an automation tool such as Tasker on Android or Shortcuts on iOS can collect it. The protocol below proposes a 7–10-day study with 3–4 ratings per day. Treat these figures, and every interval that follows, as study settings rather than measured performance claims.

1. Define the scale first. 1 means very costly to interrupt, 2 costly, 3 neutral, 4 easy, 5 very easy. Never flip the direction mid-study.
2. Set up data capture. Configure triggers that fire during different state transitions: right after an unlock, when a selected app opens, during a calendar gap, or when motion stops. For motion triggers, a trial rule might wait for 30–60 seconds of stillness after movement before prompting. Add a 60–90-minute cooldown so one work session doesn't generate a stack of near-duplicate entries.
3. Include scheduled probes. Some prompts should fire independent of any incoming alert. Sampling only notification moments leaves you blind to receptive windows where nothing arrived.
4. Log ground truth. At each prompt, ask how costly an interruption would have been in the instant before the prompt appeared. Append the rating to a local CSV or note alongside a context snapshot.
5. Record the heuristic's prediction. Save what the rule would have predicted before the rating comes in.

Each row should hold: event time, prompt time, response time, trigger type, motion label and its observation time, last observed app category and its observation time, calendar busy/free status, environment profile, rating, and prediction.

Timestamps Keep Context Honest

Write "unknown" when motion or app context is unavailable instead of guessing from screen state. Keep observation timestamps so yesterday's last-seen app doesn't masquerade as current context. Flag any response submitted more than 2 minutes after its prompt for separate review, since it describes the target moment less directly.

Privacy belongs in the design, too. Keep capture local, and skip message text, meeting titles, attendee identities, and precise location whenever category-level context answers the question.

Auditing Your Confusion Matrix to Tune Notification Rules

With a week of logs in hand, the audit begins with a declared scoring rule. For a first pass, treat ratings 1–2 as costly, 4–5 as receptive, and set 3s aside rather than forcing ambiguity into a bin.

Use "predicted receptive" as the positive class:

• True positive: predicted receptive, rated 4–5.
• False positive: predicted receptive, rated 1–2. The phone thought you were free; you weren't.
• False negative: predicted costly, rated 4–5. A missed window.
• True negative: predicted costly, rated 1–2.

Two illustrative records, invented for clarity rather than collected: pacing while thinking, predicted receptive and rated 1, lands as a false positive. An abandoned meeting block, predicted costly and rated 5, lands as a false negative.

Start with false positives. They point at the rules actively hurting you. Then work through false negatives to find alerts suppressed for no reason. Log a shadow prediction at every probe even when nothing gets delivered, because a visible alert establishes presentation, not necessarily an operating-system judgment that you were free. Work on attention management has long separated these layers, and the ACM Digital Library research on interruptibility and attention management is a solid place to see how researchers frame them.

Turning patterns into rules

Patterns in the matrix translate into specific automation tweaks:

• If costly ratings cluster around browser-to-notes transitions at your desk, test keeping Do Not Disturb active while a desktop focus-state signal holds, instead of releasing it at every app switch.
• If movement means different things at home and in transit, test a home profile that pairs a recognized home Wi-Fi network with a stillness transition, and keep commute observations in their own profile.
• If stale calendar blocks keep producing false negatives, stop letting a bare busy flag carry the decision on its own.

Change one rule at a time. Then run another 3–5 days under the same scale and sampling procedure, and compare raw false-positive and false-negative counts alongside the number of eligible observations in each period. A rule that looks better on fewer data points might just be quieter.

So when your log shows a false positive with an accurate walking label and a rating of 1, which do you trust more next time: the sensor that was right about your body, or the rating that was right about your mind?