Wiki/Compliance/Audit Trail: Who Did What, When, and Why You Can Trust the Answer
06Compliance3 min read

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

How append-only events, a human-first review layer and a tamper-evident hash chain turn “I think” into evidence.

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, starting from a GENESIS row. Each new event includes the previous head, so a silent edit breaks the chain, and a verify routine can walk it. 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.

The review page reads like a sentence

/general/activity is the human-facing view, and it leads with human language: every row opens with a plain summary of what happened, not a machine status. The same summary is the first line in the detail panel, the CSV export, and the small recent-activity panels on other screens. Source, correlation and extra metadata stay available where they add meaning; empty metadata and duplicated resource IDs are not product detail.

Filters keep the answer usable instead of turning the screen into confetti: search, domain, action, outcome, sensitivity, visibility, source table, date range, and organization where platform scope allows it. CSV export asks first — the current page, or everything matching your filters — and matching filters requires a date range, so an export cannot accidentally reach for the entire history.

Platform staff read it across tenants, and have an admin-side activity page too. Tenant admins see their own tenant, sensitive rows included, but never platform-only rows. Ordinary tenant users see the menu item and no data: the page tells them the activity log is for tenant admins, which beats a 404 pretending it does not exist.

Looking is not doing

An ordinary page load is not a business action. Opening a route, refreshing, searching, sorting, paginating, switching tabs, opening a modal, changing a filter — none of it writes activity, because none of it changes data, status, rights, evidence, money, publication, a support case, a security posture or integration behavior. A trail that logs looking at things buries the trail that logs doing things.

Genuinely sensitive reads are different: cross-tenant platform context, document access, support attachments and bid history pulled through the API are recorded as sensitive reads — deduped, or surfaced through an evidence lens — rather than as generic “viewed page” noise.

Grouping is presentation, not deletion

Consecutive low-information system and runtime events sharing scope, meaning, outcome and resource may be grouped in the review layer as one row with a count and a time range. The individual rows stay in the detail panel, and CSV export still writes them out one by one. Human business actions are never collapsed, however alike they look. Two people doing the same thing twice is a fact, not a duplicate.

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.