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/priority-flood.md 2,737 bytes · Updated Oct 23, 2026 10:44 AM EDT
Raw File

id: 019cb9fd-149f-7ba9-950a-af3dd53a301c name: Priority Flood Monitor kind: Anomaly cron: 0 0 * * * * analysis_window: 1h comparison_periods: [1d, 7d]


Detect when an abnormally high percentage of orders are flagged as priority, undermining the priority system and disrupting kitchen workflow.

Known Tables & Columns

curated.kitchen_orders

  • guid (varchar, PK) - order identifier
  • store_guid (varchar) - which store/restaurant
  • is_priority (tinyint) - whether the order is flagged as priority (1=yes, 0=no)
  • items_count (int) - number of items in the order
  • order_type (varchar) - DINE_IN, TO_GO, DELIVERY
  • pos_terminal (varchar) - POS terminal that created the order
  • server_name (varchar) - server who took the order
  • done (tinyint) - whether the order is complete
  • is_deleted (tinyint) - soft delete flag
  • create_time (int, unix timestamp) - when the order was created
  • preparation_time (int, seconds, nullable) - total order preparation time

curated.kitchen_order_items

  • guid (varchar, PK) - item identifier
  • order_guid (varchar, FK) - parent order
  • is_priority (tinyint) - whether the item is flagged as priority
  • is_deleted (tinyint) - soft delete flag
  • create_time (int, unix timestamp) - when the item was created

Analysis Approach

  1. Query all orders created in the last {AnalysisWindow} from curated.kitchen_orders (is_deleted=0).
  2. Verify that each 15-minute window contains at least 20 orders. Ignore windows with fewer data points.
  3. Group into 15-minute windows and compute the priority rate: the percentage of orders where is_priority=1.
  4. Compare against the historical baseline (same time windows {ComparisonPeriods}). Under normal operations, priority orders should be uncommon -- typically <10% of total orders.
  5. Flag windows where the priority rate exceeds 60%, sustained over 3+ consecutive windows.
  6. Investigate whether the priority flood is coming from a specific pos_terminal or server_name, which could indicate a configuration issue or user behavior problem.
  7. Check the downstream impact: when everything is priority, nothing is effectively priority -- look for whether non-priority orders are being delayed.

Baseline Reference

  • Normal priority rate: 5-15% of orders
  • Suspicious: 40-60% of orders flagged as priority
  • Anomalous: >60% of orders flagged as priority, especially >80%

Severity Guidance

  • Low: Priority rate 40-60% sustained for 3+ consecutive windows
  • Medium: Priority rate 60-80% sustained for 3+ windows, priority system becoming ineffective
  • High: Priority rate >80% sustained -- priority system is completely compromised, all orders treated equally despite flag