# Audit log

> The immutable admin audit log on the Voice AI Insights tab, and where the shared observability dashboards live instead.

The **Insights** section of the TeleQuick Voice AI console holds two
different kinds of history, on two tabs:

| Tab               | What it is                                          | Rendered where                     |
| ----------------- | --------------------------------------------------- | ---------------------------------- |
| **Audits**        | The immutable admin log for the current org.        | In the Voice AI console.           |
| **Observability** | Call quality, latency, QoE, and traces.             | In the shared platform console.    |

Only the first of the two is a Voice AI screen. The Observability tab is a
deliberate hand-off: it renders a short explanation and a link out, not the
numbers themselves. The rest of this page covers what the audit log is and
why the second tab sends you elsewhere.

## Where to find the audit log

Open the Voice AI console and select **Insights**. **Audits** is the default
tab, so the audit log is what you see first; you do not need to select it.

## What the Audits tab shows

The Audits tab renders the admin audit log for the organisation that is
currently selected in the console. The screen receives that organisation from
the surrounding console shell and passes it straight into the log view, so the
rows you see are scoped to one org at a time. Switching orgs in the console
switches the set of entries.

The log is an *admin* log. It is a record of administrative activity, and it is
distinct from per-call data: an individual call's setup timings, media quality,
and spans are not audit entries. For those, see
[Where the observability dashboards live instead](#where-the-observability-dashboards-live-instead)
below, and [Telemetry](/platform/telemetry) for the CDR and trace streams that
back them.

## Immutability

The audit log is immutable. The console exposes no edit and no delete
affordance for an entry — there is nothing in the Audits surface that mutates
a row that already exists. Treat entries as append-only: a change of state
appears as an additional entry rather than as a rewrite of an earlier one.

This is what makes the log usable as evidence. If you are reconciling "what
changed, and when", the ordering of entries is the record, and nothing in the
console can have re-ordered or amended it after the fact.

## Audits or observability: which tab answers your question

| Your question                                        | Surface                          |
| ---------------------------------------------------- | -------------------------------- |
| What administrative activity happened in this org?   | Insights → **Audits**            |
| Why did this call sound bad?                         | Shared observability console     |
| How long did setup / ASR / LLM / TTS take?           | Shared observability console     |
| What did the trace for this call look like?          | Shared observability console     |

## Where the observability dashboards live instead

The Observability tab does not draw charts. It states that observability is
**common to the whole platform** and links to the shared console, which covers:

- Call quality dashboards
- Setup, LLM, TTS, and ASR latency
- QoE — MOS, jitter, and loss
- Traces

Voice AI links out rather than forking these dashboards so that the numbers
stay in sync across voice and every other modality, instead of drifting in a
per-app copy. One shared implementation means one definition of each metric,
for every modality that reports it.

The **Open observability** button targets the root of the portal and opens it in
a new tab, so the Insights screen stays where it was. You need a portal session
in that tab; the button is a plain link, not an embedded view.

For the underlying definitions and wire formats behind those dashboards:

- [Telemetry](/platform/telemetry) — the metric families, OTLP trace fields,
  and the CDR columns that carry `jitter_ms`, `estimated_mos`, `packets_lost`,
  and the per-call timestamps.
- [Telephony Metrics](/glossary/metrics) — what MOS, jitter, loss, and PDD mean,
  and how each one is calculated.

## Related

- [Telemetry](/platform/telemetry)
- [Telephony Metrics](/glossary/metrics)