Verifying a record

Your workspace can produce two documents that somebody outside it can check without trusting you, and without running any of this software.

The two documents

An evidence pack. Admin, Settings, Audit log. The whole log for a window, with every row's position and hashes, a per-section digest, and a fingerprint for the document as a whole. This is the one an auditor is usually given.

A personal record. Activity, then the AI tab, then Download the record. What AI agents did in one person's name. Anyone in the workspace can produce their own without an administrator, and it is scoped to them.

Both carry, inside the file, the exact recipe for recomputing a row's hash and a plain statement of what that does and does not prove.

How somebody checks it

Give them the file. They open onemana.dev/verify and drop it on the page. Every row is recomputed in their browser. There is no account, no upload, and no request: the file never leaves the machine they opened it on, which matters when the document is about somebody's activity.

They can equally ignore that page. The steps inside the file are executable with any SHA-256 and JSON tool, which is the point of writing them down. The page exists because a recipe that requires somebody to write a script is a recipe almost nobody follows.

What a result means

Every row matches. Each row produces the hash it carries, so none of them has been altered since it was written.

A row does not match. That row was changed after it was written, or the file was edited on its way to the reader.

A row is marked redacted. Its content was cleared by your retention policy on purpose. The row and its hashes remain so the chain is unbroken, and its content cannot be recomputed because it is gone. This is not tampering.

What it does not prove

Recomputing hashes proves the rows you are holding are the rows that were written. It does not prove that no row was removed. Integrity and completeness are different properties, and no export turns one into the other.

A personal record is a filter over the log, so two rows next to each other in it are usually not next to each other in the log, and their hashes will not link to each other. Walking the chain end to end needs the whole log, which is what an evidence pack is for.

Why the product does not link the page

OneCamp runs on your infrastructure. An address printed in the interface would point your staff at a server that is not yours, so the files carry their own instructions instead and the checker is named here rather than in the product. If you would rather your auditor used something else, everything they need is in the file.