For Judges, Lawyers, and Evidence Reviewers

Go to creatorseal.app/verify. Enter the Seal ID. Select or drop the file into the verification area. CREATORSEAL™ calculates the file fingerprint locally in the browser and compares it to the fingerprint recorded in the sealed record. The result shows whether the file matches or does not match the sealed version. No technical expertise is required to run a verification.

A match means the file fingerprint calculated during verification is identical to the fingerprint recorded in the sealed record. This supports that the file being reviewed is the same file version that was sealed at that time. It supports the timing and integrity of that version. A match does not by itself determine authorship, copyright ownership, admissibility, or legal outcome — those are questions for legal counsel and the courts.

A mismatch means the fingerprint of the file being verified does not match the fingerprint in the sealed record. The file being reviewed is not the exact same file version that was sealed. This does not automatically mean bad faith or wrongdoing. Common reasons include reopening and resaving the file, converting it to a different format, applying a metadata change, or submitting the wrong version of the file.

Digital file fingerprinting works at the byte level. Reopening and resaving a file — even without changing its visible contents — can alter internal metadata or file structure in ways that change the fingerprint. Changing a single character, space, period, or formatting element changes the byte sequence, which changes the fingerprint. That is why the exact sealed file version must be preserved and handled carefully if later verification may be needed.

Best practice is to seal before each significant share, handoff, or delivery — not only the final version. Sealing early drafts, revision milestones, and delivery versions creates a lineage history that shows development over time. A party who sealed only the final version has one data point. A party with sealed drafts, revisions, and final versions has a documented timeline that may be more useful in context.

The Receipt of Provenance Record is a human-readable summary document associated with a seal. It typically includes the Seal ID, file name, file fingerprint, timestamp, and instructions for running a verification. It is designed to help reviewers identify the record and understand what was sealed. The receipt is a summary — the technical verification depends on the original file and the Evidence Bundle.

Lineage history is a series of related sealed records showing successive versions of a file over time. When a creator seals each significant version before sharing it, the resulting records can document the progression from early drafts to final versions. Lineage does not by itself prove authorship or ownership, but it can help make the development history of a work clearer to reviewers.

The Evidence Bundle is a portable documentation package associated with a sealed record. It may include the receipt, timestamp data, file fingerprint information, verification data, and related records depending on implementation. It is designed to give a third-party reviewer the materials needed to independently verify what was sealed.

Changes to the original file break the SHA-384 hash match — if even one byte changes, the file fingerprint will no longer match the fingerprint recorded in the sealed record, and verification will indicate a mismatch. Changes to the RFC 3161 timestamp token should break cryptographic verification, because the token contains the timestamp authority's digital signature over the timestamp data and altering signed fields causes the signature check to fail. Changes to human-readable proof text or notes may create inconsistencies or misleading documents, but they do not rewrite the signed timestamp evidence — independent verification against the original file and the timestamp token can expose those inconsistencies. The ZIP container is not inherently tamper-evident; the cryptographic check is whether the original file still matches the signed timestamp token, and whether that token verifies to a trusted timestamp chain.

No. CREATORSEAL™ documents that a specific file existed in a specific form at a specific time. It does not determine legal copyright ownership, which involves questions about authorship, jurisdiction, employment agreements, contracts, and other legal factors outside the scope of this system. Copyright ownership should be analyzed by qualified legal counsel.

A CREATORSEAL™ record may be offered as supporting documentation in a legal matter, but whether it is admissible, how much weight it carries, and what legal conclusions it supports are questions for the courts and the legal counsel involved. CREATORSEAL™ does not make admissibility determinations, and this page is not legal advice.