Aglet

Investigate notification urgency with consequence evidence

An investigation should explain why an event needs its assigned interruption level and what happens when delivery is delayed. Replay representative events, compare routine and time-sensitive paths, and inspect durable history. Keep platform-level scheduling separate from the product’s urgency decision.

Build a useful investigation brief

  1. Build the urgency matrix

    List event type, creation time, deadline, consequence, channel, interruption label, user setting, in-app record, and recovery action. Include an event that should wait and one that should surface promptly. State missing timing evidence.

  2. Vary one consequence

    Hold event and channel fixed while changing deadline, user state, or recovery availability. Compare whether waiting changes the outcome. Record when a notification is useful but not time-sensitive; that distinction prevents urgency from becoming a generic severity label.

  3. Write the urgency brief

    State the supported level, first evidence boundary, and competing explanations for perceived urgency. Recommend one bounded copy, history, or interruption experiment with a pass condition. Do not claim a platform will bypass user controls without direct evidence.

What to carry forward

The investigation is complete when urgency follows a reproducible consequence and timing boundary, or the unknown is explicit. Stop with one bounded experiment. Keep platform delivery and user settings as evidence limits, not assumptions about what every person will see.

Technical background: Apple developer documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow