Your client went quiet after delivery. The record did not.

The work is delivered, the invoice is sent, and then: nothing. No acceptance, no complaint, no reply. Ghosting is expensive for a specific reason: the usual proof of delivery lives in the same threads the client has stopped answering, so your evidence and their silence occupy the same inbox. A delivery record moves the proof somewhere their silence cannot reach. When the work ran through Zambo, the verifiable work layer for AI, the delivery sits at a public link with every step timestamped, and its acceptance state reads pending, which is their silence, documented.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup. Start a real one on the handover page.

Published October 17, 2026. Every record quoted below was read live from zambo.dev on the day this page was written. Updated October 17, 2026. Written against AER-1, IETF Internet-Draft revision 23: draft-zambo-aer1-23. AER-1 is an IETF Internet-Draft, not a finalized standard.

Why ghosting is hard to fight with an inbox

The classic delivery trail is scattered by design: a file in one thread, a link in another, a "sent it Tuesday" in a third. Each piece is real, and together they still argue badly, because every piece is a claim you are making about your own sending. The client's counter is one word, never got it, and there is no neutral ground to settle the difference. What settles it is a delivery that exists independently of both inboxes: complete before the silence started, unchanged since, and openable by anyone either side brings in.

What the record shows without the client

  • The delivery itself. One handover link: the goal, then every step of the work in order, each step carrying its own verifiable receipt. The packet was complete at the moment of delivery and reads the same today.
  • The times. Each step's receipt was saved when the call ran, so the delivery has a timeline made during the work, not reconstructed during the argument.
  • The state of the decision. The acceptance record next to the handover reads pending, decided by nobody yet, release hint hold. That is not a gap in your evidence; it is the precise, boring fact of the situation, recorded by the system instead of alleged by you.
  • The checkability. Anyone, a mediator, a platform reviewer, the client's own partner, can open the link and verify the steps without your account and without asking the client anything.

Worked record: five steps delivered, decision still pending

The ghosted delivery, on record

Handover bd7e5325 delivered five steps on October 16, 2026, their receipts saved between 14:33:42 and 14:34:01 UTC as the calls ran. Its acceptance record reads: five of five steps checked, status pending, release hint hold. (Stated plainly, because the record states it plainly: this delivery's steps carry no AI producer label; the field reads unknown, exactly as recorded.) The client has never decided, and the record does not need them to. Delivery: proven. Decision: outstanding, and visibly theirs.

The twin that got answered

Handover 45434a17, delivered the same day, reads at its acceptance record: status accepted, decided by the client, four of four steps checked, release hint ok_to_release. Same system, same shape of delivery. The only difference between the two records is whether the client acted, and each record says which, in so many words. That is what you send a ghosting client: not a complaint, a state.

The one follow-up that uses the record

Send it once, short, with no heat in it:

"Delivery record for the project: [handover link]. Five steps, each with its receipt, delivered October 16. The acceptance state is pending, which means it is waiting on your decision: accept it there, or flag the step that fails and I will address that step. The review window in our agreement runs from the delivery timestamp."

Every sentence in that message is checkable by the person reading it, which is the entire difference from the usual chase email. If the silence continues, the same link goes to whoever adjudicates: the platform, the mediator, the court. It is the exhibit, already assembled.

What the record cannot do

  • It cannot make the client pay, reply, or accept. The record is evidence, not leverage over a person. Getting paid may still take a process; this is what you bring to the process.
  • It cannot prove the client opened the link. Delivery is provable; reading is not, and any tool promising read-proof for a link is selling you a claim it cannot back.
  • It cannot prove the work was good. A receipt proves the saved result of a call has not changed since it was saved. If the client eventually engages and disputes quality, the argument happens against the record, which is a better argument to have, but it is still an argument.

Questions, answered

My client ghosted after I delivered. How do I prove I delivered it?

Point at the record, which does not need the client to cooperate. When the work ran through Zambo, the delivery is a handover: the goal, every step with its own verifiable receipt and timestamp, behind one link that exists independently of the client's inbox. The acceptance state sits next to it and reads pending until the client decides, which means their silence is recorded as a state of the record, not a hole in yours. Send the link again with the state line: delivered on this date, these steps, acceptance pending. If the dispute ever reaches a mediator, a platform, or a court, the same link is the exhibit.

The client says they never received the work. What settles it?

The record, because it was never in their inbox to lose. A handover is a page, not an attachment: it was complete at the delivery timestamp, its steps carry receipts saved when the work ran, and re-sending the link shows exactly the same contents, because a receipt's saved result has not changed since it was saved. Never received can be true of an email. Of a delivery record it can only mean never opened, and the record separates the two claims cleanly.

Does a pending acceptance mean I did something wrong?

No. Pending is the default state of every handover until the client makes the decision only they can make. An accepted record and a pending one can describe identical work; the difference is the client's act, and the record names it precisely: decided by the client, or not yet decided at all. Read the two worked records below: same shape, one accepted on the day, one still pending. Pending documents their silence. It says nothing against the delivery.

Can I prove the client opened the delivery?

No, and be suspicious of any tool that promises read-proof for a link. What the record proves is stronger in the ways that matter: the work existed in complete, checkable form at the delivery time, the steps were saved as they ran, and the acceptance has been waiting on the client's decision since. Delivery you can prove. Reading you cannot, and a dispute turns on delivery.

How do I set up the next job so ghosting costs me less?

Deliver as a record from the first step, and write the silence into the contract before the work starts: delivery defined as the handover link, a review window counted from its timestamp, and what happens when the window closes without a flag. The contract page on this hub has the clauses. On the Zambo side: for $0.99, send the next delivery as a handover with the acceptance state running, so silence has a record too: get the Day Pass. A Day Pass covers 24 hours, and ongoing use is the Zambo Pass at $29 a month or $290 a year, $19 a month for $ZAMBO holders.

Related