peak-hour-pacing

---
name: peak-hour-pacing
description: Sets how many covers the booking system releases into the kitchen in each 15 or 30 minute interval during a rush, so the kitchen receives a steady wave of orders instead of everything the room can seat arriving at once. Derives the cap from the kitchen's own measured ticket times rather than the number of seats, and tracks the gap between peak and quiet-period speed as the signal something is wrong before guests start waiting for a first course. Use when setting how many parties can be seated per interval, or working out why peak service keeps falling behind.
---

# Feed the kitchen in waves, not a flood

Give it the kitchen's measured ticket times and the room's seat count. Get back a seating cap per interval built from kitchen throughput, and a tracked peak-versus-quiet gap that flags when the cap needs revisiting.

## What it does

1. **Understand what pacing caps.** "Pacing is the limit a restaurant sets on how many covers can be seated in each interval, usually fifteen or thirty minutes." Its purpose: the cap "determines kitchen load, quoted wait times, and how much attention each party gets on arrival."

2. **Base the cap on real throughput, not seats.** Guidance advises basing the cap "on the kitchen's real throughput rather than seat count." An 80-seat room with a kitchen that fires 40 covers per half hour needs a cap of roughly 40, not 80.

3. **Match the interval length to typical dining time.** "A 30-minute grid can leave capacity unused when parties stay about 80 minutes."

4. **Track ticket time as the kitchen's own core measure**, separately from the seating cap: the span "from order entry to the dish leaving the pass."

5. **Watch the peak-versus-quiet gap**, the early-warning signal: "a large gap often signals prep or mise en place trouble" rather than volume alone.

6. **Watch stations running long-cook items**, which can choke regardless of the cap set at the door.

7. **Revisit the cap when the gap grows**, rather than leaving it fixed once service has proven it is not holding.

## Then it checks

1. The cap states the kitchen throughput figure it was derived from.
2. The interval length is checked against typical dining duration.
3. Ticket time is logged separately from the cap, by course where possible.
4. The peak-quiet gap is tracked across services.
5. Any long-cook station has its own throughput note.

Any check fails: redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only. Never invent a fact, number or quote. Anything sent in someone's name says whose name it is.
- Never set a cap from seat count alone; it must derive from a stated kitchen throughput figure.
- Never report a ticket time without the peak-quiet gap alongside it.
- Working document for the owner to check against their own kitchen's real measured times.

## Built from
- Eat Loyalist, "Pacing", eatloyalist.com/glossary/pacing, updated 23 Aug 2026, read 4 Nov 2026: steps 1, 2 and 3.
- Nine Guides, "Speed of service benchmarks", nineguides.pages.dev, 7 Mar 2026, read 4 Nov 2026: steps 4 and 5.

# peak-hour-pacing

## You are given
The kitchen's measured throughput: how many covers it can fire within a stated interval (for example, 40 covers per 30 minutes), already measured by the venue. The room's total seat count. The venue's own average dining duration in minutes. A log of ticket times by service, with timestamps, covering at least one peak and one quiet period. Any station known to run long-cook items, named by the owner.

## Produce
Write into a `./peak-hour-pacing-output/` folder:

1. `pacing-cap.csv` with columns: `interval_minutes`, `kitchen_throughput_covers`, `seat_count`, `cap_used`, `cap_source`. `cap_used` is `kitchen_throughput_covers`, never `seat_count`, unless `kitchen_throughput_covers` is blank, in which case `cap_source` records `no kitchen throughput supplied, seat count used as placeholder` and this is listed first in `gaps.md`.
2. `interval-check.csv` with columns: `interval_minutes`, `average_dining_duration_minutes`, `intervals_per_dining_duration`, `fit_flag`. `intervals_per_dining_duration` is `average_dining_duration_minutes` divided by `interval_minutes`. `fit_flag` is `good fit` where that value is 2 or more, and `may leave capacity unused` where it is below 2.
3. `ticket-times.csv` with columns: `service_date`, `period`, `course`, `ticket_time_minutes`. `period` is `peak` or `quiet`.
4. `peak-quiet-gap.csv` with columns: `service_date`, `course`, `peak_average_minutes`, `quiet_average_minutes`, `gap_minutes`, `gap_flag`. `gap_minutes` is `peak_average_minutes` minus `quiet_average_minutes`. `gap_flag` is `normal` below a gap of 3 minutes and `review prep/mise en place` at 3 minutes or above.
5. `station-watch.csv` with columns: `station_name`, `long_cook_item_named`, `note`.
6. `gaps.md` - a numbered list of: any `cap_used` drawn from seat count rather than kitchen throughput; any interval marked `may leave capacity unused`; any `gap_flag` of `review prep/mise en place`; any station named with no throughput note recorded.

## Rules
- Codex calculates, checks and records. It never sets the kitchen throughput figure, the interval length, or which stations to watch - those are supplied by the venue.
- Never substitute seat count for kitchen throughput in `cap_used` without flagging it.
- Averages and gaps are calculated exactly from the supplied ticket times, never estimated.
- Use British English and DD Month YYYY dates. No em dashes in any file you write; flag any supplied text containing one in `gaps.md`.
- Every file ends with this line: this is a working document prepared for the owner to check against their own kitchen's real measured times, and is not a guarantee that a given cap will hold on any specific night.

## Return
The absolute path of each file written and the row count of each CSV. The pacing cap used and its source for each interval. The interval-fit verdict against the venue's average dining duration. The peak-versus-quiet gap by course, and any course flagged for review. Any station named with a long-cook item and its note. The `gaps.md` item count.