Before the board, a chute jam was found when somebody walked the line. After it, every jam surfaced within a second of the controller latching it. Over the four weeks that followed, first pass yield climbed every week, and the site created a standing role around the repeat-offender table.
Before the board, a chute jam at this site was found when somebody walked the line, or happened to catch it on a supervisory screen covering hundreds of chutes. A jam that sat unseen did not just stop a lane. Packages kept arriving, got recirculated or defected, and the yield number absorbed it.
This is the longest-running deployment in the set and the only one with a site KPI attached to it. The method it demonstrates is not diagnosis. It is what happens when a measurement that never existed gets created, kept honest under production conditions, and put somewhere a shift can act on it. Two of the receipts below are exports anyone with access can rerun. One of them is the site's own performance rollup, which stays offline. Which is which is stated with each number rather than after them.
What the board actually collects
Three parts, none of them clever.
A read-only collector polls each chute controller's jam word and its per-belt jam latches once a second over batched connections. Ten chute controllers, continuously, as a watchdogged service that restarts itself. Nothing on this path writes to a controller, which is what made a 24/7 collection loop acceptable to the site in the first place. At peak the wider monitoring path here batches roughly two thousand tags per cycle, including about 930 derived motor fault tags. The same read-only collection approach is described in more detail in reproducing a cloud starvation metric from 18 controller tags.
A historian stores each jam as an interval rather than an event: start, end, time to resolve, attribution to belt, downstream, or photo eye, and a shift label. Blocked-lane periods are stored the same way, as intervals with their own clear times. Storing intervals instead of alarm counts is the decision the entire production record rests on. An alarm log tells you a jam happened. An interval tells you how long it stayed.
A live board on the shift display shows active jams, the clear-time trend, shift performance, repeat offenders, and the health of the collector itself.
A jam now lands on the board within a second of the controller latching it.
The two honesty rules that shaped the build
A monitoring board that goes quiet when it breaks is worse than no board, because it converts an outage into a false all-clear. Two rules came out of that, and both cost more to build than the versions that would have looked identical on a good day.
The first: a dead feed can never render as "no jams." Configured, connected, and collector-stale are distinct operator-facing states with their own banners. The absence of jams and the absence of data do not look alike on the display.
The second: interval ends that happened while the collector was down are flagged, never inferred. If the service restarts across an open jam interval, that interval carries an uncertain-end marker instead of a plausible timestamp. Nothing back-fills. The alternative, guessing an end from the restart time, would have produced a cleaner-looking clear-time distribution and a dishonest one.
That second rule has a number attached to it now, further down the page, and it is the one we would point at first.
What changed on the floor after the board went live
The board went live mid-week 26. Adoption took a few days from there.
| Week | First pass yield | Note |
|---|---|---|
| 22 to 25 | 25 to 27% | Flat, pre-board baseline |
| 25 | 26.23% | Last full week before go-live |
| 27 | 28.81% | First full week of use |
| 28 | 30.34% | |
| 29 | 32.99% |
First pass yield rose 6.76 points from the last pre-board week to week 29, and it climbed every week in between rather than stepping once and settling. Over the same period the material handling defect rate fell 3% and the operations defect rate fell 4%, both measured as a share of total sort volume. Defect reduction and first pass yield were the board's stated goal going in, so this is the number the site chose to be judged on, not one selected afterward because it moved.
The receipt for that table is the site's own weekly performance rollup covering weeks 22 to 29. It is retained with the site records and quoted here rather than reproduced, as all raw site performance data is. That is a real limit on the table above and it is the reason the production record in the next section is kept separate from it.
The role the site invented
The change we did not anticipate is the organizational one. The site created a dedicated jam champion role, working the repeat-offender table to target the highest-occurring jam locations. The Pareto stopped being a report somebody generated for a meeting and became somebody's standing assignment. That is a better signal that the data is being acted on than any usage metric we could have collected, because it cost the site a headcount decision.
Who actually uses the board: the flow team, ten to twenty people per shift off the shared display; maintenance and operations associates and technicians on the same view; and operations managers on the blocked-lane scoreboard, which is what turned shift-versus-shift response into something two shifts could argue about with numbers.
The production record
Historian logging was switched on 13 July, two weeks or so after the board was already driving floor response, and the record below was exported on 28 July. That ordering matters for how the figures should be read. They measure the sustained state after the change, not the improvement itself. Everything in this table is reproducible from the historian's export endpoints.
| Measure | Value | Basis |
|---|---|---|
| Jam and fault intervals, first two weeks | 3,522 | 3,252 jams, 270 faults |
| Blocked-lane periods recorded | 187,448 | Same two-week window |
| Blocked lanes cleared inside the 15-minute target | 94.7% | 177,399 of the 187,405 periods with certain ends |
| Median blocked-lane clear time | 29 s | Same population |
| Median jam clear time, day versus night shift | 460 s versus 402 s | n = 1,697 and n = 1,815 |
| Weekly median jam clear time, first two full weeks | 389 s and 457 s | Now tracked automatically, week over week |
| Top repeat offender | 394 events | One chute, roughly 60% more than the next worst lane |
| Intervals flagged with an uncertain end | 5 of 3,522, or 0.14% | Collector restarts across an open interval |
The two clear-time figures are not the same measurement and should not be read against each other. A blocked lane clears in a median of 29 seconds because most blocks resolve themselves as the downstream drains. A jam takes a median of several minutes because a jam requires a person. The gap between 29 seconds and 460 seconds is the cost of needing hands, and it is the number the jam champion role exists to attack.
Two of the rows deserve to be pulled out of the table.
The blocked-lane response rate had no baseline. Nothing at this site measured lane-block duration before this, in any system. The honest claim is not that response improved by some amount. It is that the quantity became measurable at all, that 94.7% inside the 15-minute target is now a number somebody owns, and that the shift-versus-shift comparison has a denominator behind it.
The 0.14% uncertain-end rate is the data-honesty rule holding under production conditions. Across every collector restart in two weeks, five interval ends out of 3,522 could not be established, and all five are marked as such. None were filled in with a guess. That rate is the reason the rest of the table is worth quoting: the same discipline that flagged five ends is what produced the other 3,517.
On attribution, plainly
The yield result is correlational. One site, no control group, no holdout, and a board that went live at a moment the site chose rather than one we randomized.
What supports reading it as causal is the mechanism rather than the timing. Before the board, a jam was found when someone walked past it. After the board, every jam surfaced within a second of the latch, and both defect rates fell in the same window. That is a specific physical account of how the number would have moved, which is more than a coincidence of dates. It is still not a controlled experiment and we do not present it as one. A second site would settle more than any further analysis of this one.
The distinction we hold to is between the two receipts. The production record is an export. The yield movement is the site's rollup, held offline. Those are different grades of evidence and collapsing them would be the easiest way to overclaim here.
What a second site would take
The chute configuration the collector runs from is generated out of the controller exports rather than typed by hand, so standing this up somewhere else is a configuration exercise rather than a rebuild. The board itself runs as a self-contained application on a plant server, activated per site, without dragging the full engine along with it. That separation is deliberate: the reasoning work in Nexus is not what a shift display needs at three in the morning, and a board that inherits an engine's dependencies inherits its failure modes too.
None of that has been proven at a second site yet, which is the honest end of this section.