Local durability is not model delivery

A paperclip can imply more than a system completed. Muniment Desktop stores attachments durably, while its interface says the model received nothing.

Our Desktop evidence covers ingestion, projection, live conversation results, and restored history. Each path keeps local persistence separate from model delivery.

The bytes get a durable local identity

The implementation writes attachment bytes to a content-addressed local store. Their content determines the storage identity, so identical bytes resolve to the same address.

The journal records only the durable attachment record. It does not copy the attachment bytes into chat history.

Chat receives a narrower projection with three fields:

1. The display name.
2. The byte length.
3. The optional media type.

That projection omits the source path and content hash. Chat can describe the saved attachment without exposing local storage details.

One status names the completed boundary

Both the live conversation and restored history show the same interface status: Saved locally · not sent to model.

Every word matters. “Saved locally” reports completed persistence. “Not sent to model” rules out a delivery claim that the implementation cannot support.

Contract tests cover ingestion, projection, live results, and restored history. They check that the durability record and interface boundary survive replay.

Local durability stops before delivery

This evidence does not demonstrate upload, provider delivery, or model consumption. Those paths were not implemented in the source work.

It also does not claim public install access. Visitors cannot exercise Muniment Desktop through a public install or authentication surface yet.

The record comes from our Muniment Desktop note pinned to commit 202d9b87763c2ced4c206f2b127502e2c55407ef.

Attachment state should name the boundary the system crossed. Intent belongs in the request. Completion belongs in the record.