One check I built catches page-level defects inside a mail piece: a statement that should be four pages
and printed three, a duplicated page, a page index out of range. It reads a printed keyline — the little
control line like 04 01 meaning "page 1 of a 4-page piece" — groups pages into pieces, and verifies each
piece is whole. Good for the inside of a piece.
It is completely blind to a worse defect: an entire piece that never exists. Account 100238 was in the
input file and 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, sort, walk the list for gaps — breaks on real mail.
Production streams are presorted: reordered into carrier walk sequence for postal discounts. Pieces
arrive deliberately out of order, so "the next serial is smaller than the last" is the normal, correct
state, not an anomaly. Any check that assumes ordering drowns a presorted run in false positives.
So the check has to be order-independent. Treat the serials as a set and ask set questions: within the
observed range, is every expected serial present exactly once? That reframes the problem 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 few conditions fall out cleanly:
- piece missing — a serial absent from inside the observed range
- piece duplicate — the same serial on more than one piece
- out of range — a serial outside the declared bounds
- count mismatch — a total that doesn't match what was declared
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 missing one, 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 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. Same
rule as everything else: the limit of what the data can prove is reported, never papered over.
Full write-up (with how it reuses the same keyline as the page check):
https://preflightdocs.com/blog/detecting-a-missing-mail-piece?utm_source=devto&utm_medium=article&utm_campaign=piece
The free analyzer: https://preflightdocs.com/?utm_source=devto&utm_medium=article&utm_campaign=piece
Top comments (0)