An audit trail that can't be rewritten

The difference between an audit log and a tamper-proof audit log is whether the people running the system can edit it after the fact. In NxtAssets, nobody can — not a user, not a manager, not an administrator, not the vendor.

What's in the record

Three kinds of events go into the tamper-proof log automatically, as they happen:

If it happened, it's in the log. If it's in the log, it's there to stay.

Why it can't be edited

The record lives in a part of the system that is write-once by design. Once a row is written, the system rejects any attempt to change it or remove it. That rule is enforced by the data layer itself — below the application, below the user interface, below any administrator account. Tampering isn't just forbidden by policy; it's physically blocked and, in the rare case someone tried, it would be immediately detectable.

For an auditor, the practical effect is simple: you don't have to prove that the custody record wasn't edited. The question doesn't come up.

Retention matches the law

Texas statute sets specific preservation periods for election records. NxtAssets retention is configured to match:

Retention policies are themselves protected — you can make the window longer, but you can't shorten it on a whim and make the records disappear before the clock runs out.

Real scenario

Nine months after an election, your county receives a public records request for chain-of-custody logs on a specific batch of voting machines. In NxtAssets, that's a report run — the records are right where they were written, in the form they were written, with the signatures and timestamps intact. The only thing that's changed since the handoff is the date on the calendar.

What this unlocks

Security teams and IT evaluators — if you want the specifics of how the immutable storage works (database engine features, cryptographic integrity, audit-table protections), that's on the For security teams page and in the full security architecture.