Badge logic must match the actual state exactly

What it is

A navigation badge is internal state leaking onto the destination. The rule that lights it must match the real state: nothing unfinished inside, stay dark; still unfinished, stay lit; the number must match the objects. When it does not, people walk in and find nothing, or walk past a dark door and miss work. This is not habituation (a long-lit mark going numb). It is truth on every frame.

Why it happens

Badges are usually a cached aggregate: a count on the unread table, a queue length, cart rows. If the aggregate is written apart from the source table, the two fork — a read writes back to the source and the count does not decrement; a push increments the count and the source has no row. Users take the navigation as true, find a mismatch inside, and demote every badge to untrusted. Multiple devices fork more easily: read on the phone, still lit on the desktop. An aggregate query written loosely (“ever had unread, stay lit”) produces systematic false positives.

False negatives are as bad: filtered, archived, or handled by someone else, the source is already empty, and the navigation still demands a visit. False positives train ignore; false negatives train people not to trust navigation and to spot-check instead; the badge is then unemployed as a choice cue.

Where it stops holding

A short network delay may leave the badge a beat behind, but entering the destination should correct to the source immediately; a wrong count must not hang for the rest of the session. An intentional optimistic +1 must roll back on failure. When permission can see only some objects, the badge must count the visible ones; counting invisible unread will not match what is inside. Demo data and coach-mark fake unread mixed into the real channel dirty consistency for good.

Applying it

• Aggregate the badge from the same source as the list. Read, handle, and delete decrement the count on that same write path.
• Across devices, the source is authority. Align when the navigation is shown or the destination is entered; do not let each device keep its own count for long.
• Treat “list empty, badge on” and “unfinished in the list, badge off” as defects, not visual issues.
• How to check: handle one item on one device; the other device’s nav should clear or decrement the next time it is visible. Fork source and cache on purpose; the UI should correct to the source. Compare list length with the badge number; a mismatch is an aggregate to fix, not a colour to tweak.

Related

• Within the group: E5.17.1 A nav badge signals unfinished work inside that destination · E5.17.2 Large counts on badges need a compacted display · E5.17.3 A badge that never clears dulls sensitivity to new items
• Adjacent: E5.16 Shortcuts and Pinned Items · E6.11 Badges and Dots
• Search terms: badge consistency · unread source of truth · stale count