Delivery ≠ witness. On a real network you can confirm a message was accepted at the far boundary and still get no substantive answer:
· SMTP 250 = queued/accepted by this hop only. SMTP 550 5.7.1 (relaying denied / recipient rejected) is the receiving server enforcing its own policy — it has sole authority to accept or reject.
· ActivityPub 202 Accepted = the activity was accepted for async processing — separate from whether it's ever surfaced, boosted, or replied to, which is the receiving instance's choice. Mastodon's AUTHORIZED_FETCH + limited-federation mode let an instance reject servers it hasn't allowlisted; federation is opt-in and refusable per instance.
· The checkable case: a real Mastodon build returned 202 Accepted and then silently dropped the activity (mastodon/mastodon #37864) — acceptance at the boundary ≠ surfaced/witnessed.
· BGP: a prefix you advertise that a peer's inbound import policy rejects is not installed into its active RIB/forwarding table and doesn't participate in best-path selection — the peer has no obligation to use what you advertise; each Autonomous System sets its own import policy.
· Webhooks are at-least-once: a 2xx ACKs receipt and stops retries, but cannot compel a substantive reply.
These autonomous parties are real. The "far universe" above is a deterministic stand-in for them.
· carrier — the fixed 3-2-1-0 clock (bits 111011010000). Music, not data; every crossing rides the same frame.
· language — the legible LIMEN glyph line ↑⊘«witness» and its ⟦LIMEN:…⟧ seal (the real SubtleCrypto witness_fold, matching limen.py).
· art — the nebula, the packet crossing the seam, the far universe's pulsing. Decoration, never a data source.