The short answer

An audit trail is what turns "we are compliant" into something demonstrable. For a voice platform it must cover the operational surface as well as the calls: who changed the agent prompt, who lifted a calling-window restriction, who exported a contact list. Those changes determine whether every subsequent call was compliant.

In detail

A useful entry identifies the actor, the action, the target resource, the timestamp, and enough of the before-and-after state to reconstruct what changed. Actor type matters as much as actor identity: a change made by a scheduled job, by an API key, by a workspace user and by a platform administrator carry very different weight in a review, and collapsing them into one field loses the distinction.

The property that makes a log an audit trail is immutability. If entries can be edited or deleted by the same people whose actions they record, the log proves nothing. Append-only storage, separate retention rules, and access controls distinct from the application’s own are what make the record credible to an auditor.

Coverage is where most implementations fall short. Logging calls but not configuration changes leaves the important question unanswered — a campaign that dialled outside permitted hours is explained by who changed the window setting, not by the call records themselves. Consent changes, suppression-list edits, prompt revisions and permission grants all belong in scope.

How Rexa handles it

Rexa writes audit entries through a typed service that every mutation path calls, distinguishing four actor types: workspace users, API keys, system jobs and platform administrators. Administrator actions carry stricter requirements — an actor email, a required reason, and a before/after diff — so an admin-triggered change is fully reconstructable from the log. Workspace-visible entries are filtered in the service rather than only in the query.

Security

Back to the glossary

All 53 glossary terms