Skip to main content
Every answer and every governed action in Ainomos leaves an evidence record: what happened, who did it, in which room, with which model, on which sources and under which rules. The Audit log brings these records together into one timeline for the whole organisation. It is read-only: nothing on it can be edited or deleted. Who can see this: platform admins. Members of a room also see the evidence behind its answers in the chat. See reading answers.

What gets recorded

Answers

Each chat answer writes one evidence record with:
  • the room, its data class, and who asked
  • the model that was asked for and the model that answered, the tokens used and the cost
  • every source that was offered to the model, marked as Cited if the answer used it or Context only if it did not, each with its owner and validity dates
  • every rule that was checked and its outcome, and any exception that applied
  • how many earlier turns of the conversation were part of the question
  • if the question was also searched in the other language, the model and cost of that translation

Agent actions

When an AI app or agent acts through Ainomos, the record names the agent, the app it used and the person it works for, if any. Ainomos keeps apart what it verified from the identity provider’s signed token, and what the app says about itself, such as its name. A statement is never shown as proof. Validating a planned action, and proposing or revising a draft, each leave a record.

Governance changes

Decisions on drafts and proposals write a record, and so do changes to the setup. A change carries a governance act: what was done, to what, the old and new value, and the reason given. Examples: setting the content language, saving file storage or a mail server, creating a log destination, scheduling maintenance. A search alone writes no record. An exception request gets its record when it is decided.

App reads

When an AI app reads a resource through MCP, the open standard AI apps use to connect to Ainomos, the log keeps a lightweight read event: who, which app, which room, which resource. These are best effort, have no evidence record and are never signed.

Ainomos operators

If an Ainomos operator enters your organisation, for example for support, the log shows it: Operator entered the organisation, Operator left the organisation, Operator changed the status and Operator restored the organisation, with the reason given.

Fingerprints instead of plain text

An evidence record never stores the text of the question or the answer. It stores a fingerprint of each: a short code calculated from the text. The same text always gives the same fingerprint, but the text cannot be read back from it. If you still have the text, you can show that it matches the record. A translated question is kept as a fingerprint too. Sources are named by their identifier, owner and dates, not copied. Reasons people give for a governance change are stored as written. Rows in the audit log never show raw prompts or answers.

How records are protected

The chain. Each record in a room carries the fingerprint of the room’s previous record. If someone changed an old record later, its fingerprint would no longer match the one stored in the next record, and the chain would break at that point. The signature. When the installation has a signing key, Ainomos also signs each record with Ed25519 as it is written. A signature shows the record is exactly as Ainomos issued it. The log marks each record signed or not signed. Records written before signing was turned on stay unsigned. Checking the chain. Ainomos can walk every room’s chain, recompute each link and check each signature against the installation’s public key. The check reports per room how many records it found, how many are signed, and every break. It changes nothing and writes no record. Platform admins can run it through the Ainomos API, and the operator of an installation can run it as a command. There is no button for it in the app.
The Signing and verification part of an evidence record says when a record was signed at issue. It also says plainly that opening the record did not re-check the signature or the chain.

Open the audit log

1

Open the Audit log

Open Settings, then Audit log. The newest events come first, 25 per page. Use Previous and Next to page.
2

Filter

Set any of the filters below, then click Apply filters. Clear removes them all.
3

Open a record

Click Open Evidence on an event to see its evidence record.
Blocked or deferred covers two things that share one recorded status. A rule stopped something, shown in red, or a person accepted a relation whose effect is not active yet, shown as Activation deferred. Times in the list use your time zone. Times in an evidence record are in UTC. Both say so.

Read an evidence record

Evidence details shows the verdict at the top, then:
  • Run: the outcome and the start and end time
  • Model: requested and served
  • Scope: room, data class and memories
  • Cost: in USD, with tokens
  • Cited and Context only: the sources, counted separately
  • Policy decisions: each rule checked, with its outcome
  • Governance acts: what was changed, from what to what, and why
  • Raw data: the full record as stored, including its signature

Export

The audit log has no download button. To keep audit events outside Ainomos, send them to your SIEM. Click Forward audit events to a SIEM on the page, or see log shipping.