Notification Content Audit

Operation

Inspect the named boundary and report supported findings. Do not edit product code. Include concrete evidence, impact, the owning source, one remediation direction and a meaningful validation route. Severity follows actual impact, not a category example.

Goal and scope

Audit product/email/push/chat notifications across trigger semantics, audience, deduplication, preferences, privacy, and destination.

Domain invariants

• The notification trigger represents a durable semantic event and is not emitted twice by retries or competing owners.
• Audience, tenant scope, preferences/consent, suppression, frequency, and channel fallback are authoritative.
• Content describes current state, redacts sensitive data, localizes correctly, and links to an authorized destination.
• Delivery, bounce/failure, retry, dedupe, unsubscribe, and operator observability are explicit.

Audit method

1. Trace event production through template selection, audience resolution, provider call, delivery state, and deep link.
2. Check duplicate/reordered events, stale state, preference changes, tenant boundaries, provider retry, and partial failure.
3. Compare templates across channels and locales with the product state they claim.
4. Identify transactional/marketing classification and any required approval boundary from repository evidence.

Priority model

• P0: content that creates legal, security, billing, consent, or destructive-action risk.
• P1: a material comprehension, conversion, localization, notification, or discoverability defect.
• P2: a lower-risk but concrete consistency, tone, metadata, or secondary-content issue.