The row is the production log
A station resolves its in-flight row with the run's result, so the work queue is also the record of what was produced and how long it took.
The situation
Each machine run opens a running row and closes it when the run ends. Reporting later needs every completed run, which station ran it, the result and the duration.
The recipe
await lt.escalations.resolve({ id: runRowId, resolverPayload: { result: 'success' }, metadata: { outcome: 'success', unitsProduced: 6 },});ltc esc list --role cell-a --status resolved --facets '{"outcome":"success"}' --jsonThe resolver payload wakes the workflow. The metadata patch is the durable record on the row. The row’s own created_at and resolved_at bound the run.
The guarantee
There is no side table to keep in step: the outcome lands in the same atomic update that closes the row. The lt_escalations view adds ended_at, the instant the row left the live set, so every row is one interval [created_at, ended_at) that the analytics surfaces read directly. See Data model.
Related patterns
Resolving from anywhere
Intent on create, outcome on resolve
The row is created with the facets that route it and resolved with the facets that describe what happened. One row answers both questions.
Analytics
Park every state
Each state an item passes through is one escalation row. The queue becomes a complete time series of the process with no extra instrumentation.
Analytics
Dwell and membership
One call answers how long entities spent in each state over a window, or how many are in each state right now.
The queue as a market
Lot traceability by containment
Stamp the lots each unit consumed onto its row as an array facet. Every row that used a lot is then one containment query.