For document delivery, content analysis begins with a precise question: did each intended recipient have the correct document, and what evidence exists for the next steps? Reconcile the expected batch with files and events before reporting a completion rate.
Keep documents and events separate
Statement and report-delivery systems, including the INSCI ESP+ system announced in 2004, combine document handling with delivery reporting. A useful analysis preserves the difference between what should exist, what actually exists and what happened to it.
Use a batch ID plus a document ID, expected version and recipient reference as the expected-document key. An available-file inventory adds a unique file ID and location. An event log adds an event ID, event type and time. Use opaque recipient references in working reports and keep the authorized identity mapping protected.
| Event | Supported interpretation | Remaining question |
|---|---|---|
| Created | The service reports generation of a file. | Does the correct version exist and open successfully? |
| Dispatched | The service accepted or attempted a send operation. | Did the receiving system accept it? |
| Delivered | For email, the receiving mail server accepted the message. | Did the intended person read the correct document? |
| Bounced | A delivery failure was reported. | What needs correction before a controlled retry? |
| Accessed | A request or tracking event was recorded. | Was it a person, a proxy or an automated process? |
| Acknowledged | The defined acknowledgment action was recorded. | How was identity bound to the action and document version? |
Amazon SES event definitions distinguish sending from delivery to a recipient’s mail server. Its metrics FAQ explains open tracking and its limitations. Define the semantics of your own service before interpreting similarly named fields.
Reconcile the fictional six-document batch
The downloadable sample is batch B-01. It expects D-01 through D-06, each at version 1, for recipient references R-01 through R-06. Times are UTC on October 4, 2026; the observation window ends at 12:00. All six require acknowledgment by that cutoff in this invented exercise.
There are six file rows, but D-05 is absent and D-04 appears twice with distinct file IDs. Thus five expected document keys have at least one matching file: 5 / 6 = 83.3% availability. Four keys have exactly one file. Counting six file rows as six completed documents would hide both exceptions.
| Document | Files / delivery evidence | Next action |
|---|---|---|
| D-01 | One file; dispatched, delivered, accessed and acknowledged. | Retain the linked evidence. |
| D-02 | One file; dispatched, then bounced. | Resolve delivery failure before retry. |
| D-03 | One file; dispatched and delivered; acknowledgment absent. | Follow up using the agreed acknowledgment process. |
| D-04 | Two files; no delivery events. | Resolve the duplicate and select the authoritative file. |
| D-05 | No file and no delivery events. | Investigate missing generation. |
| D-06 | One file; dispatched, delivered and accessed; acknowledgment absent. | Follow up; access alone leaves acknowledgment outstanding. |
Four expected keys have dispatch evidence, three have delivery evidence, one has a bounce and one has acknowledgment. Five expected keys lack acknowledgment. These measures overlap: a bounced item is also dispatched, and an acknowledged item is also delivered. Add counts only when the categories are explicitly mutually exclusive.
Use a repeatable reconciliation sequence
- Freeze the expected manifest and observation cutoff. Confirm the expected keys are unique.
- Match files on the full key. Flag absent keys, multiple files, wrong versions and files outside the expected population.
- Deduplicate repeated event records by event ID. Keep separate real retries and flag events whose document key is unknown.
- Apply the cutoff and each event’s documented meaning. Count distinct expected keys for each metric, keeping file and event counts available separately.
- Assign exceptions to owners with an action and due date. Preserve the original observations and record corrections in a new run.
A missing event means evidence is absent from the selected log and time window. Check event-feed completeness, clock conventions and delayed ingestion before concluding that an action never occurred. Report unresolved evidence gaps alongside the counts.
Work through the sample and adapt it
- Expected documents (CSV)
- Available files (CSV)
- Delivery events (CSV)
- Field definitions, checked totals and exception worksheet (plain text)
Import the CSVs as UTF-8 comma-separated text. Keep identifiers and ISO timestamps as text while inspecting the sample. The instructions define every field and the exact counting rules. The files contain fictional records and static observations; they do not send messages or query a delivery service.
For an operational report, agree the expected population and acknowledgment rule with the service owner. Choose a follow-up deadline, protect recipient information and retain evidence under the applicable records policy. Technical logs support an investigation; any legal conclusion about notice or receipt requires the relevant legal and procedural context.