FACTUAL COMPARISON

Audit logs vs an audit trail

The WARD chain, in full The auditor experience

An audit log is a record your own system chose to write about itself: application logs, a SIEM export, an observability trace, or a platform's own audit feature. An audit trail for an AI agent is a chain of evidence someone outside your organisation, such as an auditor, can verify on their own, without trusting that your system told the truth.

The difference is not detail or retention, it is whether the record can be checked independently. Quox produces the second kind by hash-chaining every governed agent action in VOLT and having WARD witness it externally; it does not replace the first kind, it sits on top of it.

The table below compares five approach classes on the properties an audit actually needs, honestly, including where the other four beat Quox at their own job.

In plain words

What it is, where it lives, when to reach for it

What is it: A comparison: audit logs your system writes about itself versus audit trails a third party can verify.
Where do I use it: Across the tools you already run: application logs, SIEM exports, observability traces, platform audit feeds.
When would I use it: When you are deciding whether your existing logging would survive an independent audit.
How do I use it: Read the comparison below; Quox adds the verifiable kind on top of the logs you already keep.

Dimension	Application logs	SIEM / log export	Observability traces	Platform's own audit log	Quox (hash-chained, witnessed)
Tamper evidence	None: a log file can be edited or deleted by anyone with disk access	Depends on export pipeline integrity; the index itself is mutable	None: spans are mutable records, not evidence	As trustworthy as the vendor operating it; you cannot check it yourself	Hash-chained: each VOLT event links to the one before it, so an edit breaks the chain
Ordering guarantee	Wall-clock timestamps only, no guarantee against clock skew or reordering	Ordered by ingestion time, not necessarily by the order events actually happened	Strong within a single trace (span parent/child), weak across traces	Ordered internally, but that order is asserted, not provable to an outsider	Cryptographic chain order: each hash commits to the previous one
Actor identity	Whatever the code chose to print, often just a service name	As good as the identity fields the source system forwarded	Usually service/span identity, rarely the human or agent that triggered it	Tied to the vendor account model, not portable outside it	Bound to the AEE envelope for the run: agent, tool, and the human on any approval
Completeness across layers	Only what a developer remembered to log at that call site	Only what was piped into the collector; silent gaps look identical to silence	Only instrumented spans; uninstrumented code paths leave no trace at all	Only what that one platform sees, blind to everything outside its walls	One envelope per governed action: model call, tool call, and the approval that held it
Offline verification by a third party	Not possible: a log file proves nothing without trusting whoever handed it over	Not possible: a SIEM export is still just an assertion from the exporting org	Not possible: a trace viewer shows what the org chose to retain	Not possible without the vendor vouching for its own product	Possible: VOLT ships a portable evidence bundle a third party can check without asking you
External witness	None	None: the SIEM is operated by the same org whose actions it logs	None	None: the platform is judge of its own record	WARD append-only receipts and signed tips, published to an external sink
What it is genuinely best at	Fast, cheap, close to the code: the first place a developer looks when something breaks	Correlating events across systems in real time for detection and alerting	Diagnosing latency and failure inside a single request across services	Convenience: it is already there if you only ever operate inside that one platform	Evidence someone outside your org, including an auditor, can verify without trusting you

The check mark on the "best at" row means genuinely best at that job, not a deficiency in the other four columns. See "each tool keeps its job" below.

Each tool keeps its job

Quox is an evidence layer that runs on top of whatever runtime and logging stack you already have. It is not a replacement for your logs, your SIEM, your traces, or a platform's own audit feature.

Application logs stay the fastest way to answer "what did the code do right here", right down to the call site, and no evidence layer should try to replace that.
A SIEM stays the right place to correlate events across many systems in real time and trigger a detection or an alert; VOLT is not a detection engine.
Observability traces stay the right tool for latency and failure diagnosis inside a request; a hash chain tells you an action happened, not why a span was slow.
A platform's own audit log stays useful as a first-party record of what that platform believes happened, and it is often the source an AEE envelope wraps.
Quox runs on top of all four: it does not replace your logging, your SIEM, your tracing or a platform vendor's own audit feature, it wraps the governed actions your agents take in a hash-chained, externally witnessed record none of the four can produce alone.

Where this comparison comes from

The Quox column states only what /for-auditors, /docs/volt and /docs/ward already claim live on this site: VOLT hash-chained events, portable offline-verifiable evidence bundles, and WARD append-only receipts with signed tips published to an external sink.
The application logs, SIEM, observability traces and platform audit log columns describe approach classes in general, not any specific audited product. No named vendor is compared or scored here.
No certification is claimed anywhere on this page, and no compliance outcome is promised: the comparison is about verifiability of the record, nothing more.

See the evidence pillar Read VOLT Read WARD Worked example