Dattavani Backend: Notifications and Email Diagram

Each type has a catalog entry: title, body, deep-link screen and channels (push, email, in_app).
Jobs and routes pick the entry; delivery code reads its channels to decide what to send.
Email HTML maps catalog IDs to EML-XX bodies (TRL-01 to EML-01). TRL-03 and TRL-05 have no HTML yet, so they send plain text.
To add a type: add the entry and register it in NOTIFICATION_CATALOG_BY_TYPE; for email, add bodies/EML-XX.html and its row in _eml_meta.json.

Kid messages reach active kids only. Cron jobs read kid_profiles.is_active; kid API routes pass the kid JWT consent check.
Revoking consent hard-deletes the kids, so kid messages stop and EML-23 goes to the parent.
There is no per-user opt-in or unsubscribe column. EMAIL_ENABLED and FCM_ENABLED are global switches.
Parent cron jobs (trial lifecycle, renewal reminder) do not check consent_revoked_at before sending.

Every send writes a notifications row first; push_only rows hide from the kid inbox service.
Kid dedup: one per kid and type per UTC day; LOG-04 and LOG-05 once per kid.
Parent dedup: once per type, or once per dedup_key such as renewal_reminder:<sub>:<date>.
Dedup reads fail open: a DB error counts as not sent, so a retry can send twice. tataji_prompt has no dedup at all.

send_email (smtplib) and the FCM client are synchronous. From an API background task they block the event loop for up to 30 s and 15 s.
GET /api/notifications does not filter recipient_type, so push_only and parent audit rows show in the list.
POST /api/notifications/device-token inserts a device_sessions row without device_id or session_token (both NOT NULL) when no session exists, so it returns 500.
notification_inbox_service.py is never imported; the router has its own queries.