# Email notification evidence worksheet

Companion guide: /learn/explain-email-delivery-status
Fictional source journal: /learn/resources/email-event-journal.json

This is an editable planning exercise. No real addresses, subjects, payloads, secrets, recipients or provider calls belong in it. All example times are November 4, 2026 UTC. `example-mail` and its envelope are illustrative, not real provider payloads. Nothing here establishes email delivery, inbox placement, human reading or server permissions.

## 1. Freeze the meanings

Provider and documentation date: ______
What does a successful request response mean? ______
What exactly does its delivered event establish? ______
Which evidence remains unknown? ______
Who may inspect raw events and export them? ______
Which authenticated recipient may see which status? ______
What server-side denial tests will check that boundary? ______

For the filled example, accepted request means delivery unknown until supported by later evidence. Provider `sent` maps to Send accepted; `delivery_delayed` maps to Delayed; `delivered` maps to Server delivery reported; `bounced` maps to Rejected; `failed` maps to Send failed. Opens are separate signals. Human reading, inbox placement and business completion are unknown throughout.

Missing event time or an unrecognized type means Review needed. Distinct outcome types for the same message also mean Review needed, preserving all evidence. One outcome is sticky against progress reports. Without an outcome, latest event-time progress applies; differing progress at equal times needs review. These are proposed conservative exercise rules, not universal provider precedence.

## 2. Distinguish identity

| Notification | Business action | Provider message | API attempts | Same key / payload identity |
| --- | --- | --- | --- | --- |
| M1 | BA1 | PM1 | A1 accepted at 10:00:05 | notification/BA1 / fictional-notification-BA1 |
| M2 | BA2 | PM2 | A2 accepted at 10:00:05 | notification/BA2 / fictional-notification-BA2 |
| M3 | BA3 | PM3 | A3 accepted at 10:00:05 | notification/BA3 / fictional-notification-BA3 |
| M4 | BA4 | PM4 | A4a timeout at 10:00:05; A4b accepted at 10:00:20 | notification/BA4 / fictional-notification-BA4 |

All four app-queue timestamps are 10:00:00. The exercise begins after the accepted responses. M4's response is stipulated; it is not a promise that any live retry is safe. Five attempts do not create five notifications. A receipt ID identifies your observed copy of an event. A provider event ID identifies the event being copied.

## 3. Replay the main journal

| Receipt | Event / provider message | Type | Event time | Received time | Expected handling |
| --- | --- | --- | --- | --- | --- |
| R1 | E1 / PM1 | sent | 10:01:00 | 10:01:01 | Retain |
| R2 | E2 / PM1 | delivered | 10:02:00 | 10:02:01 | Retain |
| R3 | E3 / PM2 | bounced | 10:02:20 | 10:02:21 | Retain |
| R4 | E4 / PM3 | delivery_delayed | 10:03:00 | 10:03:01 | Retain |
| R5 | E2 / PM1 | delivered | 10:02:00 | 10:04:00 | Exact duplicate event; retain receipt |
| R6 | E5 / PM3 | delivered | 10:08:00 | 10:09:00 | Retain |
| R7 | E6 / PM3 | sent | 10:01:00 | 10:10:00 | Retain older progress; no downgrade |
| R8 | E7 / PM1 | opened | 10:04:00 | 10:11:00 | Retain separate signal |

Deduplicate on provider + event ID, then compare immutable message/type/event-time content. Reusing the same event ID with different content must reject without changing the prior result. Receipt ID and received time are allowed to differ for a duplicate. Unknown provider/message IDs, duplicate receipt IDs and malformed times are errors; explicit null event time is retained as Review.

## 4. Complete the answer key

Abbreviations below: U = Delivery unknown, S = Send accepted, D = Server delivery reported, B = Rejected, L = Delayed, R = Review needed. This is an expected-state key, not an observed app result.

| Through receipt | M1 | M2 | M3 | M4 | Receipts / unique events / duplicates |
| --- | --- | --- | --- | --- | --- |
| 0 | U | U | U | U | 0 / 0 / 0 |
| 1 | S | U | U | U | 1 / 1 / 0 |
| 2 | D | U | U | U | 2 / 2 / 0 |
| 3 | D | B | U | U | 3 / 3 / 0 |
| 4 | D | B | L | U | 4 / 4 / 0 |
| 5 | D | B | L | U | 5 / 4 / 1 |
| 6 | D | B | D | U | 6 / 5 / 1 |
| 7 | D | B | D | U | 7 / 6 / 1 |
| 8 | D | B | D | U | 8 / 7 / 1 |

At checkpoint 4, the four buckets each contain one message. At final main, D contains M1/M3, B contains M2 and U contains M4. Open signals total one on M1; no other message has an open signal. The denominator remains four notifications. All seven state-bucket counts must sum to four, and their drill-down IDs must appear exactly once.

Counterexamples are separate branches after receipt 8:

| Branch | Additional receipt 9 | Expected message states | Counts and retained evidence |
| --- | --- | --- | --- |
| Conflicting outcome | E8 / PM1 bounced at 10:12, received 10:13 | R, B, D, U | One per listed state; 9 receipts / 8 events / 1 duplicate. Preserve E2 delivered and E8 bounced. |
| Missing time | E9 / PM4 sent at unknown time, received 10:13 | D, B, D, R | D2 / B1 / R1; 9 receipts / 8 events / 1 duplicate. Preserve E9 with null time. |

Do not combine the two branches. Human reading remains unknown in both.

## 5. Record your own review without sending

| Case | Message ID | Evidence IDs / event times / received times | Label expected | Exact customer/staff copy | Unknown or conflict preserved | Observed result and evidence |
| --- | --- | --- | --- | --- | --- | --- |
| Accepted only | | | | | | Not run |
| Delivered report | | | | | | Not run |
| Duplicate event | | | | | | Not run |
| Older late event | | | | | | Not run |
| Conflicting outcomes | | | | | | Not run |
| Missing timestamp | | | | | | Not run |
| Open signal only | | | | | | Not run |
| Different recipient / signed-out access | | | | | | Not run |

Proceed with the fictional disconnected screen when its labels, four-message counts, drill-downs and exports agree. Hold a real connection if provider semantics, authenticated event handling, retry scope or access restrictions remain unresolved. Review conflicting evidence rather than choosing the most convenient result. Never resend merely to make an unknown label disappear.

The local aid can export its selected fictional prefix as JSON; this file is not an import format for Overskill or a provider. Use the existing Overskill brief builder to describe one status screen. Supply the fictional journal separately, edit the builder's input fields and review the complete generated brief before Start build. The link does not carry the journal or this worksheet into a project.