The Case: The Public Tender Audit Arrived, and the Folder Had No Timeline
Auditors do not trust folders; they trust timelines. How a chronological activity log saved a public tender from becoming a scandal.
The Question of “When”
The auditor arrived on a Thursday morning. The audit concerned a public tender for a construction project. The specific allegation was that the requirements were changed after the vendor was selected to favor a specific bid.
The project manager was confident. “No, we updated the requirements on March 1st. The vendor was selected on March 15th.”
The auditor asked for proof.
The manager opened the project folder. He pointed to Requirements_v2.pdf. The timestamp read: Date Modified: April 10th.
The manager paled. “Wait, I moved that file to a new folder last week. That’s why the date changed.”
The auditor did not care. The evidence suggested the requirements were written a month after the selection. The narrative collapsed. The crisis began.
The Dispute: The Volatility of Metadata
This scenario illustrates the fragility of file system metadata. Windows and macOS are not designed for forensic preservation. They are designed for current utility.
- Copying a file changes the “Created” date.
- Saving a file changes the “Modified” date.
- Emailing a file strips metadata entirely.
In a dispute regarding sequence, the file system is an unreliable witness. It creates ambiguity. As I have stated, ambiguity is an expensive luxury.
The Proof: The Independent Timeline
To survive an audit, you need a record that is decoupled from the file itself. You need a chronological event log—a Ledger.
If the project manager had used a proper document management system, the conversation would have been different. He would not have opened a folder. He would have opened the Activity Stream.
[TO EDITOR: Illustration of a vertical timeline. Top to bottom.
- March 1, 09:00: User A uploaded Requirements_v2.pdf.
- March 2, 14:00: User B Approved Requirements_v2.pdf.
- March 15, 10:00: Vendor Selection Finalized.]
The log would show:
Event ID: 4492 Date: 2025-03-01T09:00:00Z Action: UPLOAD File: Requirements_v2.pdf Hash: 7d8f…a12
Event ID: 4498 Date: 2025-03-15T10:00:00Z Action: STATUS_CHANGE Context: Vendor Selected
The fact that the file was moved on April 10th would appear as a separate, irrelevant event later in the timeline. The original upload date remains immutable in the Ledger.
The auditor reviews the log. The sequence is validated: Requirement (March 1) -> Selection (March 15). The allegation of retrofitting the requirements is disproven by the math of the timestamp.
It is documented that audits turn into investigations only when the data is messy. When the data is linear, clear, and immutable, the auditor checks the box and leaves.
Do not rely on your operating system to tell the time. It lies. Rely on the log.
FAQs
Why are file timestamps unreliable?
If you move a file from one server to another, the 'Created' date often resets to the current date. This destroys the historical timeline.
What does an auditor look for?
They look for the sequence of events. Did the approval happen *before* the purchase order? Sequence determines validity.
How do we create a narrative log?
You do not create it manually. You use a system that auto-generates a feed of events (upload, comment, approval) independently of the file storage.