Five Questions Hiding Inside “Is This Record True?”
When people ask whether a log can be trusted, they are usually asking five different questions at once.
Is the record present? Something exists in a file, database table or archive. That is the weakest claim.
Is the record authentic? It was created by the system and the process it claims to come from, not inserted or fabricated later.
Is the record complete? No relevant entries are missing: no gaps, no dropped events, no filtered fields.
Is the record accurate? The data correctly describes what happened in the world, including correct amounts, identifiers and times.
Is it sufficient evidence for a particular conclusion? Even an authentic, complete and accurate record may not support the claim someone wants to make, such as “this person intended to make this payment”.
Each question requires different evidence. Most real disputes about digital records turn on the gaps between them.
What Different Logs Actually Record
Event, application and transaction logs
Event logs record occurrences within a system, such as a service starting, a configuration changing or an error being thrown. Application logs are written by software to describe its own behaviour: requests received, functions called, exceptions raised. Their content is decided by developers and varies widely. Transaction logs record business or financial operations, such as an order created, a payment authorised or a balance updated, often with identifiers that link to other systems.
Database, access and security logs
Database logs are a special case. Many database engines keep a write-ahead or transaction log, primarily to recover after crashes and keep data consistent, not as a human-readable audit trail. Separate database auditing features may record who queried or modified data. Access logs, typically produced by web servers and proxies, record requests: source address, requested resource, status code and time. Security logs record authentication attempts, permission changes, policy violations and alerts.
NIST’s Special Publication 800-92, Guide to Computer Security Log Management, remains a widely cited reference for how organisations should generate, transmit, store, analyse and dispose of these records.
Immutable and append-only storage
Append-only systems allow new entries to be added but not existing ones to be changed through normal operations. Write-once, read-many (WORM) storage enforces this at the storage layer, typically for a defined retention period. Some regulated sectors have explicit requirements here. US broker-dealer recordkeeping rules, for example, have long referenced WORM storage and, following amendments in 2022, also permit an audit-trail alternative.
Logging is not admissibility
Whether a log is technically sound and whether it is admissible or persuasive in a legal proceeding are separate questions. Rules of evidence differ between jurisdictions. In the United States, for instance, the Federal Rules of Evidence include provisions allowing certain electronic records and data copied from devices, identified by a process such as hash comparison, to be authenticated by certification. Even where a record is admitted, its weight and interpretation can still be challenged.
A log entry records what a system did. It does not automatically prove human intent.
The Timestamp Problem
Clocks are not facts
A timestamp is a statement by a particular clock at a particular moment. Server clocks drift. They are usually corrected through synchronisation protocols such as NTP, but synchronisation can fail, be misconfigured or be temporarily lost. Virtual machines and containers can inherit clock problems from their hosts.
Event time, processing time and ingestion time
Distributed systems often distinguish between:
event time: when the event occurred at its source;
processing time: when a service handled it;
ingestion time: when the log platform received and stored it.
These can differ by milliseconds or, in the case of delayed batch uploads, offline devices or message queue backlogs, by minutes or hours.
Time zones and formats
Logs may record local time, UTC or an ambiguous format without a time-zone offset. Daylight saving changes can create duplicated or missing hours in local timestamps. Standardised formats with explicit offsets, such as ISO 8601 or RFC 3339, reduce this risk.
Ordering in distributed systems
In 1978, Leslie Lamport’s paper “Time, Clocks, and the Ordering of Events in a Distributed System” showed that physical clocks alone cannot always establish the order of events across machines, and introduced logical clocks to capture causal ordering. Many modern systems combine physical timestamps with sequence numbers, logical clocks or correlation identifiers.
A hypothetical example
The following scenario is fictional.
A user taps “confirm” in a mobile app at 21:04:55 according to the phone. The app’s analytics event reaches the vendor at 21:05:30 because the phone was briefly offline. The platform’s API gateway records the request at 21:05:28, its own clock running two seconds fast. The payment provider records authorisation at 21:05:27 by its clock. The platform’s database commits the transaction record at 21:05:29.
All five timestamps describe related events. None is “wrong”, but read naively they suggest an impossible order: the authorisation appears to happen before the request reached the platform. Reconstructing what happened requires knowing which clock produced each value, what each timestamp means and how the events are linked by identifiers.
Integrity – Detecting Change, Not Proving Truth
Cryptographic hashes
A cryptographic hash function such as SHA-256 maps data to a fixed-length value. In practice, any change to the data produces a different hash. If a hash of a log file was computed and stored securely when the file was created, recomputing it later shows whether the file has changed.
What a hash does not do is prove that the original data was true. A record that was wrong when written produces a perfectly valid hash. A hash proves consistency with a reference value, and only if that reference value itself is trustworthy. Older algorithms such as MD5 and SHA-1 have known collision weaknesses and are not recommended for new integrity protection.
Hash chains
In a hash chain, each entry includes the hash of the previous entry. Changing or deleting an earlier record breaks every link that follows. The idea was described for document timestamping by Stuart Haber and W. Scott Stornetta in 1991. Secure audit-logging research, including work by Bruce Schneier and John Kelsey in the late 1990s, developed schemes to protect earlier log entries even if a system is later compromised.
Merkle trees extend this idea, allowing efficient proofs that a particular record belongs to a larger log. Certificate Transparency logs, specified in the IETF’s RFC 6962, use this structure to make the issuance of web certificates publicly auditable.
Digital signatures and trusted timestamps
A digital signature binds data to a private key. If the key is properly protected, a valid signature shows that the holder of the key signed exactly that data. Trusted timestamping services, as defined in RFC 3161, can sign a hash together with a time, providing independent evidence that the data existed in that form at or before that moment.
Write-once storage, access controls and replication
WORM storage, role-based access controls, separation of duties and independent copies all make undetected alteration harder. Replicating logs to a separate system controlled by a different team or organisation is one of the most effective practical safeguards.
Tamper-evident is not tamper-proof
A hash chain makes changes detectable, provided someone actually checks and the reference values are stored where an attacker cannot reach them. An administrator with sufficient privileges might be able to rewrite an entire chain and its references if both are under their control. Tamper evidence is only as strong as the independence of the verification.
Transaction Records: Many Events, Not One
Payment flows illustrate why “the transaction” is rarely a single record. Terminology and workflows differ between card networks, providers and payment methods, but card payments commonly involve distinct stages, each of which may be logged separately:
StageWhat it typically meansWhere it may be recordedInitiatedA payment request was createdMerchant application, payment providerAuthorisedThe issuer approved and reserved fundsProvider, card network, issuerCapturedThe merchant requested collectionMerchant, providerSettledFunds moved between institutionsAcquirer, issuer, settlement reportsReversedAn authorisation was cancelled before captureProvider, issuerRefundedCaptured funds were returnedMerchant, provider, issuer
A merchant’s database may show “paid” when the provider has only authorised. A provider’s record may show a refund that the merchant’s system never recorded. A sound audit trail links these events through shared identifiers and preserves each system’s own record, rather than collapsing them into a single status.
A Hypothetical Dispute on a Digital Entertainment Platform
The following case is fictional.
A user of a subscription-based digital entertainment service disputes a charge. They say they cancelled their subscription before renewal and did not authorise the payment.
Potentially relevant records include:
authentication events: logins, multi-factor prompts and device identifiers around the relevant dates;
session records: when sessions started and ended, and from which network locations;
application events: whether a cancellation request was submitted, and whether it failed or was confirmed;
payment status records: whether the renewal was authorised and captured, and any reversals;
transaction identifiers linking the platform’s records to the payment provider’s;
support communications: emails or chat logs where cancellation was requested or acknowledged.
Evidentiary limitations
A successful login shows that valid credentials were used, not who used them. A cancellation event may be missing because the request never reached the server, because logging failed or because the user never completed it. A renewal authorisation shows that the payment was approved under the stored payment credentials, not that the user remembered agreeing to the renewal. Support chats may be incomplete if retention policies have already deleted earlier messages.
Branding is not evidence of an audit trail
Public-facing branding says nothing about the quality of a platform’s internal records. A user searching for a Westio casino site, a streaming service or any other digital entertainment brand sees marketing pages, interfaces and terms of service. None of these reveal how events are logged, how clocks are synchronised, whether records are integrity-protected or how long they are retained. Those are properties of internal systems and procedures that outsiders can usually only assess through audits, certifications or the evidence produced when a dispute actually arises.
The Six-Layer Audit Trail Trust Test
This framework is designed for anyone assessing whether a log can support a conclusion, whether investigators, archivists, auditors or engineers.
Layer 1: Event definition
What to check: what exactly does the entry mean, according to documentation or code? Does “payment_success” mean authorised, captured or settled?
Why it matters: misreading the event invalidates every conclusion built on it.
Limitations: documentation may be outdated, and event meanings change between software versions.
Failed check: the record cannot be interpreted reliably.
Layer 2: Source authentication
What to check: which system, service or account produced the record? Is it signed, or produced by a controlled process?
Why it matters: records from an unverified source may be fabricated or misattributed.
Limitations: compromised systems can produce authentic-looking but false records.
Failed check: authenticity cannot be established.
Layer 3: Timestamp reliability
What to check: which clock produced the time? Was it synchronised? Is the time zone explicit? Is it event, processing or ingestion time?
Why it matters: sequence and timing are often central to disputes.
Limitations: clock drift and delayed ingestion can rarely be reconstructed perfectly.
Failed check: conclusions about order or timing are weak.
Layer 4: Integrity protection
What to check: hashes, chains, signatures, WORM storage, access logs for the logs themselves, independent copies.
Why it matters: without integrity controls, modification cannot be ruled out.
Limitations: tamper evidence depends on independent verification and secure reference values.
Failed check: the record may be authentic, but alteration cannot be excluded.
Layer 5: Context and corroboration
What to check: do other systems, such as the payment provider, the identity provider or communications records, confirm the same event?
Why it matters: independent agreement is much stronger than a single log.
Limitations: corroborating sources may share the same errors or clocks.
Failed check: the record stands alone and its conclusions remain uncertain.
Layer 6: Long-term preservation
What to check: retention policy, storage format, schema documentation, chain of custody, migration history.
Why it matters: a log that cannot be read or understood in five years has lost its evidentiary value.
Limitations: proprietary formats and undocumented schemas age badly.
Failed check: the record may exist but cannot be reliably interpreted.
Applying the test to the dispute
In the subscription case, Layer 1 reveals that the platform’s “subscription_renewed” event is written when the payment is authorised, not when it is captured. Layer 2 confirms that the events come from the production billing service. Layer 3 shows that the cancellation attempt and the renewal occurred within the same minute, but on systems with different clocks. Layer 4 finds that application logs are shipped to an append-only store with daily hash anchoring, while support chats are not integrity-protected. Layer 5 shows that the payment provider confirms the authorisation, but nothing independent confirms that a cancellation request was received. Layer 6 reveals that client-side app logs are retained for only 14 days, so the user’s device records are no longer available.
Conclusion: the records strongly support that a renewal payment was authorised. They do not establish whether the user attempted cancellation before it. That gap is not a failure of cryptography but of logging scope and retention.
Preservation, Provenance and the Digital Library Perspective
Digital-library research has long recognised that preserving bits is not the same as preserving meaning. The OAIS reference model (ISO 14721) describes the preservation information an archive needs alongside content: provenance, context, reference and fixity. The PREMIS data dictionary provides a widely used vocabulary for recording preservation events, the agents involved and the rights that apply.
For audit logs, this means preserving:
provenance metadata: which systems generated the logs, under which software versions and configurations;
retention policies: what was kept, for how long and what was deliberately deleted;
archival formats: open, documented formats rather than proprietary ones where possible;
migration records: how logs were converted between formats or systems, with integrity checks before and after;
access permissions: who could read or modify the logs, and when;
reproducibility: enough documentation that another analyst can reach the same interpretation;
chain of custody: who handled the records once they became evidence;
documentation of changes: schema updates, field renames and event definitions over time.
A log file preserved perfectly but stripped of its schema, time-zone conventions and event definitions may be impossible to interpret years later. Bit-level fixity without context protects the container, not the evidence.
From Records to Evidence
Digital audit trails are among the most valuable sources of evidence modern organisations have, precisely because they are detailed, automatic and voluminous. Those same qualities make them easy to over-trust. A record becomes credible evidence when its meaning is clear, its source is authenticated, its timing is understood, its integrity is protected, independent sources corroborate it and its context is preserved. Without these, a log is still a record, but it is not yet proof.
