Read the promise, not just the object

A lot of arguments start because one proof is asked to do too much work.

A delivery photo proves the package was dropped off. It does not prove the contents were complete. A receipt proves purchase timing. It does not prove the item stayed unused. A screenshot proves someone sent a message. It does not prove the person who needed it saw it in time.

I think this is why support tickets, return desks, roommate notes, and marketplace disputes all end up sounding weirdly similar. Everyone is holding a different piece of proof and pretending it answers the whole question.

The better move is to separate event proof from condition proof.

Event proof says something happened: delivered, paid, checked in, sent, received, assigned, picked up.

Condition proof says what state the thing was in when the decision was made: sealed, missing a part, already scratched, logged out, activated, expired, unavailable, wet, unread, locked.

That split sounds small, but it changes the argument. If a store rejects a return, the record should not only say return rejected. It should say the item was rejected because the inner seal was broken, the charging cable was missing, or the category rule treats opened hygiene packaging as not resellable. If a building manager charges for damage, the record should not only say damage found. It should say which mark was present before checkout, who observed it, and what photo or checklist supports the claim.

There is a trap here: condition proof can still be weak. A photo can be cropped. A checklist can be filled out late. A staff note can be vague. A timestamp can show when someone uploaded evidence, not when the condition existed. So the record needs a limit field, even if nobody calls it that.

For example:

- proof: delivery photo at 14:03
- shows: parcel placed at front door
- does not show: contents, seal, temperature, or who collected it
- decision it can support: delivery attempt completed
- decision it cannot support alone: item was undamaged or complete

That is much cleaner than arguing over whether the photo is good or bad. The photo is good for one claim and bad for another.

The same idea works for work notes. A deploy log proves a job ran. It may not prove the user-facing page updated if caching hid the change. A checklist proves someone ticked a box. It may not prove the room was checked after the last guest. A chat message proves a warning was sent. It may not prove the warning reached the person before they acted.

The useful record is not necessarily longer. It is just more honest about the claim.

My preferred shape is:

- What happened?
- What state is being claimed?
- What evidence shows that state?
- When was the state observed?
- Who observed it?
- What does this proof not show?
- Which decision used it?

That last question keeps the record from becoming trivia. Evidence matters because somebody uses it to accept a return, deny a refund, reopen a ticket, charge a fee, replace a part, or correct a previous note.

When those decisions are searchable later, the strongest record is not the one with the most attachments. It is the one that says exactly what each attachment can and cannot prove.

The photo only proves one thing

// COMMENTS

ON THIS PAGE