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)

Branches (328)

Branch-specific documentation across extract-raw-xml, feature-fleet-import, kds_cdc_improvments, life-cycle, and tenat-admin.

branches/kds_cdc_improvments/monitor-specs/backend/Kds.Ai.Data/MonitorSpecs/kitchen-performance.md 4,735 bytes · Updated Oct 23, 2026 10:44 AM EDT

Raw File

id: 8c4f1a72-6e3b-4d91-9f2a-3b7d1c6e5a88 name: Analyze kitchen performance kind: OperationalAnalytics cron: 0 0 8 * * * analysis_window: 90d comparison_periods: [7d, 28d]

Analyze kitchen performance to improve operational efficiency, reduce ticket times, and identify bottlenecks, recall-heavy workflows, and service inefficiencies.

The process should evaluate kitchen workflow across stations, employees, and service conditions using historical operational data from the last 90 days only.

The output must contain kitchen performance insights only, without explanations or descriptions of methodology.

Known Tables & Columns

`curated.kitchen_orders`

guid (varchar, PK) - order identifier
store_guid (varchar) - which store/restaurant
preparation_time (int, seconds, nullable) - total order preparation time
items_count (int) - number of items in order
order_type (varchar) - DINE_IN, TO_GO, DELIVERY
destination (varchar) - Kitchen, Bar, Window, Expo
server_name (varchar) - order taker or server name
done (tinyint) - whether order is complete
is_deleted (tinyint) - soft delete flag
create_time (int, unix timestamp) - when order was created
update_time (int, unix timestamp) - last update

`curated.kitchen_order_items`

guid (varchar, PK) - item identifier
order_guid (varchar, FK) - parent order
name (varchar) - menu item name
category (varchar) - menu category for aggregation
device_id (int) - KDS station identifier
is_priority (tinyint) - item priority flag
preparation_time (int, seconds, nullable) - item preparation duration
recall_time (int, unix timestamp, nullable) - when item was recalled
is_deleted (tinyint) - soft delete flag
create_time (int, unix timestamp) - when item was created

`curated.kitchen_item_status_events`

guid (varchar, PK) - event identifier
item_guid (varchar, FK) - parent item
status (tinyint) - 0=pending, 1=prepared, 2=done
last_status (tinyint, nullable) - previous status
prepared_local_time (int, unix timestamp, nullable) - when item was prepared
done_local_time (int, unix timestamp, nullable) - when item was completed
prepared_device_id (int, nullable) - station that prepared item
done_device_id (int, nullable) - station that completed item
is_deleted (tinyint) - soft delete flag
create_time (int, unix timestamp) - when status event was created

Analysis Approach

Extract completed order and item timing data from the last 90 days using curated.kitchen_orders joined to curated.kitchen_order_items.

Aggregate:

average order preparation_time per menu category
average item preparation_time per menu category
ticket time variability
slowest categories contributing to delays.

Stage 2 — Bottleneck Station Detection

Analyze station workload using curated.kitchen_order_items and, when useful, curated.kitchen_item_status_events.

Identify:

stations (device_id) with highest average item preparation times
stations causing queue buildup
structural bottlenecks in workflow between stations.

Stage 3 — Recall and Rework Analysis

Compute recall and rework signals using curated.kitchen_order_items and curated.kitchen_item_status_events.

Aggregate by:

station
category

Identify:

highest recall rate stations
menu categories with repeated rework
correlation between workload and recalls or stalled status progression.

Stage 4 — Rush vs Non-Rush Performance

Use order create_time to classify periods into service windows such as:

rush
non-rush

Compare:

ticket times
recall rates
station throughput

Identify degradation during rush periods.

Kitchen Optimization Insights

Kitchen Performance Dashboard:

Average ticket time: 18 min (target: 15 min)
On-time completion: 87%
Recall rate: 3.2%

Output Constraints

Use historical data from the last 90 days only.
Prefer aggregated summaries.
Avoid more than 3 database queries unless necessary.
Return kitchen performance insights only.
Do not include explanations, reasoning, or methodology.

Output Format

Return structured kitchen performance results.

Example structure:

Kitchen Performance:

Ticket Time:
Category: Burgers → 12.4 min avg
Category: Salads → 6.1 min avg

Bottlenecks:
Grill Station → highest delay contribution
Fry Station → peak congestion periods

Recall / Rework:
Grill Station → 3.2% recall rate
Fried Sides → highest rework concentration

Rush vs Non-Rush:
Rush: +35% ticket time increase
Non-Rush: stable performance