The audit view
SkyKeep records every access — allowed and refused — into a database that is physically separate from the one holding your documents, so that deleting a document can never delete the record of it. The audit view at /audit is that record on a screen: the newest entries, newest first, re-read on a timer. Open it from the Audit entry in the portal's left menu and it arrives in a second window, so you can watch the trail beside the work rather than instead of it.
What you are looking at
One row per event. Who is the account that acted — resolved to a name for readability; the audit database itself stores only an id. Action and Outcome are the vault's own vocabulary: an ingest that came out quarantined, a read that came out denied, a login that succeeded. Details carries the reason, and never the content — no document text exists anywhere in this database.
Reading the record is part of the record
Every refresh appends its own entry, in the same transaction as the read: a read that could not be audited did not happen. That is also why the view hides those entries from what it draws by default — a window of the newest hundred entries, refreshing every few seconds, would otherwise fill with its own reads within minutes. Only the successful ones are hidden: a read of the trail that was refused is recorded under the same action, and that is the entry you are most likely to be looking for, so it is always drawn. Nothing is removed from the record either way: the entries are all there, the exclusion — action and outcome both — is written into each read's own audit entry, and the Show the view's own successful reads checkbox turns the filtering off so you can see them.
Who may open it
An administrator, always. A compartment administrator (clientadmin) deliberately may not: it manages the shape of compartments and can read no document, and the trail is everyone's activity rather than structure. Anyone else only on a demonstration vault whose operator explicitly opened it. If your account may not read it, the page says so — and the attempt is itself recorded, because who tried to read the record is part of the record too.
What a person was shown
A search and an answer each record the versions and passages they handed over, not merely how many — so what was this person shown? is a question the record can answer. Ids only: the passage itself is document content and none of it is in this database. The What was this person shown box takes an account id and a window and lists those versions.
It obeys the same rule the trail obeys about reach. You are shown the ids only if you share a compartment with the person you are asking about; otherwise you are told how many versions were disclosed and the ids are withheld. An administrator holds no compartment, so that is the ordinary answer rather than an unusual one — the count answers how much without answering which. Asking is itself recorded, as its own disclosure-query action, and so is being refused.
Its window and its pace
How many entries the view shows and how often it re-reads them are both deployment settings (SKYKEEP_AUDIT_VIEW_LINES, SKYKEEP_AUDIT_VIEW_REFRESH_SECONDS). The interval is a load control as much as a cadence, since each tick is a real read and a real append; on a busy vault, raise it. The Pause button stops the timer without closing the window.