Aglet

Triage stale notification links before changing destinations

A notification can remain useful after its original page or state changes, but only if the destination explains what happened. Triage stale links through current state, role, and fallback. Capture the public identifier, original action, current context, and visible recovery instead of treating every failure as a broken route.

Establish what is happening

  1. Replay the notification

    Record event, public identifier, original state, notification age, action label, destination, current state, role, and response. Include a current target and a moved or unavailable target. Keep private details out of the evidence.

  2. Compare useful fallbacks

    Ask whether the destination can show current context, a parent list, a status explanation, or an alternate action. Compare a stale link with a route error and a permission boundary. A fallback should orient the person, not pretend the old state still exists.

  3. Set a stale boundary

    State which state changes trigger fallback, what copy names the change, and how the person returns to useful work. Preserve a current-link control. Stop when another reviewer can distinguish stale target, unavailable permission, and routing failure.

What to carry forward

The triage output is a stale-link recovery boundary with identity, current state, role, fallback, and explanation. Stop when target change and route failure are distinguishable. If current state cannot be read, keep the fallback conservative and record the missing evidence.

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