ācta
← Insights
Governance

Tamper-Evidence: The Feature Nobody Talks About

When you approve minutes, ācta seals them with a SHA-256 hash, and every audit event links to the one before it. Here is how that makes a later change detectable.

Isaac Saunders Updated 12 min read
tamper-evidence governance audit cryptography minutes hash-chain compliance

Picture the moment a lawyer asks you, across a tribunal table, to produce the minutes from a meeting that took place eighteen months ago. You open the shared drive. The file is there. It has a modified date from last week. The metadata shows four different editors over the past year. The lawyer asks, quite reasonably, how you can be sure the document in front of you says the same thing it said on the day it was approved.

You cannot. Not really. You can swear to it. You can produce witnesses. You can point to version history inside your word processor, which anyone with edit permissions can also modify. What you cannot do is hand the tribunal a mathematical proof that the text is unchanged.

This is the problem the ācta hash chain addresses. It is the feature almost nobody asks about until they need it, by which point it is usually too late to retrofit.

The Trouble With Silently Editable Documents

Tamper-evidence means that any change to a record after approval can be detected. ācta seals approved minutes with a SHA-256 hash and links each audit event to the one before it in a hash chain. A changed document no longer matches its hash, and a changed event breaks the chain.

Many governance records live in Word documents on a shared drive. Some live in Google Docs. Others live inside purpose-built board portals. All of them share one property: the text can be changed, and the change can be made to look like it never happened.

Word tracks revisions if you remember to turn the feature on. Google Docs keeps a version history, accessible to anyone with edit rights, deletable by administrators. SharePoint retains versions for a configurable window. Each of these mechanisms is useful for collaboration. None of them were designed to survive adversarial scrutiny. They rely on the honesty of the custodian and the integrity of the platform. Which is fine, until honesty or integrity is the disputed point.

The risk is not that someone will commit obvious fraud. The risk is subtler. A director misremembers a decision and asks for a small clarification. A secretary tidies up an ambiguous sentence weeks after the fact. An action item gets quietly reassigned. Each individual change feels innocuous in isolation. Together, they mean the document in your hand today is not the document that was approved at the time.

A record you can silently edit is not a record. It is a draft that never stopped being a draft.

What Does Tamper-Evident Mean for Meeting Minutes?

Tamper-evidence is not the same as tamper-proof. A locked physical filing cabinet is tamper-proof, until someone with bolt cutters decides otherwise. A wax seal on an envelope is tamper-evident. The seal does not prevent you from opening the envelope. It just makes sure everyone can tell you did.

For a digital record, the equivalent of that wax seal is a cryptographic hash. A hash is a fixed-length fingerprint of a document. Feed the same document through the same hash function and you get the same fingerprint every time. Change a single character, a comma, a space, anything, and the fingerprint changes completely. The fingerprint is short. The document can be arbitrarily long. There is no way to work backwards from the fingerprint to recover the document, and no practical way to find two different documents that produce the same fingerprint.

ācta uses SHA-256, a standard and widely reviewed hash algorithm. When you approve minutes, ācta stores a SHA-256 hash of the content and a checksum of the PDF. If anyone changes the stored document, the hash no longer matches, and a check shows it.

From Fingerprint to Chain

A single hash protects a single document. That is useful but limited. It tells you whether the document in front of you is identical to the document that was hashed. It does not tell you anything about what happened to the record around it.

Governance records need more than a snapshot. They need a history. The question in a dispute is rarely "is this file corrupted?" It is "what happened to these minutes, and in what order?" To answer that, you need the events in order, and you need to prove that none were removed or swapped.

This is where the chain comes in. ācta keeps an audit trail of events for each document. Each event stores its own hash and the hash of the event before it. Event 2 points to event 1. Event 3 points to event 2. The chain lists the events in order.

The practical consequence is that tampering with one event breaks the link to every event after it. Change event 2 and its hash changes. Event 3 still points to the old hash, so the link does not match. ācta shows this as Chain Broken. When every link matches, ācta shows Chain Valid.

Git uses a similar structure to track source code. ācta uses it for a narrower purpose: one document, one audit trail, one chain.

How Does the ācta Audit Trail Run From Draft to Sealed Record?

Every set of minutes in ācta moves through a short lifecycle. The audit trail starts at the draft. The SHA-256 seal comes at approval.

1. Draft

ācta uses AI to draft the transcript, the minutes, and the records. ācta records each generated artifact, such as the transcript and the draft minutes, as an event in the hash-chained audit log with its source. The draft stays a draft until a person approves it. Reviewers can edit it, and ācta saves each edit. A draft is not sealed, so the draft text can change freely.

2. Approved and Sealed

When a person approves the minutes, ācta computes a SHA-256 hash of the content. It locks the approved minutes and the records, and it generates the PDF. Approval cannot be undone. From this point, the hash is the proof of what was approved.

3. Change Request

After approval, the content changes only through a change request. A recipient submits one from the document link and proposes new text for a section. A workspace user reviews it and either approves it or denies it. A denial needs a reason.

4. New Version

An approved change request updates the text and computes a new hash. ācta also creates a new version of the document. The change goes through the audit trail like any other event.

Nothing in ācta is silently overwritten after approval. A change needs a request, a decision, and a new hash. The history is the record.

Amendments, Not Edits

The distinction between an amendment and an edit is one of the most underappreciated points in governance practice. An edit rewrites history. An amendment adds to it.

Robert's Rules of Order Newly Revised treats a correction to minutes as an act of the meeting, not a private edit by the secretary. Corrections made at approval go into the minutes being approved. After approval, the body changes them by motion, and the secretary does not alter the original minutes.

ācta enforces this structurally. Approved minutes cannot be edited in place. A change goes through a change request that a workspace user approves or denies. An approved request produces a new hash and a new version of the document.

Contrast this with a Word document. You open it, make the change, save, and nothing is noted. Even with track changes enabled, a user with enough permissions can accept all changes and discard the history. There is no structural barrier. The discipline has to come from the people, and people forget.

Checklist: Before You Approve and Seal Minutes

Approval is final, so the checks belong before it. Use this list for every set of minutes.

  1. Read the whole draft. AI can miss a point, name the wrong speaker, or state a decision incorrectly.
  2. Correct every error in the minutes and each record, including owners and due dates.
  3. Check the participants list against who attended.
  4. Preview the PDF before you approve.
  5. Wait until the editor shows Saved, so no edit is lost.
  6. Approve. The seal protects the content exactly as it was approved, errors included.
  7. After approval, send corrections as change requests. Do not look for a way to edit in place.

Why Regulators and Tribunals Care

The value of a tamper-evident record is invisible until it is tested. When it is tested, a record that can show it is unchanged saves time and argument.

Audit evidence

Auditors look for reliable evidence of governance decisions. An auditor who asks for the minutes of a related-party approval is not helped by a Word document of unclear origin. In ācta, an external auditor works in an audit session. The auditor checks a PDF or hash against the sealed records in scope, sees the chain of custody, and can download a verification certificate. ācta logs every action the auditor takes.

Data protection

Data protection law in the UK and EU asks organizations to process personal data with appropriate integrity and confidentiality. Minutes often contain personal data: attendance, decisions about individuals, disciplinary references. A tamper-evident chain is one integrity control for that material. It does not make an organization compliant with any law, and ācta does not claim that it does.

Retention

A hash chain does not decide how long a record is kept. Your organization sets how long audio and transcripts are kept. Deleting audio does not change your approved minutes or their hashes. What the chain adds is a way to show that a kept record is the same as the one that was approved.

Tribunals and disputes

Employment disputes, shareholder disputes, and regulatory inquiries often turn on what was decided in a meeting. A party that can show its minutes match the approved version is in a stronger position. A party that says "we can show you the file" is relying on trust, not evidence.

Scenarios Where the Chain Earns Its Keep

Three illustrations show the idea. They are examples, not case studies.

The contested action item

A trustee says they never accepted a piece of fundraising work. The chair believes otherwise. With ordinary minutes, the conversation ends in a stalemate or a long scroll through email threads. With ācta, anyone with an account in the workspace checks the approved PDF against the sealed record. The result shows the meeting, the approval date, and the version. A match shows that the document is the version that was approved.

The late correction

Six weeks after a board meeting, the company secretary notices a typo in a financial figure. On a shared drive, the temptation is to fix it and say nothing. In ācta, approved minutes cannot be silently edited. The correction goes in as a change request, a workspace user approves it, and ācta computes a new hash and creates a new version. The change is an event in the audit trail.

The departing custodian

A long-serving secretary leaves under difficult circumstances. Their replacement cannot be certain that every historical record is untouched. Anyone with an account in the workspace can check any approved document. ācta shows Chain Valid when the links are intact and Chain Broken when a link does not match. A broken link points to where to look. An intact chain removes that doubt for the document checked.

What This Is Not

Honesty about capabilities matters. A hash chain is a strong integrity control, but it does not solve every problem.

A hash match proves that a document is the version that someone approved in ācta. It does not prove that the minutes are accurate or complete. It does not prove that the meeting took place as the minutes describe it. If the draft is wrong and a person approves it, the seal preserves the wrong draft. The people who approve the minutes are responsible for what the minutes say.

It does not prove who wrote the text. Approvals are recorded in the tamper-evident audit trail. The hash itself says nothing about authorship.

It does not, by itself, defend against an attacker with unrestricted access to every system, including the stored hashes. No system does. What it does is make tampering with an approved record visible to anyone who checks.

Tamper-evidence does not make you immune to disputes. It makes you the party holding the evidence when the dispute arrives.

Why General-Purpose Tools Do Not Do This

Word, Google Docs, Notion, SharePoint, and most meeting note apps are optimized for something different. Their job is to make collaboration easy. The whole point of a word processor is that anyone with access can change anything, instantly, without ceremony.

Tamper-evidence adds ceremony by design. It draws a line between draft and record, and it refuses to let you cross that line silently. That is the opposite of frictionless. It is also what governance requires.

A general-purpose tool can add version history, access controls, and activity logs. None of these is the same as a hash that is bound to the content. Collaboration tools have their place, and for most of what organizations write, they are adequate. For minutes and decision records, they are not.

Who Can Verify an ācta Record, and How?

Anyone with an account in the workspace can check a PDF or hash against its sealed records. External auditors verify in an audit session. A user checks a record in these steps.

  1. In the sidebar, open Tools, then select Verification.
  2. Drop the PDF on the drop zone, or paste the 64-character hash into the hash field and select Verify.
  3. Read the result. Document verified means the file or hash matches an approved document in your workspace. No matching document found means the file is not a sealed ācta record in your workspace, or the file changed.
  4. Read the chain of custody. The badge shows Chain Valid when the links are intact and Chain Broken when a link does not match.
  5. For a verified document, select Download Certificate to save a verification certificate.

ācta computes the hash of a PDF in your browser, so the file never leaves your computer. The chain works the same way for every document. Each audit event stores its own hash and the hash of the event before it. If someone altered an event in the middle of the chain, the links after it would no longer match.

The check shows that a document is the approved version. It does not show that the minutes are accurate.

The Bottom Line

Tamper-evidence is the feature you hope you never need. It is also the feature that turns a document into a record. Without it, minutes are a helpful summary. With it, minutes can be checked against the version that was approved.

Most organizations will go their whole lives without being asked to prove that their governance records are unaltered. A few will be asked, and they will learn quickly which side of the line they were on. Putting a proper chain in place before the question arrives is cheap. Reconstructing a defensible record afterward is expensive and sometimes impossible.

If someone asked you today to prove what your minutes said on the day they were approved, could you? If the answer is anything other than yes, your records are not yet records.

ācta seals approved minutes with a SHA-256 hash and records approvals and changes in a tamper-evident audit trail. Anyone with an account in the workspace can check a document against its sealed records. External auditors verify in an audit session.

Sources

  1. Robert's Rules of Order Newly Revised, 12th edition: Frequently Asked Questions (citing §48:2, §48:4(5), §48:15). Robert's Rules Association, October 6, 2026.

Ready to transform your meetings?

Join the ācta beta and never lose a decision again.

Free during beta · No credit card required