Status: Logic Hardening

Subject: Tamper-Proofing Google Sheets with SHA-256 and Custom Triggers

Standard automation is usually about moving data from A to B as fast as possible. But when the data in question is for legal or compliance purposes, the priority shifts from speed to immutability. If a record can be edited after it is saved, the entire automation loses its value.

This log looks at the backend logic we developed to turn a standard Google Sheet into a secure, tamper-evident vault.

1. The Digital Fingerprint: SHA-256 Hashing

The core of this system is the “Digital Fingerprint.” We don’t just want to save a row of data; we want to “seal” it. To do this, we use the Utilities.computeDigest method in Apps Script to run a SHA-256 hash.

The Logic Flow:

The script gathers the User ID, the Timestamp, and the Message.
It joins them into a single string.
It converts that string into a 64-character hash.
This hash is stored in a hidden, “protected” column.

If someone tries to manually go into the sheet and change a single letter in that record, the hash will no longer match the content. We built a secondary “Audit Script” that runs every hour, re-calculates the hashes, and flags any row where the fingerprint has been tampered with.

2. The “Dual-Clock” Validation

To prevent “back-dating” (an issue where a user might change their phone clock to make it look like an entry was made earlier), we implemented Dual-Timestamping.

The system captures:

The Device Time: When the user physically pressed “Submit.”
The Server Time: The exact millisecond the Google Script received the request.

If the gap between these two times is more than 10 seconds, the script doesn’t just save the data—it appends a “System Latency” flag. This provides a clear, technical audit trail that proves exactly when the data hit the server, regardless of the user’s local settings.

3. Handling Deletions: The “Soft-Kill” Logic

In a high-integrity system, you cannot truly “delete” anything. If a user needs to remove an entry, we don’t use the deleteRow() function. Instead, the automation performs a Soft Delete.

When the “Delete” command is triggered:

The script moves the data to a “Hidden Archive” sheet.
It marks the original row as inactive.
It creates a new log entry: “Entry ID [X] moved to Archive by User [Y] at [Timestamp].”

This ensures that the “Chain of Custody” is never broken. Even “deleted” items have a verifiable history.

The Verdict

By treating Google Sheets like a high-security database, we proved that you don’t need a million-pound infrastructure to achieve data integrity. You just need the right logic.

This “Evidence Vault” architecture is now the standard for any Empower Automation project where data accuracy is non-negotiable.

Building the 'Evidence Vault' Logic