Multi-Store Operations Command Center — example input brief

Purpose: build an HQ-to-store publishing, execution verification and issue escalation workspace.
This is a tutorial input brief, not a complete data export or production dataset.
Project: https://e94e8bcf25bd4540adb42dddb8238f26.prod.enter.pro/

Input tables: Stores; Regions; Updates; Versions; Store Tasks; Task Steps; Evidence; Issues; SLA Events; Training Modules; Assignments; Follow-ups; Users.
Store task fields: task_id, update_id, version, store_id, state, acknowledged_at, steps_done, steps_total, evidence_status, due_at_local, verified_by, returned_reason.
Rules: completion = verified store tasks / non-cancelled store tasks; submitted tasks count only after verification; overdue is judged in each store's timezone; blocked time extends the due time; issues carry severity, owner and an SLA clock that pauses while waiting on the store; unowned issues past the SLA escalate to the HQ Action Queue; a new version archives the old one and cancels its unfinished tasks.
Workflow: HQ update -> store tasks -> acknowledgement, steps and evidence -> manager verification or return -> issues, triage and escalation -> follow-up.
Roles: Director of Operations (HQ), Regional Manager, Store Manager.

Observed example, 2026-10-12: Allergen labelling SOP v4 (adds sesame as a named allergen; a new laminated matrix at every prep station; all handlers confirm they have read it), published to 24 stores. Verified 5/24 (20.8%); 18 overdue, 4 not acknowledged, 3 blocked by an issue. Oakland Broadway (1005): returned, 2/4 steps. Issue #4111, Instructions unclear: the v4 matrix lists sesame under seeds but the label printer still prints the old category; Critical, escalated to HQ after no regional owner acted within the SLA; the store asks for an HQ decision on replacement cost. Philadelphia Rittenhouse (1023): submitted 4/4 steps, awaiting verification.
If additional demo data is needed, generate clearly labelled synthetic records with consistent IDs and dates.