Proving a student submitted on time

Every department has had this conversation. A student says the chapter went in before the deadline. The supervisor says it wasn't there. Both are being honest, and neither can prove anything.

The reason is simple: most departments store submissions in a way that cannot answer the question.

Why a shared drive can't settle it

A file on Google Drive, OneDrive, or a departmental server has a last modified date. That is not a submission time. It is the time of the most recent edit — including edits made after the deadline.

Three specific ways this breaks:

• Overwrites destroy the original. Upload thesis_final.docx twice and the first version's timestamp is gone. There is no record it existed.
• Timestamps are client-side and mutable. Depending on the sync tool, the recorded time can come from the uploading machine's clock, which the uploader controls.
• Folder permissions allow deletion. If a student can delete their own file, the absence of a file proves nothing either.

None of this means students are cheating. It means the storage was designed for collaboration, not for evidence — and using it as evidence is a category error.

What "immutable" actually means

An immutable submission is one that cannot be edited or deleted after it is created. Not "shouldn't be" — cannot be, because the system offers no operation that does it.

The practical consequences:

• Submitting a revision creates version 2. Version 1 remains, with its original timestamp intact.
• The submission time is recorded server-side, from the server's clock, not the uploader's.
• Nobody — including administrators — can backdate or remove a submission.

That last point is what makes the record worth anything. A log that a privileged user can edit is not an audit trail; it is a document.

What a checksum adds

A SHA-256 checksum is a fixed-length fingerprint computed from the file's contents. Change a single byte anywhere in the file and the fingerprint changes completely.

Storing the checksum alongside the submission gives you one specific guarantee: the file you are reading now is byte-for-byte the file that was submitted. If storage were ever corrupted, migrated badly, or tampered with, the checksums would no longer match and you would know.

It is worth being precise about what a checksum does not do:

• It does not prove who uploaded the file — that is authentication's job
• It does not prove when — that is the server timestamp's job
• It does not detect plagiarism or AI-generated text — different problem entirely

Checksum, server timestamp, and authenticated identity are three separate guarantees. You need all three, and each one covers a gap the others leave open.

The audit trail around it

Submissions are the core, but a dispute usually involves more than the file:

• When was the deadline set, and was it changed afterwards?
• Was an extension requested? Approved by whom?
• When was feedback given, and on which version?
• Who marked the milestone complete?

An append-only audit log covering those events turns "what happened" from a reconstruction into a query. Append-only matters for the same reason immutability does — a log you can edit answers the question you want it to.

What changes in practice

Departments that move to immutable submissions report the same thing: the disputes mostly stop happening. Not because the record wins arguments, but because everyone knows the record exists, so the argument never starts.

There is a secondary effect worth planning for. Once submissions are immutable, students will submit earlier and more often, because a submission is no longer a commitment they can't walk back — version 2 is always available. That is a good outcome, but it means your milestone structure should expect multiple versions per gate rather than one.

A short checklist

If you are evaluating whether your current setup can survive a challenge:

1. Can a submission be overwritten or deleted after the deadline? If yes, you have no record.
2. Is the recorded time generated by the server or the client?
3. Can an administrator alter a submission or its timestamp?
4. Is feedback attached to a specific version, or to the project in general?
5. Are extension approvals written down at the time they are granted?

Any "no" on the first three is worth fixing before the next cohort, not after the next dispute.

---

Supervizo stores every submission immutably, checksummed with SHA-256 and timestamped server-side, with an append-only audit log across the project lifecycle. Read more about the platform.