A screenshot isn't evidence: what "tamper-evident" actually means for your claim file

A host posts the screenshot in the thread, half-relieved: "I have it right here, the rule's in my listing, I screenshotted the chat where they agreed." The replies are gentle but the same every time: that screenshot is not the thing you think it is. It's a picture of text. Anyone, including you, could have produced it at any moment, including after the dispute started. That's the gap this post is about: the difference between a record that's merely there and one that's tamper-evident, where a reviewer can tell whether the text changed after the fact.

The word sounds technical. It isn't, really. You already trust tamper-evident things every day: the foil seal on a medicine bottle, the plastic ring on a milk cap. Neither stops a determined person. What they do is make interference visible. If the seal's broken, you know. A tamper-evident record does the same job for text. This is a plain-language walk through what that means for your file, written for a host, not an engineer.

"I have screenshots" is not "I have evidence"

Here's the intuition gap. To you, the screenshot feels like proof because you know it's real: you were there, you remember the conversation. But evidence isn't about what you know. It's about what someone who wasn't there can verify.

So: is a screenshot proof? On its own, no. A screenshot is an image, and images are trivially editable, and everyone reviewing disputes knows it. The same goes for a PDF you exported yesterday, or a house-rules document with the guest's name typed at the bottom. They share one fatal property: nothing about them is anchored to a moment in time you can't move. You could have written any of it this morning.

We covered the disclosure-versus-acknowledgment side of this in why AirCover claims get denied: a rule in your listing proves the rule existed, not that the guest agreed to it. Tamper-evidence is the next layer down. Even once you have an acknowledgment, the question becomes: can the reviewer trust that the acknowledgment in front of them is the one the guest actually made, unedited? A screenshot can't answer that. That's why it doesn't carry the weight hosts expect it to.

What a reviewer is actually weighing

Put yourself in the seat of whoever reads the file: an AirCover associate, a Resolution Center agent, eventually maybe a small-claims clerk. They have no way to know you. They've seen people exaggerate, misremember, and occasionally fabricate. So they read everything with one quiet question running underneath: could this have been changed after the dispute started?

That question is the whole game. If the answer is "yes, easily," the document gets discounted, no matter how genuine it is. Your honest screenshot and a doctored one look identical to a stranger, so both get treated as the weaker case. You're penalized for the format, not the facts.

A tamper-evident record flips the default. Instead of asking the reviewer to take your word that nothing changed, it lets the document answer for itself. The reviewer doesn't have to trust you. They can check. That shift, from "trust me" to "check it yourself," is what makes a record hold up. It's also the entire reason searches like airbnb evidence for claim tend to circle back to the same advice: get something that timestamps itself before the stay, not after.

The three things that make a record tamper-evident

Strip away the jargon and a tamper-evident acknowledgment comes down to three plain ingredients. None of them is exotic. They just have to be captured at the right moment, at signing, not reconstructed later.

A timestamp captured at signing

Not the date you exported the file. The date and time the guest actually completed the acknowledgment, recorded by the system at that instant, before they had the keys. A timestamp you can edit is worthless; the point is that this one is written down when the event happens and isn't yours to move afterward. It anchors the record to a moment that pre-dates the stay — which is exactly the moment a reviewer cares about.

A content hash

This is the one that sounds intimidating and isn't. A hash is just a short fingerprint of a body of text, produced by running that text through a fixed mathematical recipe. The same text always produces the same fingerprint. Change a single character (add a fee, edit a rule, swap a number) and the fingerprint comes out completely different.

So the hash doesn't lock the document. It witnesses it. You record the fingerprint at the moment of signing. Later, anyone can run the same recipe on the text in the certificate and compare. Match means the words are the same ones the guest agreed to. Mismatch means something moved. That's all "tamper-evident" means in practice: not that the text can't be changed, but that a change can't hide.

A signature bound to the packet

A signature the guest draws themselves, tied to that specific packet of rules and fees, not a checkbox, not a typed name that could sit under any document. Bound means the signature and the exact text it sat under travel together and are fingerprinted together, so you can't quietly swap the rules out from under a real signature.

Those three together are the foil seal. A timestamp says when, a hash says what, a drawn signature says who — and because they're captured together at signing, a reviewer can tell if any one was disturbed.

What it looks like on the certificate

This is where it stops being abstract. The PreArrive certificate carries a line, in plain sight, that ties those three things together. Simplified, it reads something like this:

Content hash (SHA-256): 7f3a…e91c
Opened:  2026-05-12 14:02 UTC
Signed:  2026-05-12 14:04 UTC
Verify:  scan the QR code on the certificate

Walk it left to right. The content hash is the fingerprint of the exact rules and fees the guest saw. SHA-256 is just the name of the recipe; you don't need to know how it works any more than how the foil seal is glued. The two timestamps capture two events, the guest opening the packet and signing it, both stamped before check-in. And the verify path means a reviewer doesn't have to take the certificate's word for it: scanning the code re-runs the fingerprint check against the stored record and reports whether the text still matches.

That's the difference from a screenshot in one picture. A screenshot says "here's what I claim happened." This says "here's what happened, here's the fingerprint of it, and here's how you check that I didn't touch it since." If you want to see a full one end to end, there's a clearly marked specimen on the proof page you can open and read — including the hash and the verification path, on a real certificate.

What tamper-evident is, and what it isn't

Now the honest boundary, because this is exactly the kind of feature it's tempting to oversell.

Tamper-evident means a reviewer can tell whether the text changed after it was signed. That's the whole claim. It is not a cryptographic vault, it is not unforgeable, and it does not make your case unbeatable. Hashes and timestamps are evidence, not magic. A sufficiently determined and technical bad actor isn't the threat model here, and no honest tool should pretend otherwise.

It is also not a verdict. A tamper-evident certificate doesn't decide the dispute or promise any particular outcome. Whether AirCover, an insurer, or a clerk is persuaded is their call, the same as it always was. A signed acknowledgment is an acknowledgment, not a contract.

What it changes is narrower and more useful than a guarantee. It removes the single easiest objection a reviewer can raise, you could have edited this, before they raise it. It moves your file from "a stranger has to trust you" to "a stranger can check you." That's a stronger file, and because the record is captured before the stay, it's a stronger file earlier, when the 14-day clock is running and you'd otherwise be assembling something under pressure.

That's the entire pitch, and it's a modest one. A screenshot asks to be believed. A tamper-evident record asks to be checked. On a contested fee, the second one is usually the only one that survives the read. If you want the mechanics of how the acknowledgment gets captured, the how-it-works page walks the ninety-second flow the guest sees, and the trust page covers the retention and verification side.