Implemented notifications catalog#

Long-form reference for every outbound notification the AutoResponder pipeline sends today: exact To / Cc, subject templates, attachments, and body text as implemented in code.

For the compact recipient matrix, see NOTIFICATIONS_REFERENCE.html. Product decisions from the 2026-05-17 alignment are in meetingNotes.md. Deferred work: Deferred (N11) and IMPLEMENTATION_PLAN.html. Legacy 1.x / 2.x / 3.x IDs are mapped in Legacy ID mapping.

Derived from:

• src/auto_responder/services/notifications/notifier.py
• src/auto_responder/services/notifications/alignment_helpers.py
• src/auto_responder/processors/action_engine.py (flush_batch_notifications)
• src/auto_responder/main.py
• src/auto_responder/services/tarun_upload_api.py
• src/auto_responder/services/email_service.py
• src/auto_responder/config.py
• src/auto_responder/send_output_folder_emails.py
• src/auto_responder/send_action_items_confirmation.py

Notification index (N01–N12)#

Rows are sorted in pipeline send order. Every live email also receives the global Max + Vish Cc (see Global delivery rules) unless SMTP_NOTIFICATION_RECIPIENTS override is active. Index Cc shows role-specific Cc only; add Max + Vish for production routing unless override is on.

Pipeline order: N01 → N02 → N03 (batch flush; each sends only when its in-memory queue has rows) → N04 → N05 or N06 when action-item CSVs exist → N07 → N08 → N11 scaffold (log only). N09/N10 are independent of the batch run.

Global delivery rules#

• Single send path: every live notify_* method calls Notifier._send_notification_email, which assembles the full body (see Email body assembly), merges Cc, and invokes EmailService.send_email.
• Global Cc: NOTIFICATION_EMAIL_MAX and NOTIFICATION_EMAIL_VISH are appended on every send via _global_cc() / _merge_cc (deduped against To). These appear in the delivery note Intended Cc when override is active.
• Action-required subjects: _action_required_subject() produces [ACTION REQUIRED] [AutoResponder] … and strips duplicate prior [REVIEW REQUIRED] / bare [AutoResponder] prefixes. Exception: notify_run_audit_for_ip4 (N08) uses only [AutoResponder] Run reports - {run_dir}.
• Attachment allowlist: filter_notification_attachments keeps .csv, .txt, .log, .html only — JSON and other suffixes are dropped from emails (JSON may still exist on disk). This also applies to Tarun uploads: the upload endpoint accepts .csv, .tsv, .xls, and .xlsx, but only allowlisted suffixes are attached to the outgoing notification.
• SMTP_NOTIFICATION_RECIPIENTS: when set, EmailService.send_email delivers To-only to that list — all Cc is dropped at SMTP time. The body still records who would have received the message in production via the Delivery note block (see below).
• SMTP_ALWAYS_CC: merged into Cc by EmailService.send_email when override is off (after notifier global Cc). When override is on, the delivery note lists SMTP_ALWAYS_CC with an explicit “not added to delivery” qualifier.
• Simulation / dev mock-all: MOCK_ALL_SERVICES_FOR_DEV=true always uses Notifier(dry_run=True) and sends nothing. With WRITE_OPERATIONS_ENABLED=false, notifications are logged only unless SMTP_NOTIFICATION_RECIPIENTS is set; in that simulation+override mode, database writes remain intercepted but notifications are sent To-only to the override list.
• Skip-when-unset: most methods return True and log when the primary recipient env var is missing (no hard failure). Client Services N02/N09 return False only when Angel/Yogesh are unset and the Max fallback is also unset.
• Multipub Client Services gate: subscriber follow-up emails fire only when Multipub shows active subscription, subscription in the last 12 months, or purchase in the last 12 months. Undetermined sender identity routes to Tarun; determined sender with no Multipub match sends neither Tarun nor Client Services email.

Email body assembly (every live send)#

Notifier._send_notification_email builds the SMTP body in this order (implemented in notifier.py + alignment_helpers.py). Every send includes an HTML alternative that bolds the subject and opening instructions. When SMTP_NOTIFICATION_RAW_MODE is false, metadata blocks are appended at the bottom of both plain and HTML parts.

1. Main content — per notify_* method (documented under each N## below).
2. Catalog banner — appended via format_notification_catalog_header only when SMTP_NOTIFICATION_RECIPIENTS is set, so dev/override recipients can map the message to a catalog entry. Production recipients (Sai, Venu, etc.) do not see the banner.
3. Attachments guide — when at least one attachment survives the allowlist, format_attachment_guide appends a filename + one-line purpose for each file.
4. Delivery note — when SMTP_NOTIFICATION_RECIPIENTS is non-empty, _smtp_override_disclosure_lines appends who actually received the message vs who it was intended for in production.

1. Catalog banner (SMTP override only)#

Omitted in production when mail goes to the intended role addresses. When SMTP_NOTIFICATION_RECIPIENTS is set, the banner is the last metadata block before the delivery note (after main content and attachments guide).

This message is notification catalog {ID} — {title from NOTIFICATION_CATALOG_NAMES}.
{optional one-line usage hint — N08 only today}
(See docs/NOTIFICATIONS_CATALOG.html)

{main content begins here}

2. Main content (per notification)#

Everything after the banner until the attachments guide. Documented in full under each N01–N09 entry below, including per-notification Intended To / Intended Cc values used in the delivery note when SMTP_NOTIFICATION_RECIPIENTS is set.

3. Attachments guide (when files attach)#

Attachments:
  - {filename}: {one-line purpose from NOTIFICATION_ATTACHMENT_DESCRIPTIONS}

Unknown filenames fall back to: Supporting file from this run (see filename). output_document_*.csv files use: Output-document deliverable for this run.

4. Delivery note (when SMTP_NOTIFICATION_RECIPIENTS is set)#

Appended after the main content and attachments guide. Lists the override mailbox(es) that actually received the message and the intended production routing for that notification (To/Cc as computed before override). Each N## entry below documents its intended To/Cc for this footer.

--- Delivery note ---
SMTP_NOTIFICATION_RECIPIENTS is active; this message was delivered to the override list.
  Override To : {comma-separated addresses from SMTP_NOTIFICATION_RECIPIENTS}
  Intended To : {production To for this notification, or "(none)"}
  Intended Cc : {production Cc after _merge_cc — per-notification Cc + global Max + Vish, deduped vs To; or "(none)"}
  SMTP_ALWAYS_CC : {comma-separated from SMTP_ALWAYS_CC} (not added to delivery while override is active)   ← only when SMTP_ALWAYS_CC is set

Important: when override is active, SMTP sends To-only to Override To. Intended Cc (including Max, Vish, Matt, Sai, Tarun, etc.) and SMTP_ALWAYS_CC are informational in the body only — neither is added at SMTP time while override is on.

Configuration#

Notification details (by phase)#

Each entry documents: Method, Trigger, To, Cc, Subject, Attachments, and the complete body as assembled by _send_notification_email (banner → main content → attachments guide → delivery note). See Email body assembly for shared blocks.

Batch notifications — N01–N03 (flush_batch_notifications)#

Flush order in code: N01 → N02 → N03. In the normal batch run, each method is called only when its corresponding queue has rows. The CSV-only fallback behavior documented for N02/N03 is used by the resend CLI and any direct method call with an existing attachment directory.

N01 — notify_hodor_prospect_import#

Body (fixed in notifier.py):

Attached: Hodor Prospect Import verification rows generated by AutoResponder.

hodor_prospect_import_verification.csv is the review and update artifact for this run. Each row includes InboxSource (original mailbox), Email, Action, RequestedStatus, Title, ProsNum, Reason, PreviousEmail, and all SAC contact fields (comma-delimited UTF-8).

Use this file to review and apply Hodor updates manually.

Verification metadata columns (prepended in hodor_prospect_import_verification.csv): InboxSource, Email, Action, RequestedStatus, Title, ProsNum, Reason, PreviousEmail — then all SAC columns (sal, fname, …, employee_value).

Complete body (as sent) — intended routing for delivery note:

• Intended To: NOTIFICATION_EMAIL_VENU
• Intended Cc: NOTIFICATION_EMAIL_MAX, NOTIFICATION_EMAIL_VISH (global; deduped if same as To)

This message is notification catalog N01 — Hodor Prospect Import.
(See docs/NOTIFICATIONS_CATALOG.html)

Attached: Hodor Prospect Import verification rows generated by AutoResponder.

hodor_prospect_import_verification.csv is the review and update artifact for this run (InboxSource, Action, RequestedStatus, SAC fields).

Attachments:
  - hodor_prospect_import_verification.csv: Hodor Prospect Import verification rows for manual review and updates.

--- Delivery note ---                                    ← only when SMTP_NOTIFICATION_RECIPIENTS is set
SMTP_NOTIFICATION_RECIPIENTS is active; this message was delivered to the override list.
  Override To : {SMTP_NOTIFICATION_RECIPIENTS}
  Intended To : {NOTIFICATION_EMAIL_VENU}
  Intended Cc : {NOTIFICATION_EMAIL_MAX}, {NOTIFICATION_EMAIL_VISH}   (or "(none)" if unset)

N02 — notify_multipub_subscriber_followup_batch#

Body (from build_multipub_subscriber_followup_payload in alignment_helpers.py):

The auto-responder detected that the people below are no longer available, retired, or unreachable, but they likely still have active or recent Multipub subscriptions.

Please reach out to these customers (or related contacts) and make the necessary subscription and contact adjustments.

Total contacts: {N}

============================================================
{idx}. {contact_name} ({contact_email})
   Subscriber number: {subsnum}
   Org: {org}                    (when present)
   Determination: {determination} (when present)
   Active subscriptions ({total}):
     - onum {onum}, {product_name}, expires {end_issue_date}
     ... and {N} more            (when more than 5)
   Subscriptions ended in last 12 months ({total}): ...
   Single-issue purchases in last 12 months ({total}): ...
   Source subject   : {source_subject}
   Source message id: {source_message_id}

CSV-only fallback (empty in-memory queue but multipub_subscriber_followup.csv on disk): subject [ACTION REQUIRED] [AutoResponder] Subscriber follow-up needed (see attached CSV); main content:

Please review the attached CSV. The auto-responder detected contacts who are no longer available but likely still have active or recent Multipub subscriptions. Reach out to customers and make the necessary adjustments.

Complete body (as sent) — intended routing for delivery note:

• Intended To: NOTIFICATION_EMAIL_ANGEL + NOTIFICATION_EMAIL_YOGESH (if both unset → NOTIFICATION_EMAIL_MAX only)
• Intended Cc: NOTIFICATION_EMAIL_MATT when set and not already in To; plus global Max + Vish

This message is notification catalog N02 — Multipub subscriber follow-up.
(See docs/NOTIFICATIONS_CATALOG.html)

{main content — full per-contact blocks above, or CSV-only fallback paragraph}

Attachments:
  - multipub_subscriber_followup.csv: Client Services queue: inactive/unavailable contacts with Multipub activity.

--- Delivery note ---
SMTP_NOTIFICATION_RECIPIENTS is active; this message was delivered to the override list.
  Override To : {SMTP_NOTIFICATION_RECIPIENTS}
  Intended To : {Angel}, {Yogesh}   (or Max if Angel/Yogesh unset)
  Intended Cc : {Matt when set}, {Max}, {Vish}   (Matt omitted if already in To)

N03 — notify_tarun_undetermined_sender_review#

Body (from build_tarun_undetermined_sender_payload):

The auto-responder could not determine the true sender email for the messages below.

Please review the email bodies, match any subscriber you can find in Multipub, and respond through the Multipub upload endpoint:
  Yes - you found a subscriber (this will notify Client Services).
  No  - reviewed; no further action needed (logged only).

Total cases: {N}

============================================================
{idx}. Subject       : {subject}
   Raw From      : {raw_from}
   Candidate(s)  : {candidates}
   Determination : {determination}
   Message ID    : {message_id}
   Run directory : {run_directory}
   Body excerpt  :
     {body_excerpt}

CSV-only fallback main content:

Please review the attached cases where the auto-responder could not determine the true sender email. Reply through the Multipub upload endpoint with outcome yes or no.

Complete body (as sent) — intended routing for delivery note:

• Intended To: NOTIFICATION_EMAIL_TARUN
• Intended Cc: global Max + Vish

This message is notification catalog N03 — Tarun undetermined sender.
(See docs/NOTIFICATIONS_CATALOG.html)

{main content}

Attachments:
  - tarun_undetermined_senders.csv: Cases where the true sender email could not be determined (Tarun review).

--- Delivery note ---
SMTP_NOTIFICATION_RECIPIENTS is active; this message was delivered to the override list.
  Override To : {SMTP_NOTIFICATION_RECIPIENTS}
  Intended To : {NOTIFICATION_EMAIL_TARUN}
  Intended Cc : {NOTIFICATION_EMAIL_MAX}, {NOTIFICATION_EMAIL_VISH}

Run-end notifications — N04–N08 (main.py)#

Call order: notify_marketing_suppression → notify_sai_action_items → notify_venu_cupola_audit_files → notify_run_audit_for_ip4 → notify_run_summary_for_leadership (log only).

N04 — notify_marketing_suppression#

Here is the list of people that the auto responder marked as inactive (deceased, retired, left their organization, or no longer there).

Attached are suppression import files ready for SFMC ({filenames}).

Please suppress them from your marketing communications.

Run directory: {report_dir}

Complete body (as sent) — intended routing for delivery note:

• Intended To: marketing team mailbox via NOTIFICATION_EMAIL_ERIN (marketing-team-cbi@columbiabooks.com)
• Intended Cc: global Max + Vish

This message is notification catalog N04 — Marketing suppression.
(See docs/NOTIFICATIONS_CATALOG.html)

Here is the list of people that the auto responder marked as inactive (deceased, retired, left their organization, or no longer there).

Attached are suppression import files ready for SFMC (Marketing_NoLongerThere_2026-05-27.csv).

Please suppress them from your marketing communications.

Run directory: {report_dir}

Attachments:
  - Marketing_NoLongerThere_2026-05-27.csv: SFMC suppression import file (Email Address, Status, Date Added).

--- Delivery note ---
SMTP_NOTIFICATION_RECIPIENTS is active; this message was delivered to the override list.
  Override To : {SMTP_NOTIFICATION_RECIPIENTS}
  Intended To : marketing-team-cbi@columbiabooks.com (NOTIFICATION_EMAIL_ERIN)
  Intended Cc : {NOTIFICATION_EMAIL_MAX}, {NOTIFICATION_EMAIL_VISH}

N05 — notify_sai_action_items (replacements-only)#

Body opening (fixed):

Please complete the manual Cupola actions below for this run.
Search Cupola for each person; if a record is missing, create it and associate it to the correct organization.
Reply when manual actions for this run are complete.

Run directory: {report_dir}

Then up to four sections with per-record blocks:

• SECTION 1 — output_document_alternate_contacts.csv: Original email, Subject, Message ID, replacement name/email/title, org (body blocks echo these fields).
• SECTION 2 — output_document_inactive_no_cupola_match.csv: contact email, person name, org, determination, source subject/message id.
• SECTION 3 — output_document_inactive_new_org.csv: contact email, person name, previous org, new org name/title, Cupola action, source subject/message id.
• SECTION 4 — Human Review rows whose Reason is in SAI_ACTION_HUMAN_REVIEW_REASONS: active_new_contact_no_cupola, reactivation_candidate_inactive_cupola, email_or_title_update_on_inactive_cupola, replacement_parse_fallback, unknown_determination, no_contact_match.

Per-record block formats (in body when section has rows):

SECTION 1 - New replacements for inactive contacts
===============================================
Rows: {N}

  {idx}. Original: {Email Received From}
     Replacement Name : {Alternate Person Name}
     Replacement Email: {Alternate Person Email}
     ...

SECTION 2 - Inactive contacts with no Cupola match (research)
  {idx}. Contact Email     : ...
SECTION 3 - Inactive contacts at a new organization
  {idx}. Contact Email     : ...  New Org Name : ...
SECTION 4 - Other Human Review action items
  {idx}. Contact Email     : ...  Reason : ...  Notes : ...  Suggested Action : ...

Complete body (as sent) — N05 only (replacements-only); intended routing:

• Intended To: NOTIFICATION_EMAIL_SAI
• Intended Cc: global Max + Vish
• Typical attachments: output_document_alternate_contacts.csv only

This message is notification catalog N05 — New replacements for inactive contacts (Sai / IP4).
(See docs/NOTIFICATIONS_CATALOG.html)

Please complete the manual Cupola actions below for this run.
...
{SECTION 1 blocks only when N05}

Attachments:
  - output_document_alternate_contacts.csv: Replacement contacts suggested for inactive subscribers.

--- Delivery note ---
  Intended To : {NOTIFICATION_EMAIL_SAI}
  Intended Cc : {NOTIFICATION_EMAIL_MAX}, {NOTIFICATION_EMAIL_VISH}

N06 — notify_sai_action_items (manual review bundle)#

Same method, SECTION 1–4 layouts, and per-record formats as N05. Catalog banner and subject differ.

Complete body (as sent) — N06 (combined bundle); intended routing:

• Intended To: NOTIFICATION_EMAIL_SAI
• Intended Cc: global Max + Vish
• Attachments: every relevant section CSV that exists (alternate, no-cupola, new-org, and/or output_document_human_review_action_items.csv when SECTION 4 has rows)

This message is notification catalog N06 — Manual review action items (Sai / IP4).
(See docs/NOTIFICATIONS_CATALOG.html)

{same opening paragraph and Run directory as N05}
{one or more SECTION 1–4 blocks with per-record detail}

Attachments:
  - {each attached CSV with output-document description}

--- Delivery note ---
  Intended To : {NOTIFICATION_EMAIL_SAI}
  Intended Cc : {NOTIFICATION_EMAIL_MAX}, {NOTIFICATION_EMAIL_VISH}

N07 — notify_venu_cupola_audit_files#

Main content (fixed opening + dynamic counts):

Please review the attached Cupola audit log for this run and reply by email when you have finished processing the records.

Run directory: {csv_path.parent}
Audit entries: {entry_count}
Human Review rows: {total}                    ← when output_document_human_review.csv exists

Human Review counts by reason:               ← when HR CSV has rows
  - {reason}: {count}
  ...

Human Review reason key:
  - unknown_determination          LLM returned UNKNOWN
  - no_contact_match             Actionable outcome, no contact in any system
  - bounce_pending_rule          Bounce awaiting the Max + Vish rule
  - replacement_parse_fallback   Replacement alt-contact failed to parse
  - active_new_contact_no_cupola Active person is missing from CUPOLA
  - reactivation_candidate_inactive_cupola CUPOLA row is inactive but email indicates active
  - email_or_title_update_on_inactive_cupola Email/title update requested on inactive CUPOLA row
  - out_of_office_tracked_separately Out-of-office response awaiting split-out process

Complete body (as sent) — intended routing for delivery note:

• Intended To: NOTIFICATION_EMAIL_VENU
• Intended Cc: NOTIFICATION_EMAIL_SAI and NOTIFICATION_EMAIL_MAX when distinct from Venu; plus global Max + Vish (Max may appear once after dedupe)

This message is notification catalog N07 — Venu CUPOLA audit.
(See docs/NOTIFICATIONS_CATALOG.html)

{main content above}

Attachments:
  - cupola_audit_log.csv: CUPOLA changes applied or recommended during this run.
  - cupola_audit_log_rollback_plan.csv: Rollback SQL for auto-applied CUPOLA status changes.   ← when present
  - output_document_human_review.csv: Human Review metadata for every HR row in the run.     ← when present

--- Delivery note ---
  Intended To : {NOTIFICATION_EMAIL_VENU}
  Intended Cc : {Sai when ≠ Venu}, {Max when ≠ Venu}, {Max}, {Vish}   (actual merge/dedupe in code)

N08 — notify_run_audit_for_ip4#

Body sections (built in notifier.py):

• Run identity (directory; run started parsed from run_YYYYMMDD_HHMMSS folder name when possible)
• Email pull window (UTC start/end) when backlog snapshot is available
• Impact summary with definitions (emails processed, records deactivated, records added)
• This-run progress (processed count + repository backlog estimate, or master-CSV complete vs pending)
• Category breakdown from category_summary_report.csv
• Processing status breakdown from master CSV
• IP4 ledger row count
• Repository backlog snapshot (or skipped/incomplete reason)

Main content (all sections optional except opening; built in notify_run_audit_for_ip4):

This email contains the run ledger and summary files for verification.

Run identity:
  Run directory : {report_dir}
  Run started   : {YYYY-MM-DD HH:MM:SS UTC (from folder name)}   ← when parseable

Email pull window (UTC):                        ← when backlog snapshot OK
  Start : {ISO8601}
  End   : {ISO8601}

Impact summary (this run):
  Run ID               : {run_id}
  Emails processed     : {N}  (messages handled in this batch)
  Records deactivated  : {N}  (auto-applied CUPOLA inactive transitions)
  Records added        : {N}  (successful contact_addition with contact_id)

This-run progress:                              ← backlog snapshot or master CSV
  Processed this run           : {N}
  Repository backlog estimate  : {N}

Category breakdown (category_summary_report.csv):   ← when file exists
  - {category}: {count}

Processing status breakdown (master CSV):           ← when master exists
  - {status}: {count}

IP4 ledger:
  processing_report_ip4.csv rows : {N}

Repository backlog snapshot:                        ← when snapshot OK
  Total candidates in window   : {N}
  Estimated still unprocessed  : {N}
  Oldest unprocessed ReceivedDate (UTC): {ISO8601 or (none - backlog empty)}
  Days behind (UTC calendar vs now): {N}

Complete body (as sent) — intended routing for delivery note:

• Intended To: settings.ip4_audit_recipients() → NOTIFICATION_EMAIL_SAI
• Intended Cc: global Max + Vish
• Note: impact_report.txt is written on disk but is not attached to the email (not in allowlist attachment list for this method).

This message is notification catalog N08 — Run audit (IP4).
Review the attached run ledgers and summaries to verify this batch. Use processing_report_ip4.csv for IP4-actionable rows; no reply needed unless something looks wrong.
(See docs/NOTIFICATIONS_CATALOG.html)

{main content sections above}

Attachments:
  - processing_report.log: Full per-email processing trace, run summary, and impact headline metrics.
  - processing_report_master.csv: Ledger of every email in the run (full internal column set).
  - processing_report_ip4.csv: IP4-actionable emails only (filtered categories, 23-column order).
  - category_summary_report.csv: LLM category counts for the run.
  - batch_report.html: HTML dashboard summarizing run outcomes.
  (only files that exist on disk are listed)

--- Delivery note ---
  Intended To : {NOTIFICATION_EMAIL_SAI}
  Intended Cc : {NOTIFICATION_EMAIL_MAX}, {NOTIFICATION_EMAIL_VISH}

Upload API — N09–N10 endpoint#

POST /multipub/upload — multipart file plus form outcome=yes|no (default yes). Implemented in tarun_upload_api.py.

N09 — notify_multipub_subscriber_followup_from_upload#

Main content — no parsed items (current Yes-path default):

Tarun reviewed an undetermined-sender case and confirmed a subscriber match in Multipub.

Please review the attached file and reach out to the customer or related contacts to make the necessary subscription and contact adjustments.

Note from Tarun:                                              ← when upload form includes a note
{note text}

This body text is fixed in code. If the uploaded file has a suffix accepted by the upload API but not by filter_notification_attachments (for example .xlsx), the email can still say “attached file” while the attachment is omitted.

Main content — with items: same per-contact blocks as N02 from build_multipub_subscriber_followup_payload (subject prefix adds Tarun confirmed subscriber match -).

Complete body (as sent) — intended routing for delivery note:

• Intended To: Angel + Yogesh (same as N02; Max fallback)
• Intended Cc: Matt when set; NOTIFICATION_EMAIL_TARUN when not already in To; global Max + Vish
• Attachments: uploaded file under original filename only when allowlisted; optional inline CSV when items passed

This message is notification catalog N09 — Tarun upload — Yes (subscriber follow-up).
(See docs/NOTIFICATIONS_CATALOG.html)

{main content — short message or N02-style blocks}

Attachments:
  - {uploaded_filename}: Supporting file from this run (see filename).   ← only if upload filename is allowlisted; or multipub CSV description

--- Delivery note ---
  Intended To : {Angel}, {Yogesh}
  Intended Cc : {Matt}, {Tarun when not in To}, {Max}, {Vish}

N10 — append_tarun_upload_audit_row — no email#

outcome=no appends to {TARUN_UPLOAD_DIR}/tarun_upload_audit.csv with columns: timestamp, original_filename, outcome, uploaded_by, note. No notification is sent.

Action items tracker (N01–N07)#

After each run, main.py calls append_action_items_for_run(report_dir) to append one row per action notification email (N01–N07 that had attachments) to action_items_tracker.csv (default under processing_reports/; override ACTION_ITEMS_TRACKER_PATH). Each row has ActionItemCount, a file breakdown in Summary, and Completed=false until an operator marks it done. See DATA_DICTIONARY §32. Catalog N12 is a separate CLI follow-up (not appended to the tracker) that asks each N01–N07 notification owner to reply confirming work for that run.

Action items completion confirmation (N12)#

CLI: auto-responder-request-action-item-confirmation <processing_reports/run_*> (send_action_items_confirmation.py).

Reads the same artifacts as collect_action_item_detail_rows, groups by NotificationId (N01–N07), and sends one N12 email per group to the notification owner (Venu for N01/N07, Sai for N05/N06, Angel+Yogesh for N02, etc.). Does not inspect the Sent mailbox.

Subject: [ACTION REQUIRED] [AutoResponder] Confirm completion — {original N## title} — {run date}

Body: Reply request for the run date, reference to the original N## notification, row counts, breakdown by source file, and up to 25 item lines from tracker fields.

Resend from an output folder#

CLI: auto-responder-send-output-emails <processing_reports/run_*> (send_output_folder_emails.py).

Dispatch groups (in order):

1. N01 hodor-prospect-import — loads rows from hodor_prospect_import_verification.csv
2. N02 multipub-subscriber-followup — CSV-only resend when multipub_subscriber_followup.csv exists
3. N03 tarun-undetermined-senders — CSV-only when tarun_undetermined_senders.csv exists
4. N04 marketing-suppression — when *_NoLongerThere_*.csv exists in the run folder
5. N05/N06 sai-action-items
6. N07 venu-cupola-audit — rebuilds entry count from JSON or CSV
7. N08 ip4-run-audit — restores impact_report and backlog from processing_report.json when present

Leadership summary is not resent (not implemented).

Deferred (N11) / not implemented#

notify_run_summary_for_leadership#

Called from main.py after the IP4 run audit. Does not send email today. Builds a metrics-only preview body and logs at INFO:

AutoResponder run summary (metrics only)
Run directory: {report_dir}
Emails processed: …
Records deactivated: …
Records added: …
Email/title corrections (auto-applied): …   (from cupola_audit_log.json when present)
Distinct organizations in contact additions: …   (or "not tracked yet")

Per meeting notes and IMPLEMENTATION_PLAN.html, the live send should go to NOTIFICATION_EMAIL_LEADERSHIP with no CSV attachments, only after Sai confirms action items and Venu confirms the audit log (reply email or API). Intended subject: [AutoResponder] Run summary - {run_dir.name}.

Preview body (log-only today) — uses the catalog banner but does not send SMTP:

This message is notification catalog N11 — Leadership run summary (deferred; not emailed).
(See docs/NOTIFICATIONS_CATALOG.html)

AutoResponder run summary (metrics only)
Run directory: {report_dir}
Emails processed: {N}
Records deactivated: {N}
Records added: {N}
Email/title corrections (auto-applied): {N}   ← when cupola_audit_log.json present
Distinct organizations in contact additions: {N}   ← or "Organizations added: not tracked yet"

When implemented, intended delivery note would show Intended To : {NOTIFICATION_EMAIL_LEADERSHIP} and global Max + Vish in Intended Cc.

Legacy ID mapping#

Prior docs and meeting notes used tiered IDs (1.x, 2.x, 3.x). Use N01–N11 in new mail banners and references.

Open follow-ups#

• Service mailbox: dedicated cbi-automation sender (interim: global Max + Vish Cc on all notifications).
• Hosting: bumblebee / AWS — access TBD.
• Leadership send + confirmation gate: implement inbox/API detection for Sai and Venu completion replies.