Sealed submission
Sealed submission: a working definition for claims and operations teams
A sealed submission is a package of evidence, the files, the answers and the session record, bound together and cryptographically signed at the moment the receiving system takes delivery, so anyone can verify later that the package is complete and unaltered since receipt.
What does a sealed submission mean?
The old analogy still works. A wax seal on a letter never vouched for the honesty of what was written inside. It showed the letter had not been opened on the way, and that it came from whoever held that particular signet. A digital seal makes the same two statements, with far better guarantees behind them.
How a sealed submission differs from a file hash
A SHA-256 fingerprint pins one file. That is necessary and not sufficient, because a real submission is more than a file.
A seal is built over a manifest: a structured list describing the whole submission and everything in it. That manifest typically includes:
- The digital fingerprint of every file received, each video and each photo.
- The answers the participant gave to the flow's questions, plus any transcript.
- The server-side receipt time for the submission.
- The recorded session events from the capture session.
- The technical signals logged around the submission.
So a hash proves that file four is unchanged. A seal proves there were exactly four files, that these are their fingerprints, that these were the answers, and that this whole set arrived together at this time.
How does sealing work: manifest, private key, public key
The manifest is signed with a private key held by the receiving system. Signing does two things at once. It fixes the contents of the manifest, so nothing can be added, removed or edited without invalidating the signature. And it ties the manifest to the holder of that key, so the package is attributable to a system rather than floating free.
To verify, a third party takes the sealed package, the signature and the published public key, and runs a standard signature check. If the signature validates, the manifest is exactly as it was when signed. They can then recompute the SHA-256 hash of each file they hold and compare it against the manifest.
None of that requires logging into the platform or trusting a green tick on a vendor's screen. That is the whole reason for public key verification rather than an internal status flag: an opposing expert, a regulator, an auditor or a court-appointed assessor can check the seal on their own equipment.
Sealed on receipt, not sealed on demand
Timing matters more than most descriptions admit. A seal generated when someone presses export, weeks into a case, only proves the package has been stable since that export. A seal applied automatically at receipt covers the period that is actually disputed, from arrival onwards.
The question to ask a provider is therefore not whether they can seal a submission. It is when the seal is created, and whether it can be regenerated afterwards. A seal that can be recreated at will proves less than one that cannot.
Sealed submission example: the reopened warranty claim
A warranty claim is declined in February on the strength of a customer video and two photos. In October the customer's solicitor argues that a third photo was submitted and ignored. Verifying the seal with the public key shows the manifest listed two photos and one video at receipt, and that nothing has been added or removed since.
It does not prove the decline was correct. It removes one argument from the table and lets both sides discuss the actual assessment.
What a sealed submission does not prove
- Not authenticity of the scene. A properly sealed submission can contain a recording of a staged situation. The seal covers custody, not truth.
- Not the time of the incident. Receipt time is when the system took delivery. The damage may be older.
- Not identity. The seal attributes the package to the receiving system, not to the person who held the phone.
- Not admissibility. Whether evidence is accepted depends on the forum, the jurisdiction and the wider case. A verifiable seal supports that argument. It does not settle it.
When does sealing matter?
When the alternative is a folder of photos and an assurance that nobody moved anything. That holds up fine until a case is reopened, the original handler has left, and the file has been copied across three systems. A sealed package lets a stranger reconstruct what arrived without relying on anyone's memory, the same requirement described in our guides to insurance claim documentation and remote claim inspection.
One operational warning. Sealed packages are only as durable as your retention policy, and data protection rules push towards deleting personal data once its purpose ends. Set the retention window against your real dispute horizon, not a default.
Venta Capture, a product of VentaVid, seals each submission on receipt, with 28 control points per submission, made up of 10 automatic signals, 21 recorded session events and 1 signed seal, plus SHA-256 fingerprints, a seal verifiable with a public key, GPS location, and GDPR-compliant storage with configurable retention.
