The list and the badge agree

The queue as a marketDashboardHTTPSDKjeopardypriority_threshold_minutespriority_facetgetStationMetrics

The at-risk count on the Pace Board and the list it links to run the same SQL predicate, so the list always holds exactly that many rows.

The situation

A board shows “7 at risk” on the packing station. A supervisor clicks it and sees 6 rows, or 9. Trust in the board is gone after the first mismatch.

The recipe

curl -X PATCH https://lt.acme.dev/api/roles/packing \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{ "priority_threshold_minutes": 120, "priority_facet": "promisedAt" }'

curl -G https://lt.acme.dev/api/escalations \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode 'role=packing' --data-urlencode 'jeopardy=1'

/escalations/available?role=packing&jeopardy=1&view=table&orderBy=[{"field":"metadata.promisedAt","direction":"asc"}]

Age runs from the priority_facet timestamp on each row, or created_at when unset, against priority_threshold_minutes, or sla_minutes when unset.

The guarantee

The station metric priority_count and the jeopardy filter are one expression, so a jeopardy list’s total always equals the badge that linked to it. Roles with no threshold contribute no rows. See Faceted routing.

The queue as a market