State the source and the object it concerns

What it is

Verifiable notification provenance and referent lets an authorized viewer determine which product or subsystem sent the notification, who or what triggered it, which object it concerns, and why that state is relevant. Source, actor, object, and state need not all appear every time, but omissions must not leave reasonable ambiguity. On activation, a deep link resolves and validates the current authentication context, reauthenticating or stepping up only when needed, and reauthorizes before opening the corresponding object's current state rather than merely replaying the send-time snapshot.

Why it happens

A notification leaves its originating interface for a cross-app, cross-device stream, where an app icon cannot distinguish workspaces, accounts, automation, or collaborators. Actor distinguishes a person, system, or rule; object limits scope; state and relationship explain relevance. A link to home, the wrong account, or an expired action cannot verify the promise. Trusting payload data directly can bypass changed permissions. Stable concept and object IDs, a send-time version, and fresh landing data connect wording to current reality.

Studying it

Build a source × actor × object × state × account/workspace matrix. Include same-name objects, delegated actions, automation, cross-device duplicates, rename or deletion, revoked access, and expiry. Ask users to judge relevance from permitted details, then open the link and verify object, state, and next step; record mis-opens, wrong accounts, backtracking, and stale actions. Test spoken order and long-name truncation, and avoid real sensitive objects in privacy-state studies.

Where it stops holding

Actor and object may be hidden on a lock screen or shared device and revealed after unlock; self-containment does not override disclosure permission. A security notification may withhold detection rules while identifying the affected account, a safely stated condition, and a verification route. Marketing without a specific object should honestly identify product source and promotional category rather than inventing a personal event. The product must not endorse an unverifiable external source in its own voice.

Applying it

• Model source, actor, action, object, relationship, state, event time, workspace or account, and privacy class, with non-misleading variants for missing or unknown values.
• Use product-consistent object and state terms. Disambiguate same-name objects with a safely visible workspace or type, and do not hide known provenance behind “someone did something.”
• Put a stable reference—not authorization—into the deep link. On open, resolve and validate the current authentication context; reauthenticate or step up only when the session is missing, expired, or risk requires it. Always recheck the account, workspace, and object permission before fetching current state. Show present status and a safe return path for expired or completed events.
• Deduplicate one event across devices and update or retract stale notifications. Regress sending, grouping, speech, activation, account switching, permission change, and history end to end.

Related

• Same group: T2.08.1 The first line must stand alone when collapsed · T2.08.3 Anxiety-inducing copy gets notifications switched off entirely
• Adjacent: T1.03.2 Omitting the subject creates unclear reference · T2.02.3 Labels must match the target page's heading
• Search terms: notification provenance · actor object state · verified deep link