Symptom
A digital-delivery manifest referenced one PDF that did not exist.
The first suspicion fell on transfer. A missing file in a delivery ZIP often looks like a compression pattern, SFTP, or cleanup problem.
An operator asked an AI agent to investigate the failed production job. The agent compared the job folder, delivery ZIP, manifest, source input, archive metadata, sorted index, batch configuration, deployed PUB package, and approved Design objects. It did not send correspondence content or customer input to an external service.
The counts exposed the shape of the failure:
physical PDFs N
PDF entries in ZIP N
recipients in manifest N + 1
The ZIP contained every PDF present in the job folder. Transfer had not lost a file. The manifest had invented a reference to a file that the output layer never created.
Follow the reference backwards
The extra manifest entry and the final valid PDF shared the same business identity. The source input contained one corresponding document, and the archive metadata also contained one document.
That ruled out two independent source documents.
The investigation then moved upstream through the production path:
source document
-> presort records
-> sorted internal records
-> post-sort Exstream application
-> PDF output and delivery manifest
-> ZIP
-> transfer
The batch configuration proved that the ZIP step simply collected matching PDFs and the generated manifest. It could not add a filename to the manifest, and it could not package a PDF that did not exist.
Cause
The deployed Exstream application generated the delivery counter and the manifest entry in a queue rule.
The packaged logic was equivalent to:
if this is not a statistics document
and PrintOutput = "digital"
and print mode is enabled
then
increment delivery counter
build PDF filename from counter
append manifest recipient
include in queue
That rule assumed that every qualifying post-sort record represented one physical PDF.
The sorted index disproved the assumption. One source document could produce several internal post-sort records. More than one record carried the same customer and document identity. The queue rule advanced the delivery counter for those internal records, while the physical output boundary still produced one document.
The result was a referential-integrity defect:
manifest recipient -> generated PDF filename
One manifest reference pointed to a filename that no physical document owned.
Put the correction in the component that owns the invariant
The transfer system did not own the recipient counter. The ZIP step did not own filename generation. The sorting application produced repeated internal records, but the investigation found no evidence that it had duplicated a source document.
The primary correction belonged in the Exstream application that owned:
- the output queue rule;
- the delivery counter;
- PDF filename generation;
- manifest content;
- the decision that maps post-sort records to physical documents.
Changing the sort step first would have risked print ordering, grouping, archive output, and other queues without correcting the broken ownership rule.
Resolution pattern
Generate one manifest entry per physical delivery document:
if this record is eligible for digital delivery
and this is the first record for the physical document
then
create one shared document reference
use it for the PDF filename
use it for the manifest recipient
endif
Do not deduplicate on customer number. One customer can legitimately receive several documents in the same batch.
Use the same document or mailpiece identity that controls the physical PDF boundary. Confirm that identity against package metadata, Design definitions, and representative test data before changing the rule.
The strongest design uses one shared document-reference value for both output and manifest generation. Two counters that merely happen to advance together will drift again.
Regression invariant
Test single-record and multi-record documents, multiple documents for one customer, mixed queues, and a batch with no digital output.
Every successful case must satisfy:
number of generated PDFs
= number of manifest recipients
= number of PDF entries in the delivery ZIP
Also confirm that each manifest filename exists exactly once in the ZIP.
Evidence the agent assembled
Searching for the missing filename only confirmed the symptom.
The agent compared counts at each boundary, ruled out the downstream components, inspected the actual packaged rule, and matched repeated internal records back to one source document. It then assigned the correction to the application that owned the broken relationship.
The operator owned the decision. The preserved evidence and rejected explanations made that decision faster to review.
Inspect the rules and output definitions inside an Exstream PUB package.