Engineering · 2026-07-15
A recipient who gets nothing
Detecting a whole missing mail piece across a run — the defect a page-level check can’t see, and why finding it means order-independent set-continuity, not a sorted scan.
A previous check we built catches page-level defects inside a piece: a statement that should be four pages and printed three, a duplicated page, a page index out of range. It works by reading a printed keyline — the little control line like 04 01 meaning “page 1 of a 4-page piece” — and grouping pages into pieces. Good for the inside of a piece.
It is completely blind to a different, worse defect: an entire piece that never exists. Account 100238 was in the input file and simply produced no output — no pages, no keyline, nothing to group. The run looks internally perfect. Every piece that printed is complete. And one household gets silence where a statement, an EOB, or a legally-required notice was supposed to be.
Why you can’t just sort and scan
The obvious approach — collect every piece’s serial number, sort them, walk the list looking for gaps — breaks on real mail. Production streams are presorted: reordered into carrier walk sequence for postal discounts. The pieces arrive deliberately out of order, so “the next piece has a smaller serial than the last” is the normal, correct state, not an anomaly. Any check that assumes ordering will drown a presorted run in false positives.
So the check has to be order-independent. It treats the serials as a set and asks set questions: within the observed range, is every expected serial present exactly once? That reframes the whole thing away from sequence and toward continuity of a set — which is what actually matters. Nobody cares what order the pieces printed; they care that everyone who should have gotten one, did.
The findings — and the honest one
From the set of per-piece serials, a handful of conditions fall out cleanly: a serial missing from inside the observed range (piece missing), the same serial twice (piece duplicate), a serial outside the declared bounds (out of range), and a total count that doesn’t match what was declared (count mismatch). Per client, you choose whether serials must be strictly contiguous or merely unique.
The subtle one is the boundary. If the very first or very last piece of a run is the one that’s missing, the gap is invisible — there’s nothing beyond it to reveal a hole. You cannot detect a missing edge from the data alone; you need an external anchor: a declared expected range or expected count. So when a run’s edge can’t be proven either way, the check doesn’t quietly assume it’s fine. It emits a coverage disclosure stating exactly what it could and couldn’t guarantee, and points at the declaration that would close the gap. The same rule as everything else we build: the limit of what the data can prove is reported, never papered over.