Know what the platform records
The Duale AI audit log records platform events and authorization decisions but omits document reads, policy changes, and tool results you must record yourself.
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
- Tenant, agent, member, token, and invitation changes
- What the record carries
- Who acted, what changed, before and after
- Recorded
- Configuration changes, including model routes
- What the record carries
- The change, with secret values redacted
- Recorded
- Configuration and directory reads
- What the record carries
- An access event
- Recorded
- Library access-grant changes
- What the record carries
- The subject, action, and effect of the grant
- Recorded
- Task lifecycle
- What the record carries
- Completion, timeout, and stop
- Recorded
- Routing dispatch
- What the record carries
- The platform or customer tool selected for dispatch, by name
- Recorded
- Authorization decisions
- What the record carries
- 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
- Document reads. Uploading, reading, or deleting a document in a Library raises no audit event.
- What no record can show
- Who read which document
- What covers the gap
- Your own record, written at the moment of the action
- Not recorded
- Policy and group changes. Authoring or editing an access policy or a group leaves no resource-change record.
- What no record can show
- Who wrote or changed an access rule
- What covers the gap
- Your own record, written at the moment of the action
- Not recorded
- Repeated authorization decisions. The record holds a sample of decisions, not every one.
- What no record can show
- A complete access-decision history
- What covers the gap
- Nothing
- Not recorded
- Tool completion and result. A routing row is written before the tool is dispatched.
- What no record can show
- Whether the tool ran, succeeded, or what it returned
- What covers the gap
- Your own tool record, written when the tool finishes
- Not recorded
- Model selection. Routing records name the dispatch, not the model selection.
- What no record can show
- Why a given model ran a task
- What covers the gap
- Usage analytics show provider and model for recorded executions. Nothing records the reason
- Not recorded
- The routing algorithm version. Two runs of the same agent can differ.
- What no record can show
- Why two runs of the same agent differ
- What covers the gap
- 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 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
- Who approved a model-pool change, and against what evidence
- The gap it closes
- The platform records the change, never the approval
- Record it yourself
- Who shared a Library, and with whom
- The gap it closes
- The grant record names a platform component, not the person
- Record it yourself
- Who authored or edited an access policy or a group
- The gap it closes
- Policy and group changes are not recorded
- Record it yourself
- Which document an agent read for a given answer
- The gap it closes
- Document reads are not recorded
- Record it yourself
- Your acceptance decision on each result
- The gap it closes
- Acceptance is not a platform event
Ownership and approvals 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 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 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 to place these records in the lifecycle of one task.