---
title: "Know what the platform records"
description: "The Duale AI audit log records platform events and authorization decisions but omits document reads, policy changes, and tool results you must record yourself."
lang: en
status: public-preview
lastUpdated: 2026-08-31
url: https://dev.duale.ai/en/docs/security/evidence-and-audit
---

## AI-generated summary

The audit log records platform events like configuration changes and routing dispatch, omits document reads and policy edits, and requires you to record approvals and acceptance decisions yourself.

- Records tenant, configuration, task lifecycle, routing dispatch, and authorization decisions with before-and-after values.
- Does not record document reads, policy edits, tool results, or model selection reasons.
- Query filters by tenant, action, resource type, and time range; no acting-person or free-text search.
- Audit proof verifies canonical_event_data via SHA-512 but does not cover user_context or append-only anchoring.
- You must record approvals, Library sharing, policy authoring, document reads, and acceptance decisions yourself.

Summaries were generated by AI. Generative AI is experimental.

---

The audit log records part of what happens. This page states which part, what it leaves out, and what you record yourself
to close the difference.

Your change-management system stays the authoritative record for approvals, decisions, and exceptions. Platform records support that record. They never replace it.

## What the platform records

Use the audit log to support these platform events:

| Recorded                                             | What the record carries                                         |
| ---------------------------------------------------- | --------------------------------------------------------------- |
| Tenant, agent, member, token, and invitation changes | Who acted, what changed, before and after                       |
| Configuration changes, including model routes        | The change, with secret values redacted                         |
| Configuration and directory reads                    | An access event                                                 |
| Library access-grant changes                         | The subject, action, and effect of the grant                    |
| Task lifecycle                                       | Completion, timeout, and stop                                   |
| Routing dispatch                                     | The platform or customer tool selected for dispatch, by name    |
| Authorization decisions                              | Only the decisions the platform computes, never a cached repeat |

Use these entries as supporting evidence, then check the next section for the records that do not exist.

## What the platform does not record

Each row is a record an auditor routinely assumes exists. None of them does.

| Not recorded                                                                                                     | What no record can show                              | What covers the gap                                                                         |
| ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| **Document reads.** Uploading, reading, or deleting a document in a Library raises no audit event.               | Who read which document                              | Your own record, written at the moment of the action                                        |
| **Policy and group changes.** Authoring or editing an access policy or a group leaves no resource-change record. | Who wrote or changed an access rule                  | Your own record, written at the moment of the action                                        |
| **Repeated authorization decisions.** The record holds a sample of decisions, not every one.                     | A complete access-decision history                   | Nothing                                                                                     |
| **Tool completion and result.** A routing row is written before the tool is dispatched.                          | Whether the tool ran, succeeded, or what it returned | Your own tool record, written when the tool finishes                                        |
| **Model selection.** Routing records name the dispatch, not the model selection.                                 | Why a given model ran a task                         | Usage analytics show provider and model for recorded executions. Nothing records the reason |
| **The routing algorithm version.** Two runs of the same agent can differ.                                        | Why two runs of the same agent differ                | Nothing                                                                                     |

## What you can query, and what you cannot

The Dashboard queries records by tenant, action, resource type, resource identifier, and time range. One page contains
100 records by default and at most 1,000. An opaque cursor requests the next page. An export contains at most 100,000
records and uses JSONL or CSV.

**There is no filter by acting person and no free-text search.** A request for every event concerning one person cannot
be answered through this query interface. Plan your data-subject request procedure around that limit.

Reads of the audit log are themselves recorded.

With the built-in roles, an administrator can query and export records. A viewer can query records and request proofs but cannot export them. An editor has no audit access.

## You can verify record content, not append-only anchoring

An audit proof returns the exact `canonical_event_data` text and its `content_hash`. Compute SHA-512 over the UTF-8
bytes of `canonical_event_data`, without parsing or reformatting it, and compare the lowercase hexadecimal result with
`content_hash`.

A match proves that the exact returned canonical text produces the returned stored hash. It detects a change to that
text unless the hash changes with it.

The canonical text omits `user_context`, which contains the acting-person data. The platform authenticates and encrypts
that field separately, but this hash check does not cover it. A matching hash does not verify the acting-person data.

**You cannot verify the append-only anchoring independently today.** The interface returns transaction values but no
inclusion path and no independently trusted root. Treat that anchoring as an internal integrity control. Do not present
it to an auditor as independently verified tamper evidence.

## Linking a platform failure to your own records

Store each request, trace, or span identifier that a platform failure carries with your business record, and include
the available identifiers in a support request. [Errors and reliability](https://dev.duale.ai/en/docs/sdk/errors.md) defines how the SDK
exposes them.

Store the task identifier for every task, not only for failed ones. It is the one durable link between your record and the platform record.

## What you record yourself

Write each of these down when the action happens. No platform query reconstructs them later.

| Record it yourself                                          | The gap it closes                                           |
| ----------------------------------------------------------- | ----------------------------------------------------------- |
| Who approved a model-pool change, and against what evidence | The platform records the change, never the approval         |
| Who shared a Library, and with whom                         | The grant record names a platform component, not the person |
| Who authored or edited an access policy or a group          | Policy and group changes are not recorded                   |
| Which document an agent read for a given answer             | Document reads are not recorded                             |
| Your acceptance decision on each result                     | Acceptance is not a platform event                          |

[Ownership and approvals](https://dev.duale.ai/en/docs/model-routing/ownership-and-approvals.md) lists the fields to put in a change record.

## Contract terms set the response times

For an incident that requires notification under applicable law, the
[terms of use](https://dev.duale.ai/en/legal/cgu.md) set three deadlines. They set an early warning
within 24 hours of awareness, an incident notice within 72 hours, and a final
report within one month. The [terms of sale](https://dev.duale.ai/en/legal/cgv.md) set data return or
deletion within 30 days after termination. They also set an audit on 30 days'
notice. They promise no uptime figure.

Return to [Security](https://dev.duale.ai/en/docs/security.md) to place these records in the lifecycle of one task.

## Related content

- [Secure your use of the platform](https://dev.duale.ai/en/docs/security.md)
- [Legal terms, privacy policy, and subprocessors](https://dev.duale.ai/en/legal.md)
- [Intended purpose, excluded uses, and behavioral constraints](https://dev.duale.ai/en/docs/scope-and-limits.md)
- [Ownership and approvals for routing decisions](https://dev.duale.ai/en/docs/model-routing/ownership-and-approvals.md)
- [Govern AI agents while they move to production](https://dev.duale.ai/en/solutions/governance.md)
- [Integrate model routing in an application](https://dev.duale.ai/en/docs/model-routing/application-integration.md)

---

## Sitemap

See the full [Markdown sitemap](https://dev.duale.ai/sitemap.md) for all pages.
