"Seal your file" gets used as a single action, but it is really three separate things happening at once, each answering a different question a dispute might ask later. Knowing what each piece actually does makes it clear why the result holds up in a way that a saved copy or a screenshot does not.
Step one: the file is hashed
A cryptographic hash function reads the exact bytes of your file and produces a fixed-length string unique to that content. Change a single character, a single pixel, one line of formatting, and the hash comes out completely different. The hash does not store or reveal the contents of the file. It is a fingerprint: nobody can reconstruct your document from it, but anyone holding the original file can recompute the same hash and confirm it matches.
Step two: you add a declaration
The declaration records how the work was made: human authored, AI-assisted, or AI-generated, along with whatever category fits the content. This matters for two reasons. It gives future readers, or a court, an honest account made at the time of creation rather than reconstructed later from memory. And under the EU AI Act's Article 50 transparency obligations, a clear, contemporaneous declaration is exactly the kind of record that labelling requirements are asking for.
Step three: the qualified timestamp is issued
The hash and declaration are bound to a timestamp issued by Swisscom Trust Services, a Qualified Trust Service Provider accredited under both ZertES in Switzerland and eIDAS in the EU. This is not your device's clock. Under eIDAS Article 41, a qualified timestamp carries a legal presumption of accuracy, for both the date and time shown and the integrity of the data it is bound to. That presumption is what a plain file-modified date, set by whatever software last touched the file, can never carry.
What you're left with
The result is a certificate: a record of the hash, the declaration, and the qualified timestamp, retrievable later through a public verification link. Anyone holding the original file can recompute its hash and check it against the sealed record, with no login and no need to contact whoever sealed it. If even one byte of the file has changed since sealing, the hashes will not match, and that mismatch is itself the finding.
Nothing about this process depends on trusting the platform the file happens to be sitting on today. The hash, the declaration, and the qualified timestamp travel with the record, independent of wherever the file is stored or shared next.
