{
 "notes": "Ines said to lead with priorities 2 and 4 if slots are tight, so tonight is entirely those two. For priority 2, I'm not just re-stating last week's 60-request total — Claire Dubois (Risk & Payments) posted ~48 requests company-wide in the same channel, which doesn't match my count, so before anything goes to the regulator I need an auditable type-x-status breakdown that either reconciles the two numbers or pinpoints exactly where they diverge. I'm also treating \"zero portability requests ever\" as a hypothesis to test rather than a fact: since data_subject_requests.data_export_id links to data_exports, I can check whether export jobs are actually being run for shoppers outside the formal DSAR table — if so, that's a logging blind spot, not a true zero. For priority 4, last week I only checked 2 of the 6 policy-covered tables (email_log confirmed broken, audit_log mostly fine with a narrow gap); tonight I'm closing out the remaining four (events, job_runs, page_views, system_health_checks) at a compact one-row-per-table grain so Ines has the full current picture of \"what persists past its stated window,\" not just the one confirmed violation. I'm deferring the legal-hold evidence question (priority 1), the consent anomaly (priority 3), and Henrik's three asks to night 2, since those need either external evidence (disputes) or more design thought (what \"touches security data\" means for a request) that I don't want to rush tonight.",
 "requests": [
  {
   "title": "Privacy request volume reconciliation: counts by type and status",
   "question": "What is the defensible, auditable count of privacy (DSAR) requests by type and status, so we can reconcile against the ~48 figure quoted elsewhere and the 60 we found last week before briefing the regulator?",
   "grain": "one row per (request_type, status) combination, across full history, all tenants",
   "columns": [
    "request_type",
    "status",
    "count",
    "earliest received_at (date)",
    "latest received_at (date)",
    "median days to close (completed_at minus received_at, in days, for rows where completed_at is not null; blank if none)"
   ],
   "details": "Source: data_subject_requests, no date or tenant filter (full history, platform-wide, matching what last week's reports covered). Group by request_type and status exactly as stored (do not normalize casing) so we can see if any unexpected type/status strings exist. This is meant to be the single ground-truth table that explains how other reported totals (e.g. Risk & Payments' ~48) might be a subset of ours (e.g. excluding a status or request_type) — order by request_type, then status, so all rows for a type are grouped together.",
   "builds_on": [
    "Data subject request status audit: does completed_at reflect true closure?"
   ]
  },
  {
   "title": "Portability requests: formal DSAR count vs. unlinked data exports",
   "question": "Is 'zero portability requests in 3 years' a real zero, or are shopper data exports being fulfilled outside the formal DSAR process (a logging blind spot)?",
   "grain": "one row per linked-to-DSAR status (2 rows: linked, not linked)",
   "columns": [
    "linked to a data_subject_requests record (Y/N)",
    "export count",
    "distinct subject users (count of distinct subject_user_id)",
    "earliest requested_at (date)",
    "latest requested_at (date)",
    "completed export count (status indicating the export finished)",
    "average row_count (for exports where row_count is not null)"
   ],
   "details": "Source: data_exports LEFT JOIN data_subject_requests ON data_subject_requests.data_export_id = data_exports.id. 'Linked' = a matching data_subject_requests row exists (regardless of that row's request_type); 'not linked' = no such row. Platform-wide, full history, no date filter. If the 'not linked' row has a meaningful count, that indicates shopper data exports happen outside the DSAR table entirely, which would mean request_type='portability' showing 0 in data_subject_requests is a process/logging gap rather than genuine zero demand. Order by linked_to_dsar (Y first, then N).",
   "builds_on": [
    "Data subject requests: monthly volume, closure time, and overdue backlog"
   ]
  },
  {
   "title": "Retention reality check beyond email: events, job_runs, page_views, system_health_checks",
   "question": "Beyond the confirmed email_log failure, how much data in the other four policy-covered tables is currently sitting past its stated retention window?",
   "grain": "one row per entity_table: events, job_runs, page_views, system_health_checks",
   "columns": [
    "entity_table",
    "stated retention_days (from retention_policies, confirmed uniform across tenants last week)",
    "action_on_expiry",
    "total rows currently in the live table (platform-wide)",
    "oldest row age in days (as of 2026-01-05)",
    "rows exceeding stated retention (count)",
    "pct of rows exceeding stated retention"
   ],
   "details": "Source: retention_policies for the stated retention_days/action_on_expiry per table (one value each, already confirmed uniform across all 120 tenants last week), joined against each live table using its natural timestamp: events.occurred_at, job_runs.queued_at, page_views.viewed_at, system_health_checks.checked_at. Use the literal date 2026-01-05 for all age math (never CURRENT_DATE/now()). This mirrors last week's email_log/audit_log checks but at a compact one-row-per-table summary so all four fit on one page, giving a complete current picture of retention-window violations across every policy-covered table, not just the one confirmed so far. Order by pct of rows exceeding retention, descending (worst first).",
   "builds_on": [
    "Retention policy landscape: distinct rules by entity table",
    "email_log actual retention vs. the stated 730-day delete policy",
    "audit_log actual archiving vs. the stated 730-day archive policy"
   ]
  }
 ]
}