The problem with an ordinary audit table
A standard audit log is just a table of rows. Anyone with sufficient database access — an administrator, an attacker who compromises credentials — can edit or delete a row and leave no trace that it happened.
How hash chaining fixes that
In a hash-chained log, each new row’s hash is computed over its own content plus the previous row’s hash. That makes every row cryptographically dependent on every row before it. Change one historical row’s content, and its hash no longer matches what the next row expects — the chain breaks at that exact point.
Why row locking matters
Writing to a hash chain safely under concurrent access requires that two privileged actions cannot compute their hash against the same "previous row" at the same time. Voz360 writes chain rows under a row lock (FOR UPDATE) specifically to prevent that race condition from corrupting the chain order.
What verification looks like
A verification pass reads the chain from the first row forward, recomputing each hash and comparing it against the stored value. Any mismatch identifies the exact row where history diverges from what the chain proves should be there.
Can the vendor tell you — in one sentence — which of their AI capabilities are rule-based, which are generative, and which are still roadmap?