The audit trail and chain verification

Every change to a record is written to the event log with a timestamp, the actor who made it, the record affected, and the before and after values. The Δ column shows how many fields changed, so a routine edit and a wholesale rewrite look different at a glance.

Actors include people, integrations acting under an API key, and automation. Machine activity is attributed as specifically as human activity — there is no anonymous "system" bucket that changes cannot be traced through.

Journal entries are linked by cryptographic hash: each entry's hash incorporates the one before it. Altering a historical entry would change its hash and break every link after it.

The chain verifier walks every entry for the entities in scope and reports per entity whether the chain is intact. It is the fastest way to answer an auditor asking whether the ledger has been rewritten — and, unlike a policy statement, it is checkable.

Verifying the chain proves internal consistency. It does not, by itself, prove that the whole chain was not rebuilt at some later date. External anchoring closes that gap.

A scheduled job stamps each legal entity's chain head to OpenTimestamps every Sunday at 06:00 UTC. The anchor records the sequence number, the head hash, and a status that moves from pending to confirmed as the timestamp is committed. The result is independent evidence of what your ledger contained at a point in time — evidence that does not require anyone to trust Backline.