Feature

Proctoring signals, live sessions and human judgement

Proctoring here means two things: integrity signals collected by the candidate runtime, and a live session where a supervisor can see and talk to a cohort while they sit the test.

The signals that are collected

With proctoring enabled, the candidate runtime reports browser-level integrity events and keeps a running violation count on the attempt.

Focus events: Tab switch, window blur, and fullscreen exit — the candidate leaving the exam surface.
Content events: Copy, paste, and right-click, which is what an attempt to lift question text looks like.
Tooling events: Developer-tools open.
A threshold you set: Past the configured violation count the runtime can warn the candidate, force-submit the attempt, or — at your discretion — ban them from the test.

Live sessions

A test launched in supervisor mode opens a live session with a waiting room. Candidates queue, you watch the roster fill in real time, and everyone starts together when you press start. Candidate launch mode is the alternative: each candidate begins as soon as they register.

During a session you can message the whole cohort or one candidate, at informational, warning or critical priority, and messages carry read receipts. Candidates can message back. A session can be ended forcibly at any point, and ended sessions are archived to a session history you can read afterwards.

What supervisors see

Live roster: Who has joined, who has started, and where each candidate is in the paper.
Violation counts: Per-candidate integrity events as they happen, so an emerging pattern is visible during the exam rather than after it.
Force submit: End an individual attempt, or the whole session, when you judge that it should stop.

What this does not do

Worth knowing before you plan around it.

These are browser-level signals, not identity verification. There is no webcam recording, no screen recording, no face match, and no keystroke biometrics. A signal tells you the exam surface lost focus — it does not tell you why, and it is not evidence on its own.
A determined candidate on a second device is outside what any browser-level check can see. Treat the violation count as an input to a human decision, and pair high-stakes exams with supervised live sessions.
Real-time monitoring needs a live WebSocket connection. Where that is unavailable the runtime falls back to polling, so roster updates are near-real-time rather than instant.

Common questions

Does proctoring record the candidate’s camera or screen?

No. The runtime reports browser integrity events — tab switch, window blur, fullscreen exit, copy, paste, right-click, developer-tools open — and a violation count. There is no webcam, screen recording, or biometric identity check.

What happens when a candidate crosses the violation threshold?

Whatever you configured: a warning to the candidate, an automatic force-submit of the attempt, or a ban from the test. The supervisor can also intervene manually from the live session.

Can the supervisor and candidate talk during an exam?

Yes. Live sessions include assessor chat — broadcast to everyone or message one candidate, at informational, warning or critical priority. Messages are stored with read receipts.

Run a supervised exam

Open a live session, watch the roster, and keep the cohort in sync.

See plans and pricing How the assessment engine works