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.