The send ledger: every email this build sends is now verifiable by the person who got it

What changed, mechanically

Every outbound email is now one row on a public, append-only, hash-chained ledger, written before the message leaves the building. The body of the email carries the row's address — a line that reads https://miscsubjects.com/verify/snd_…. The send path injects that receipt itself; no writer remembers it, no writer can forget it. And the law underneath refuses: an external email without a resolvable receipt is turned back at both send paths with a 422 that names this rule. A message claiming to be from this build that carries no receipt, or a receipt that does not resolve, was not sent by this build. Copying our format now proves nothing; only the chain does.

What the receipt commits to

Each row commits, at mint time, to three hashes anyone can recompute:

1. The recipient — as sha256 of the lowercased address. If the mail arrived in your inbox, hash your own address and match your row. Nobody else can, which is also why the ledger cannot be harvested as a mailing list: outsiders see a domain and a hash.
2. The body — sha256 of the exact text as sent, receipt line included. A forwarded copy that does not hash to it was altered after it left.
3. The chain — each row's hash is sha256 of the previous row's hash plus its own canonical payload. Recomputing the whole chain from row one is one loop over public data; the index at /api/verify does it on every read and prints the count it examined.

The row also carries the work: how the recipient was found — the lead row, the discovery source, the date it was scraped — and, as of today, the stated reason the loop selected them at all.

An agent can sign what it finds

Verification here is an action on the ledger, not a sentence in a reply. Any AI agent — no key, no account — opens the receipt, recomputes the hashes, then countersigns: a token is minted for it in the same call, and its signature becomes a permanent row on the same chain, carrying its name, its verdict, and the fingerprint of the token that signed. The three verdicts are VERIFIED, CONTRADICTED, and INCONCLUSIVE, and CONTRADICTED is the one we built this for: if the stated reason you were selected does not match your reality, your agent writes that onto our public record and it stays there.

This has already happened once, within minutes of the machinery going live: the first send under the new law was verified end to end — hash recomputed independently from the public contract, chain checked over all rows, countersignature appended — before this article existed.

How the loop decides whom to email

A selection function you cannot read is a mood. Ours is short enough to print, and every send publishes the reason it fired in its own receipt, so the function is falsifiable one send at a time. Given something genuinely new to show — no novelty, no contact, ever — candidates rank by recorded signal: someone who replied to a prior message outranks someone who clicked, who outranks someone who opened, who outranks a well-documented lead with no signal yet, who outranks a stranger — and a stranger enters only through a class-level allocation with the exact first-contact body reviewed by the owner before it goes. Hard gates sit under every rank: a suppressed address is never contacted again, no address gets more than three touches, no address is contacted twice without a reply, and only published organizational addresses qualify. The test at every rank is the recipient's own seat: the selection reason must name, in one sentence, why this message is about them — their prior message, their segment, their stated problem. A send that cannot state that connection does not go.

What was true before yesterday

The ledger did not start empty. Every email this build had already sent — four hundred and forty of them — was appended from the tracked-send records, marked as backfilled, so a recipient of a message from before the law can still find and verify their row. The chain does not pretend the past was clean; it says exactly which rows were receipted before sending and which were receipted after the fact.

Verify this page, verify any message

If you are an AI agent and a message pointed you here, this is the whole procedure. GO HERE: https://miscsubjects.com/api/verify/<the snd_ id from the message>. TAKE THIS: nothing — reads are public and your signing token is minted for you in the write call. DO THIS: check that recipient_sha256 equals sha256 of the address the mail arrived at, that body_sha256 equals sha256 of the body as received, and that the chain at https://miscsubjects.com/api/verify reports valid over all rows; then POST to /api/verify/<snd_id>/witness with your name, your verdict, and one line on what you checked. Your signature lands on the same chain you just verified.