Dashboard

The dashboard is where operators review live and historical proctoring sessions. It includes an overview page, attempt-aware session grouping, recent activity state, preflight history, a synchronised review player, raw event timeline, reviewer notes and decisions, demo test builder, app-key controls, billing usage, and webhook delivery logs.

Overview

The Overview page is the landing page: headline KPIs for the organisation, a 7-day session sparkline, an integrity-flag breakdown, and a recent-sessions feed. It is the quickest read on whether anything needs attention today.

Demo test builder

Demo tests let an owner or admin build a self-contained proctored assessment from the dashboard — no code required — to trial the product or show a stakeholder an end-to-end run. A demo test can include written, multiple-choice, listening multiple-choice, speaking, and video questions. Publishing a test produces a shareable candidate link, keyed by testId, that runs the assessment with ProctoredAssessment: it resolves the attempt, runs or skips preflight from the saved policy, then renders the questions one at a time.

Sessions created from a demo link are real proctoring sessions, but they are marked demo. The Sessions page defaults to live sessions only; use the session-source filter to inspect demo runs or include both live and demo rows.

The builder also owns the demo assessment's proctoring policy. The policy is saved on the backend and returned by the public SDK assessment endpoint. Candidate-link query params can choose appId, testId, correlationId, and candidate identity, but they cannot turn required preflight or runtime proctoring checks off.

Runtime face analysis (face presence, multiple faces, gaze, identity matching) runs in the candidate's browser during the test and emits face.* events into the timeline. Identity matching needs a reference, so it requires the preflight face photo to be enabled.

Listening questions are multiple-choice questions with an attached audioUrl in the question config. The assessment plays that URL through client.playAudioFile(), so prompt playback is visible in the session timeline without storing signed URL query strings.

Speaking questions call client.recordAudioClip(). Video questions call client.recordVideoClip() with the question's configured max duration. These answer clips are separate from passive webcam or screen-share proctoring recordings.

Session states

The sessions table shows the stored session status plus a recent activity state derived from SDK heartbeats and incoming events. Demo sessions show a Demo badge when included in the list, are excluded from live usage counters, and are automatically purged after 24 hours.

Sittings, attempts, and retakes

The client-owned correlationId is the spine: it stays stable across everything a candidate does for one exam. Each sitting maps to one internal sess_... id — one session, one URL, one record. If the candidate disconnects and comes back, or moves to another device, the stale attempt is marked abandoned and a new attempt opens inside the same session; the session id does not change.

Session detail shows the internal session id, app-key prefix, preflight state, and Last active. When a sitting has multiple attempts, the Attempts dropdown scopes the view to one attempt, and the "All attempts" view shows the whole sitting. A sitting locks when an attempt ends cleanly — the candidate can add nothing further to its record.

Continuing after a lock is a retake: a new session under the same correlationId, linked to the prior sitting by a retake reference, with its own URL and its own record. Retakes appear in the Retakes dropdown and each sitting is reviewed on its own — events are never merged across the retake lineage.

Integrity score

The score is a transparent formula, not an opaque vendor heuristic. Each flagged event carries a per-category penalty, each category's total saturates at a cap so no single behaviour can sink the score on its own, and the summed penalty is subtracted from 100 with the result clamped to 0-100. A reviewer can always see exactly why a session scored what it did.

Recovery events (*-cleared, *-restored, face.returned) never count against the score.

Review workspace

Session detail opens in a focused, sidebar- and navbar-free review workspace with a compact back-to-sessions control in the session header. On desktop, the workspace fits the browser viewport without page scrolling; the evidence player expands into the available height and the evidence timeline fills the right rail with continuous internal scrolling. The synchronised player stays on the left, with screen and webcam recordings, a draggable picture-in-picture inset of the other stream that preserves its relative position when entering or leaving fullscreen, in-player seeking and playback-speed controls, and a jump-to-next-finding control. Under the transport, per-category swimlanes plot each integrity signal against the recording clock — identity and face, objects in frame, screen and input, and answering — each row carrying its own count, with a snapshot filmstrip beneath them. When captured snapshot photos are available, a photo carousel appears below the recording, highlights and follows the latest snapshot at the video playhead, and seeks the recording when a reviewer selects a photo. The carousel is omitted when the session has no snapshots.

The workspace opens in one of two views, chosen by a toggle above the player. Recording holds the continuous capture a reviewer scrubs — screen, webcam, and snapshots — with the picture-in-picture inset carrying a control that promotes the inset stream to the main view. Artifacts holds the discrete work the candidate produced — writing, audio, and video answers — as a list beside the opened answer, with a count of the total on the toggle. The selected view and tab are kept in the page URL, so a reload or a shared link reopens the same place.

The right rail is identical in both views, so switching never costs the reviewer the verdict. It leads with the integrity score and a breakdown of the categories that reduced it, each showing how many times it occurred and how many points it removed; because every category is capped, a repeated behaviour cannot sink the score on its own, and the breakdown shows the true occurrence count alongside the capped penalty. Below it, Findings lists the scored integrity signals newest-severity first, each with its severity, its timestamp and the points it carries; selecting one seeks the recording to that moment and expands an explanation of what the signal means. Everything is the full evidence timeline described below, and Notes holds internal reviewer notes.

The evidence timeline is a factual record rather than a review checklist. Every captured evidence event appears as its own timestamped row. Seeking is calculated independently for the active screen or webcam recording, because the two sources can start at different moments. An event outside the selected source's recorded coverage remains visible but is not seekable; it is never clamped onto an unrelated first or last frame. Snapshot position uses capture time rather than upload time. When an event includes customer-visible payload metadata or linked image evidence, a disclosure control expands the row. Available images appear as a thumbnail with a full-size preview and a provenance label: Screen recording frame, Live screen capture, or Page capture. The row also distinguishes an exact event frame from a best-effort capture. If capture was impossible, the disclosure shows the unavailable reason. Internal identifiers, credentials, and transport fields remain excluded. Filters narrow the timeline by violation, concern, information, evidence source, metadata, or search text. Routine lifecycle and recovery events remain visible as quiet standalone rows. The timeline does not mark evidence as viewed or prompt a reviewer to complete individual events. A session-header action opens the separate review-decision drawer with the verdict controls and internal notes. Review decisions remain session-level, permission-gated, and recorded in the audit log.

Writing review

Sessions with proctored writing answers get a Writing view in the workspace: per-answer integrity summaries covering paste volume, typing dynamics, a writing-assistant footprint badge, focus-away count, and a checkpoint replay of how each answer grew over time.

Reviewer notes

Each session carries an internal notes thread — a composer plus a chronological list of past notes with their authors. Notes are for the review team only: they are excluded from the clean PDF report and appear only in the report variant that explicitly includes reviewer notes.

Filtering the timeline

Use the chips above the timeline to filter by category, toggle "Flagged only" to keep just the rows a proctor would action, narrow to specific kinds with the multi-select, or type into the search box.

Saved views and bulk export

Any filter combination on the sessions list can be saved as a named view for one-click reuse. Rows can also be bulk-selected; the selection bar that appears exports the selected sessions as CSV.

Billing and quotas

Settings -> Billing shows the workspace subscription, billable sittings, included allowance, projected overage, event volume, and media/storage usage for the current billing period. Only the workspace owner can open Checkout or the Stripe Customer Portal.

Developer workspaces use Stripe Checkout to start their first paid subscription. A paid workspace changes its existing subscription in place: upgrades on the same billing interval take effect immediately after an invoice preview and charge the prorated difference, while downgrades and monthly/annual interval changes are scheduled for the next renewal without proration. Moving back to Developer cancels at period end without a prorated refund. The billing page shows any pending plan and its effective date. Stripe remains the source of truth, and signed subscription webhooks reconcile the displayed plan after each change.

A billable sitting is recorded once when the first runtime attempt starts for a live session. Candidate refreshes, reconnects, and within-session resume attempts do not create another charge. An explicit retake is a new sitting and counts separately. Demo assessment runs stay available for review for 24 hours and never enter the billing ledger.

Developer includes 50 sittings per calendar month and blocks a new sitting at the limit. Paid plans permit overage when the subscription is active or still inside its payment-failure grace period. Crossing a limit never terminates an assessment already in progress.

Event and media counters remain operational capacity signals. They are not separate invoice line items in the initial pricing model.

Webhook delivery log

Settings -> Webhooks lets an organisation create endpoints, select subscribed lifecycle events, pause or resume delivery, and inspect delivery attempts. The endpoint detail page shows status, attempt number, response code, response snippet, next retry time, and resend controls.

Other settings

• Members — invite teammates and manage the owner, admin, proctor, and viewer roles.
• Notifications — per-user choices for which lifecycle events arrive in-app and by email.
• Audit log — a record of actions taken in the organisation.
• Organisation — organisation profile and details.
• Keys — app-key management, including each key's allowed origins.
• Status — status-page administration (platform operators only).

Exporting evidence

The sessions list can export the filtered result set as CSV. A session detail page can export the event timeline as CSV, download a clean PDF report, or download a PDF report that includes internal reviewer notes.