Reviewer Tooling Guide

This guide walks through the reviewer-side of ProctorSafe: how a reviewer reads a session's results, how they start and close a review, how they exclude events that the detector fired on by mistake, and what the audit trail records about the sitting. It is written for the person who has to size internal staffing — operations leads, compliance officers, DPOs — rather than for the engineers building the integration.

A session in ProctorSafe is one proctored attempt. The system collects a small, fixed set of signals during the attempt and turns them into a trust score (0–100) and a per-type breakdown of how the score was reached. The reviewer's job is to confirm the system got it right, or to correct it where it didn't. Everything on this page is about that confirmation step.

Table of Contents

1. What the reviewer sees
2. Reading the trust score breakdown
3. Starting and closing a review
4. Excluding events
5. The audit trail
6. Staffing cheat-sheet
7. Where this fits

What the reviewer sees

A reviewer opens the session detail page for a single session. The page has three regions: a header with the session's identifying facts and current status; a centre column with the trust score, the breakdown, the AI summary, and the timeline; and a right column with reviewer-specific controls.

The header carries the session's applicationRef, the candidate's identifier (hashed at the source so no PII leaves the device — see Privacy), the duration, the trust-score version the session is scored under, and the current status. Status is one of ACTIVE, COMPLETED, ABORTED, or TERMINATED. A session reaches the review queue when it is COMPLETED or TERMINATED with a score below your tenant's review threshold.

The trust score is a single number from 0 to 100. The colour band is the dashboard's standard one: green at 80 and above, amber between 60 and 80, red below 60. The threshold for "needs human review" is a tenant setting, not a ProctorSafe default — most deployers set it at 80.

Below the score, two further regions matter to a reviewer:

• The AI summary is a two-to-three sentence paragraph generated after the session ends, naming the dominant signals and giving a recommended action (Approved, Flagged, Voided, or Inconclusive). It is decision-support — the reviewer's outcome is the binding one.
• The timeline is the raw event stream the system recorded during the attempt, in chronological order. Each event has a type, a timestamp, a severity (information / minor / major / critical), and a one-line label. Reviewers who exclude events do it from here.

Reading the trust score breakdown

The breakdown answers the only question the trust score itself does not: which behaviour cost the most points?

A score of 62 looks identical to a score of 62 with a different cause, so the breakdown groups all events by type and shows each type's total cost as a horizontal segment on a shared scale. The bar's full length is the 100-point integrity budget — a perfect score is an empty bar, a score of 62 means 62 points were spent.

The colour encodes severity, not type. There are more scoreable types than a categorical palette can separate, so two types at the same severity look similar; identity rides on segment order (which matches the row list below the bar exactly) and on the 2-pixel gap between segments. Hovering a row in the list highlights the matching segment and dims the others.

Each row carries:

• The type's display name (e.g. Tab blur, Multiple faces, Look away).
• The severity chip (Information, Minor, Major, Critical).
• The incident count — how many distinct episodes of this type the system recorded.
• The total duration — how long across the attempt.
• The total cost — the points this type removed from the score, with the matching bar segment.

A type can show a high incident count but a low total cost (many short blips), or a low incident count with a high total cost (one sustained episode). The distinction is what tells a reviewer they are looking at a one-off technical blip rather than something more deliberate.

Starting and closing a review

A review is a bounded sitting on one session. Starting one is optional — committing any event exclusion opens a review by itself, and so does the system flagging the session for review. The explicit Start review button is for reviewers who want to pin the starting score before they touch anything.

When a review is open, two facts are captured automatically:

• The score at start — the trust score the session had the moment the review opened. It is recorded whether the reviewer opened the review themselves, committed an exclusion, or the system did it on their behalf.
• The score at close — the trust score the session has when the review closes.

The difference between the two is the net effect of the reviewer's changes, not the trust score itself. A review can close with a higher score than it opened (because the reviewer excluded events that the detector fired on by mistake) or a lower one (because the reviewer's exclusion tightened the breakdown). Both are valid.

Closing a review requires an outcome and optionally an internal note:

The internal note is optional, capped at 1000 characters, and stays inside ProctorSafe. It is never sent to the candidate or to the integrator. It exists so that a second reviewer (or a compliance reviewer during an audit) can read why the first reviewer decided what they decided.

Excluding events

The detector is allowed to be wrong. A reviewer can mark an event or a run of events as excluded from the trust-score calculation. Excluded events stay on the timeline — they do not disappear — but they move to a separate Excluded lane and no longer cost points.

The flow is select → preview → commit, in that order:

1. Select. In the timeline, the reviewer shift-clicks a run of events, or clicks a grouped burst to select it whole. A sticky tray at the bottom of the page shows the running selection and the score-projection as the selection changes.
2. Preview. The projected score — what the trust score would be after this exclusion — updates with each selection change. Reviewers can see the effect of their change before they commit.
3. Commit. A modal asks for the category and the comment. The category is one of six:

The comment is mandatory and capped at 1000 characters. It is the justification a future reader — a second reviewer, a compliance officer, a candidate's appeal — will read to understand what the reviewer saw. Asking for the comment after the reviewer has seen the projected score (rather than before) is deliberate: a required comment field asked first turns into boilerplate, and the comment is the most useful artefact the system records.

When the exclusion commits, three things happen at once: the events move to the Excluded lane in the timeline, the trust score recomputes, and an audit-trail row is recorded with the before/after score, the category, the comment, and the reviewer as actor.

A reviewer can also restore excluded events — bring them back into the counted timeline. The same comment discipline applies, with a RESTORE_EVENTS action recorded in the audit trail rather than EXCLUDE_EVENTS.

The audit trail

Every status change and every reviewer action on a session is logged. The log is append-only and cannot be edited, even by a tenant admin. It is the operational record of who did what, when, and why — and it is what a compliance reviewer reads during an audit.

The audit trail merges two kinds of row:

• Status changes — when the session moved from one status to another (e.g. ACTIVE → COMPLETED, COMPLETED → TERMINATED after a void). Each row carries the from-status, the to-status, the reason (when given), the actor, and the timestamp.
• Review actions — EXCLUDE_EVENTS and RESTORE_EVENTS from a reviewer. Each row carries the action type, the category, the comment, the score before, the score after, the actor, the timestamp, and the list of event IDs touched. A RESTORE_EVENTS row carries the ID of the EXCLUDE_EVENTS it reverses, so a reviewer can follow the reversal chain.

The default filter is All. Reviewers can filter to Status only or Review only when they want one stream. Each row is expandable so the comment text (often the longest field) does not dominate the list by default.

The audit trail is also exposed via the ProctorSafe webhook system on three events: review.started, review.closed, and review.action_recorded. Integrators who want to react to a session being reviewed — for example, to surface it in their own case-management tool — subscribe to those webhooks rather than polling.

Staffing cheat-sheet

The numbers below are rough guides based on what the dashboard currently shows in production deployments, not commitments. Treat them as the starting point for sizing, not the answer.

Time per sitting. A reviewer who is approving a clean session spends about 2–3 minutes on it: glance at the trust score, scan the breakdown, confirm the AI summary, close with Approved. A reviewer who is flagging spends about 6–10 minutes: read the timeline, decide whether the issues warrant exclusion, often exclude one or two events, then close with Flagged and a comment. A reviewer who is voiding spends about 10–15 minutes: the void requires confidence, so reviewers typically re-read the full audit trail and the AI summary before committing. Inconclusive sits at the high end of the flagging range because the reviewer has to write down what they could not decide.

Reviewer-to-candidate ratio. This is the question that has no clean answer, because it depends on what fraction of sessions reach the review queue. A tenant that flags everything below 80 with no automatic exclusions will see a much higher queue than a tenant that flags only below 60 with the most common false positives auto-excluded. A reasonable starting assumption for sizing is one reviewer per 500 candidates per exam sitting when the threshold is at 80, falling to one per 2,000 when the threshold is at 60. Most of the variance is threshold-driven, not volume-driven.

Authentication and audit binding. Every reviewer action is bound to a real authenticated user account. A review cannot be opened or closed by an anonymous actor, and a tenant cannot disable the audit trail. The integration you set up determines who counts as a reviewer (your staff), not whether every action is logged — the logging is on by default and cannot be turned off at the tenant level.

Working hours. The review queue does not require real-time review. Sessions become eligible for review the moment they reach COMPLETED or TERMINATED, and the audit trail records the time the reviewer opened the closed the sitting — not the time the session ended. A team that reviews in batches once or twice a day is functionally equivalent to one that reviews continuously, with a backlog that clears overnight.

Where this fits

This page covers the operational view of human review: what a reviewer sees, what they can do, and what the system records. The legal and ethical framing — the requirement that a human must meaningfully oversee an automated decision, the conditions under which ProctorSafe qualifies, and the limits of what a human reviewer can do — lives in two adjacent articles:

• EU AI Act compliance for online proctoring — what the regulation asks of a deployer and how ProctorSafe's architecture answers it.
• Human-in-the-loop: bias, fairness, and the role of the reviewer — the ethics of the reviewer sitting itself: what training a reviewer needs, what second-reviewer structures look like, and what ProctorSafe's audit trail is and is not designed to support.