Exhibits: what gets appended to a job file

One list, one numbering

A job file export ends with an exhibits index, and, in the full record, the exhibit files themselves appended as pages. Both are driven by one ordered list, built once: the index is printed from it, and the appended files are fetched from it, in the same order. That is a deliberate piece of engineering discipline, because the failure mode it prevents is the worst one an evidence bundle can have: an index that says "Exhibit 4: Xactimate Estimate" while the fourth appended file is something else. The numbering in the index always matches what follows it.

What makes the list, in what order

The list is assembled from two sources:

1. Documents on the job, ordered by their document date: the estimates, invoices, and reports extracted for this job, each labeled by its type, for example "Xactimate Estimate" or "Insurance COI," with the vendor or sender as written on the document.
2. Attachments from linked emails, labeled "Email attachment" with the filename, dated by when the email arrived, and attributed to its sender.

Duplicates collapse: a file that was ingested more than once appears a single time. The index holds up to 60 exhibits, and each row reads the exhibit number, its label, its kind and date, its source, and whether it is "appended below" or "on file, not embedded."

What gets appended as pages

Only formats that can honestly become PDF pages are appended: PDFs are copied in page for page, and images (PNG and JPEG) each become a full page scaled to fit. Everything else, a spreadsheet, a video, an unrecognized format, stays index-only, labeled "on file, not embedded"; the index notes that such files can be produced on request. A divider page headed EXHIBITS separates the record from the appended files and states that the documents and images from the index follow in that order, as held in your systems.

The appended set is bounded so one pathological job cannot produce an unusable file: at most 20 files are embedded, and at most 30 MB of source material is fetched in total. Anything past those caps remains in the index, on file and producible, just not embedded in this PDF.

Fail-soft, by design

The merge is deliberately forgiving. A corrupt, unreadable, or oversized file is skipped, and the export continues: you still get the packet, with that exhibit listed in the index rather than appended. A single bad scan from three years ago never denies you the record of the whole job. If nothing can be appended at all, the document is simply the record plus its index, which is still complete as an index.

Fingerprints beside exhibits

Where the source system recorded a content fingerprint for a file, most commonly on email attachments, that fingerprint prints beside the exhibit in the index. If you later need to prove that a produced file is the exact one the index referenced, the fingerprint is the match: recompute it from the file and it either matches the printed value or it does not. Exhibits whose source recorded no fingerprint simply print without one; Verinode does not fabricate a fingerprint after the fact.

Data sources