Audit Trail: Who Did What, When, and Why You Can Trust the Answer

An audit trail that can be edited is not an audit trail. It is a working document wearing a serious hat. ReVend OS is built so critical activity can be reconstructed later: who acted, what changed, which record was touched, and whether the trail itself still lines up.

Activity events

Server-side mutations, sensitive reads, document access, evidence downloads, cron outcomes, webhook results, admin overrides and security events write activity rows. They carry actor, tenant, action, outcome, sensitivity and bounded metadata. Raw secrets, passwords, signed URLs and payment details do not belong there. The sanitizer helps, but the real strategy is not putting dangerous things in the box.

Tamper-evident chain

Audit events are chained per tenant with a SHA-256 hash. Each new row includes the previous head, so a silent edit breaks the chain. That does not turn the database into a courtroom by itself, but it gives the platform a way to detect that history no longer matches itself. Auditors like history that can make eye contact.

Activity log

/general/activity is the human-facing event view. Platform staff use it for cross-tenant support and incident review; tenant admins use their own scope to answer the classic question: "who changed this on Tuesday at 4pm?" Filters keep the answer usable instead of turning the screen into confetti.

Per-record history

Many detail pages expose their own slice of history: asset status transitions, company edits, contract changes, escrow events, document access and support activity. The detail page answers the local question; the activity log answers the broader one.

What the auditor checks

The trail proves integrity, authorship, chronology and completeness. If a record moved, ReVend should show who moved it, when it moved, why it was allowed, and what evidence went with it. If the answer is "probably Dave," the audit has already gone poorly.