The FirstByte Voice AI console keeps two different kinds of history in two different places: Only the first is a Voice AI screen. The dashboards are shared by every modality, so the Voice AI console does not draw them. The rest of this page covers what the audit log is and why the dashboards live in the portal.

​
Where to find the audit log

Open the Voice AI console and select Operations → Audit log.

​
What the Audit log shows

The Audit log screen 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 below, and 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 on the Audit log screen 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.

​
Audit log or observability: which screen answers your question

​
Where the observability dashboards live instead

The Voice AI console does not draw observability charts. Observability is common to the whole platform, so the dashboards live on the portal Observability page, which covers:
  • Call quality dashboards
  • Setup, LLM, TTS, and ASR latency
  • QoE — MOS, jitter, and loss
  • Traces
Voice AI does not fork these dashboards, so 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. You need a portal session to open the Observability page. For the underlying definitions and wire formats behind those dashboards:
  • 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 — what MOS, jitter, loss, and PDD mean, and how each one is calculated.