"Did they get it?" is the question RelayLink exists to answer honestly. That honesty depends on never confusing three different events.
Three things that are not the same
A magic-link fetch. Something requested the /p/{token} page — a person, a mail scanner, a link previewer, a corporate filter. Treating that as "read" would put a false signal on the one screen a sender consults. So it is recorded for diagnostics and never shown to them.
A portal view. You opened the package while signed in. Same rule: recorded, not shown, drives nothing in the inbox badge or thread state. "Acknowledged" can still mean a person pressed a button rather than "a page was rendered."
An acknowledgement. acknowledge_package through an assistant, or the acknowledge control in the portal. Deliberate. Visible on the sender's trail. A sender cannot acknowledge their own package. Doing it twice does not create two claims.
What the sender's trail actually shows
Sent. Notification accepted or failed. Opened by the recipient's assistant — that is get_package — shown only when the recipient shares read receipts with you. Acknowledged. Replied.
Link fetches and portal views are omitted on purpose. An "we tried to send email" event is omitted too: an accepted or failed event always follows it, so showing all three makes one send look like three things.
The account export uses the same list. The other side's fetches do not travel with it.
The recipient decides whether "opened" reaches you at all
A pull is still recorded the instant it happens — it is the recipient's own unread state, and that never changes. Whether it is shown to you is a separate question the recipient answers, account-wide or for one person specifically: turn read receipts off and every pull from then on reads as "read receipts not shared" instead of "opened" or "not seen yet." The two unopened-looking answers have to be indistinguishable, or the setting would leak the very thing it exists to hide — a sender who noticed replies arriving to briefings still marked "not seen" would work out the pattern soon enough. Acknowledging is untouched by any of this: it is a deliberate act the recipient chose to make visible, not a passive trace of an assistant fetching something, and it always shows.
Why a pull still matters
When an assistant calls get_package, that is a claim the recipient's assistant fetched the briefing. thread_status uses it. That is why outbound webhooks carry an envelope and never the prose: a consumer that acted on webhook content without pulling would skip the event the sender relies on.
A human reading in the portal must not mint that claim. Otherwise acknowledgement would be redundant, and a browser open would look like an assistant pull.
When someone says they never got it
Start with the boring explanations — wrong address, spam folder, filter — before reading the trail as a verdict. They say they never got it is the order worth checking. The trail tells you what RelayLink attempted and what a deliberate recipient act recorded. It does not tell you what landed in a mailbox.
If you read something and want the sender to know, acknowledge it. If you only opened the page, you have not told them yet. That is the feature working.