Spensara Spensara Knowledge Base & Documentation Repository

Repository Docs & Knowledge Base

Consolidated Spensara documentation repository (722 Markdown & architecture documents in ../repository)
Built Word Documents (.docx): Spensara Overview (.docx) Capability Assessment (.docx) Brink POS Ingestion Analysis (.docx) The Borg Ingestion Architecture (.docx)

Monitor Specs (29)

Operational monitoring, alerting, anomaly detection, and health specifications.
monitor-specs/backend/Kds.Ai.Data/MonitorSpecs/item-recall-storm.md 3,243 bytes · Updated Oct 23, 2026 10:44 AM EDT
Raw File

id: 019cb9fd-14a0-7ee4-a201-76118a743fd7 name: Item Recall Storm Monitor kind: Anomaly cron: 0 0 * * * * analysis_window: 1h comparison_periods: [1d, 7d]


Detect an unusual spike in item recalls -- completed items being sent back to the kitchen for rework, indicating quality issues or operational breakdown.

Known Tables & Columns

curated.kitchen_orders

  • guid (varchar, PK) - order identifier
  • store_guid (varchar) - which store/restaurant
  • done (tinyint) - whether the order is complete
  • is_deleted (tinyint) - soft delete flag
  • create_time (int, unix timestamp) - when the order was created

curated.kitchen_order_items

  • guid (varchar, PK) - item identifier
  • order_guid (varchar, FK) - parent order
  • name (varchar) - menu item name
  • category (varchar) - Grill, Fryer, Salads, Drinks, Desserts
  • device_id (int) - KDS station ID (1=Grill, 2=Fryer, 3=Salad, 4=Drinks, 5=Desserts)
  • recall_time (int, unix timestamp, nullable) - when the item was recalled (NULL or 0 if never recalled)
  • is_deleted (tinyint) - soft delete flag
  • create_time (int, unix timestamp) - when the item was created
  • update_time (int, unix timestamp) - last update

curated.kitchen_item_status_events

  • guid (varchar, PK) - bump identifier
  • item_guid (varchar, FK) - parent item
  • status (tinyint) - 0=pending, 1=prepared, 2=done
  • last_status (tinyint, nullable) - previous status before current change
  • prepared_local_time (int, unix timestamp, nullable) - when item was prepared
  • done_local_time (int, unix timestamp, nullable) - when item was completed (reset to 0 on recall)
  • is_deleted (tinyint) - soft delete flag

Analysis Approach

  1. Query items from the last {AnalysisWindow} in curated.kitchen_order_items (is_deleted=0) where recall_time IS NOT NULL AND recall_time > 0.
  2. Also query total items created in the same window. Verify at least 15 items exist in the window. If not, call emit_no_anomaly — the sample is too small.
  3. Count recalled items per 15-minute window and compute the recall rate: recalled items / total items created in that window.
  4. Compare against the historical baseline. Under normal operations, recalls should be rare -- typically <2% of items.
  5. Flag windows where the recall rate exceeds 10%, sustained over 2+ consecutive windows.
  6. Join with curated.kitchen_item_status_events to identify items that were previously at status 2 (done) and are now back at status 1 (prepared) -- this confirms the recall pattern.
  7. Optionally break down by device_id (station) or category to find if recalls cluster on specific stations or menu items, which could indicate a quality issue with specific food types.

Baseline Reference

  • Normal recall rate: <2% of completed items
  • Suspicious: 5-10% recall rate
  • Anomalous: >10% recall rate, especially >20% (1 in 5 items being sent back)

Severity Guidance

  • Low: 10-20% recall rate sustained for 2+ consecutive windows, possible quality issue
  • Medium: 20-30% recall rate sustained over multiple windows, systematic quality problem
  • High: >30% recall rate -- kitchen is in a recall storm, completed items are being continuously sent back for rework