Lesson 03 of 05
Common Questions
Understand what our service provides, and what it does not
Five plain answers
- Yes, by comparison.
Does it show whether this copy changed?
Recompute the fingerprint under the same byte-processing rule. A mismatch shows this copy is not the same bytes; a match strongly supports that it is.
- Yes, with the retained evidence.
Does it support that the file existed by a chain record?
When the retained file reproduces the digest in the receipt's named transaction slot, the included Base transaction supports that the data existed in that form no later than that chain record.
- No — browser file flow.
Do you see my file?
The file body stays on your computer — the browser hashes it locally and sends the digest. Guest filename, size, and content type are off by default and reach us only if you opt to include them. A digest is not encryption: if a file’s contents are predictable, someone can test a guess against the published digest and learn whether it matches.
- No.
Does this prove I own the file, or that I made it?
No. A fingerprint carries no information about who. It shows this exact file existed by this date; who made it and who owns it are separate questions, answered by your raw files, your delivery emails and your contracts.
- No.
Does it prove what the file says is true?
Recording a fingerprint does not make the contents true. The evidence concerns the bytes and the chronology, not the truth of the statements inside.
Where the line is
Stays on your computer
The exact file body and everything readable inside it. The browser file flow reads those bytes locally rather than uploading them.
Can leave your device when you submit
The fingerprint — always
The outer file details
Guest notarization
Optional
Filename, size, and, when available, content type reach the service only if you opt in.
Account notarization
Always included
Quantum Notary records that external shell metadata for file management.
In the browser file flows described here, the service never receives or reads the file contents. Base calldata carries raw digest slots only — never the filename, type, size, topic, account, tenant, or service record ID.
A transaction may carry several digests. That reveals only that those records were submitted in the same short window; it reveals nothing about their contents.
Why it's narrow on purpose
A service cannot derive authorship, ownership, consent, or truth from a SHA-256 digest. What remains is narrower and checkable: retained bytes can be recomputed, a named slot can be read from Base, and the two can be compared. That is useful evidence precisely because it does not pretend to settle the questions outside it.
Technical version
A matching digest at the receipt's named transaction slot provides cryptographic and chain evidence. It does not establish identity, signature authority, authorship, ownership, consent, truth, confidentiality, storage, a complete chain of custody, or a legal outcome. Those require different evidence and, where relevant, qualified advice.