Audit evidence: understanding what a log can and cannot prove

An audit record helps explain who attempted or performed an action, when it occurred and what result was recorded. Its usefulness depends on coverage, retention and reliability. An absence of entries is not automatically evidence that nothing happened.

Different logs serve different purposes. A permission denial, a transaction history, an approval change and an AI query record are not interchangeable evidence.

Audit Reports in DNA

The reviewed Audit Reports page reads from an audit logger that stores its entries locally and retains a bounded number of records. It supports filters such as role, module, result, type and dates. This is useful for the events represented there, but it should not be described as a complete, immutable, company-wide server audit trail.

A browser's available log population can differ from the full history a reviewer needs. Important conclusions should be reconciled with the relevant transaction, approval or service records.

AI Audit is a separate source

DNA's AI Audit page requests query-audit records through its API, with search, date, user and outcome filters and pagination. It handles unsuccessful loading separately from returned results. Its source and scope differ from the local Audit Reports logger.

A reviewer should identify the question, returned outcome and available execution evidence. The existence of an AI answer does not establish that its interpretation was correct, and a filtered page does not represent every query ever made.

A disciplined review

If Emily investigates why a document did not proceed, she should identify the relevant action and time, then examine the appropriate evidence. A denied permission may explain one attempt; it does not prove that a later authorised attempt never occurred.

State conclusions within the evidence's scope. A useful review distinguishes observed events, missing evidence and unresolved questions, rather than converting an incomplete log into a confident story.