A 311 analytics team needs gold tables that support daily SLA dashboards. Which grain should they choose?

Gold grain for a 311 analytics SLA dashboard must match how the city measures service: typically one row per ticket-day so open tickets can be scored against daily targets. That grain lets analysts compute daily aging, breach flags, and backlog without reconstructing a day-level fact from event chaos. Ticket-day aligns curated gold to civic reporting calendars and keeps joins to date and ticket dimensions stable for dashboard refresh.

One row per ticket with status collapses each ticket to a single row, so it cannot measure open tickets against daily service targets or support daily aging and breach flags. One row per ticket-week claimed to measure open tickets against daily service targets is too coarse for a daily SLA scoreboard that needs one row per ticket per day, because weekly grain hides daily aging and breach timing. One row per ticket-month claimed to measure open tickets against daily service targets cannot provide the daily ticket-level measurement required for SLA dashboards, because monthly grain hides day-to-day open status and breach timing.

Exam caveat: grain is a modeling decision—do not confuse event-level fidelity with dashboard grain; gold should match the SLA metric’s unit of analysis. Operational check: define the gold primary key as (ticket_id, service_date), materialize daily open/closed/SLA columns from silver events, validate row counts against known ticket-days, and confirm the SLA dashboard filter on one day returns one row per open ticket without requiring ad hoc rollups.