Integrity
Proctored assessments, and the evidence behind every flag
A proctoring tool earns its place by being right in both directions: catching the candidate who imported a solution, and clearing the one who did not. This page is the whole mechanism — what is recorded, what raises a finding, what each finding costs, and the signals this product refuses to score at all.
- Insertion threshold
- 250 chars
- Novel characters in one editor event before anything is raised.
- Largest genuine edit seen
- 62 chars
- Across a 22,024-event corpus of real sittings. The threshold sits four times above it.
- Camera finding needs
- 3 frames
- Consecutive corroborating observations, spanning at least 45 seconds of wall clock.
- Camera findings that score
- None
- All four ship non-counting. A company has to decide otherwise.
What a sitting actually records
Three streams, and it is worth being precise about them because the differences decide what the evidence can and cannot show later.
One screen recording, of one display
The candidate shares a display and that stream is recorded. The webcam is an overlay drawn inside the fullscreen exam page, not a second recorder — which means a candidate who shares the wrong display discards the camera evidence along with the screen evidence. The product detects that case and says so loudly.
Short clips around each finding
Rather than asking a reviewer to scrub two hours of video, the recorder cuts a clip around the moment a finding was raised — eight seconds by default, set per company. Some findings have no clip and cannot have one: anything derived after the fact on the server has no recorder to ask.
The edit stream
Every change to the code editor is logged as a Monaco range replacement, which is a complete keystroke-level record of how the answer was built. It is the source of truth for the insertion analysis below, and it is what makes session replay possible at all. It is also the one stream a tampered browser cannot quietly suppress, because the server reconstructs from it rather than trusting a flag the client sent.
What counts against an integrity score
These are the defaults every company starts on. Severity, weight and whether a type scores at all are per-company rows an administrator can change, so this table is a starting position rather than a law.
Two of those deserve a note, because they are the two evasions that cost a candidate nothing anywhere else. A second monitor is charged once, at the start, and then a candidate reading answers off the other screen never triggers a tab switch — the exam window is never hidden. So unfocused time is accumulated across the whole sitting and charged once at sixty seconds, and only where a second display was actually reported. Two seconds is a notification; eight minutes across a sitting is somebody reading.
What this product deliberately does not score
This is the half of the design that decides whether a proctoring tool is worth having. Every signal below is recorded, shown to the reviewer, and worth zero.
The four camera signals and the two "the recording shows nothing" signals are filed as Major even though they score zero, and that pairing is deliberate. Severity also drives display: low signals collapse behind a disclosure by default, which is what stops eighteen unfocused-window events burying one paste. The failure this closes is a reviewer watching confidently healthy footage of the wrong thing and concluding the candidate was clean. Hiding the line that says so would reproduce it exactly.
Code that arrived instead of being typed
The single most useful thing in the integrity record, and the one that took the longest to get right.
Most platforms detect a paste by asking the editor. The editor answers with a callback that does not fire for drag and drop, does not fire for middle-click paste, does not fire for programmatic insertion, and can lose a race with the change event during an ordinary paste. When the flag is missing, a large block of imported code is indistinguishable from typing to everything downstream.
One real sitting in this product logged 1,084 edit events, none of them flagged as a paste by the editor, and three single events that inserted 1,227, 1,028 and 797 characters. It scored 81.48% and read as high integrity. A whole solution appeared at once and nothing noticed.
So the flag is not trusted. The server replays the edit stream and reconstructs the document after every keystroke, which gives it the text that was removed as well as the text inserted — and therefore the only number that matters: how many genuinely new characters one event added. The threshold is 250. The largest genuine multi-character edit anywhere in a 22,024-event corpus of real sittings was 62 characters, so no bracket auto-close, auto-indent, tab-completion or snippet expansion can reach it.
Four guards, and the guards are the product
- A rewrite is not an arrival. Editors re-emit the whole document on undo, redo and format. One real candidate produced ten events of nearly seven hundred characters that way, each replacing a near-identical block. Raw character counts would have branded them a cheat ten times over.
- Cutting and pasting your own work back is not an arrival. Two real candidates re-inserted blocks that matched, character for character, text they had deleted earlier on that same question.
- Duplicating a block already on screen is not an arrival. One real candidate's 204-character insertion was already present verbatim in the document above it.
- Moving your own text between questions is not an arrival. This one was a confirmed false positive before it existed: a candidate typed 317 characters of test data into one question over 251 ordinary keystrokes — the largest single insertion among them was 36 characters — and moved it into another question eighteen minutes later. The detector saw a block appear from nowhere. Nothing had arrived — it was his own typing, from the next tab along.
When a guard accounts for a large insertion, that clearance is not thrown away. It becomes a first-class item on the session timeline with the guard named and its reasoning attached, so a reviewer can watch the exact moment a suspicious block appeared and read why it is not a finding. That is covered on session replay.
Two candidates, one answer
Insertion analysis proves a block was not typed. It cannot say where it came from, and it is blind by construction to two people submitting the same answer, both typed out by hand.
Answer similarity compares a submission against every other answer to the same question your organisation holds. Nothing compares source text: renaming a variable, reindenting and deleting the comments defeats a string compare in seconds. Every answer is lexed to a token stream with identifiers, numbers and strings normalised and comments dropped, and the two streams are matched with greedy string tiling — the same family of algorithm academic plagiarism tools use — because a plagiarist reorders functions and a linear diff scores a moved block as a mismatch.
Three forces push honest answers towards identical
- The question handed it to them. Everyone starts from the same template, the same prompt and, for SQL, the same schema and seed data. The question's own material is struck out of both answers before anything is compared.
- There is only one way to write it. After identifier normalisation, two correct SQL answers are nearly identical, because SQL has almost no vocabulary. That is what a right answer looks like, not evidence of anything. Token runs that recur across a large fraction of unrelated answers are struck out too — measured from your own corpus, so it needs no per-language boilerplate list and learns whatever your stack happens to be.
- The answer is too short to carry information. Six tokens of SQL is not collusion, it is two people being right. Below the volume floor there is no finding at any score, ever.
Camera analysis, and why it is off until you turn it on
Face analysis is a documented fairness problem in this category. It misfires in dark rooms, on glasses, on headscarves, and measurably worse on darker skin. A candidate wrongly flagged as an impersonator is a lawsuit, not a bug.
For most of this product's life the webcam was recorded and never looked at. It can now be analysed — nobody in frame, more than one person in frame, the person on camera changing, and a one-off photo-ID check at the start of a sitting. It is off by default, only an account owner can switch it on, and it is metered because it costs real money per frame. The reasoning behind that gate is the same reasoning as the guards: switching it on means sending candidates' faces and identity documents to a third-party model, which is special-category data under GDPR Article 9, and nobody should discover after the fact that a colleague enabled it.
Five guards
- One frame is never evidence. A finding needs three consecutive corroborating observations spanning at least 45 seconds — 90 seconds for an identity finding. Bending to pick up a pen, a housemate crossing behind, a yawn and a reflection each produce exactly one bad frame, and none of them can produce a finding.
- Unreadable is not empty. If the model cannot see the frame, the observation is recorded as indeterminate, never as "nobody there". A candidate in an unlit room is not a candidate who left.
- The accusing direction needs confidence; the clearing direction does not. A low-confidence "two faces" is discarded. A low-confidence "one face, fine" still clears the streak.
- Gaps break streaks. Corroborating frames too far apart are two unrelated moments, not a sustained condition.
- The prompt rules out the known biases. Skin tone, ethnicity, gender and age are excluded from identity entirely. A hijab, turban, kippah, cap, hood, face mask, glasses, a new haircut and new lighting are all stated as not identity changes. Faces on posters, monitors, phones and mirrors are stated as not people.
And the sixth guard is not technical: all four camera findings ship non-counting, at weight zero. They are shown to a human and they change no score unless your organisation decides otherwise. The output stored against each one is a sentence — what the model saw and why it said what it said — rather than a similarity distance, because nobody can explain a cosine distance to a candidate who has just been failed by one.
What this cannot do
Read this before you decide the assessment carries the weight of a hiring decision on its own.
- It is a browser-based proctor, not a locked-down desktop client. It sees the shared display, the exam tab and the camera. It cannot see the rest of the machine.
- It records one display. A phone on the desk, a second laptop out of shot, a printed page, or a person off camera are all invisible to it — the second-screen and second-device signals cover a narrow slice of that and nothing more.
- It cannot prove who was in the room, only what the camera showed for the frames it sampled. Without camera analysis on, it does not even do that.
- It cannot tell a crash from a deliberate escape. That is why a recording gap is recorded and worth nothing.
- It cannot tell you whether a candidate understood their own answer. The follow-up conversation still does that, and no detector replaces it.
- Blocking a candidate whose desktop spans several displays depends on a browser feature that exists in Chromium and nowhere else, so Firefox and Safari candidates cannot be gated at the door and fall through to the in-exam finding instead.
Who decides
A person does. Severity, weight and whether a signal counts at all are your rows, not ours, and they are resolved on the server so the score a reviewer sees and the score in a report cannot disagree. Findings are grouped, clipped and ranked; the replay puts them on the same timeline as the typing; and the recommendation at the end of the round is written by a human on a scorecard with a stated reason.
The same rule holds for the AI interviewer: there is exactly one code path that writes a decision about a candidate, and it requires a signed-in person with a role and records who they were. See the FAQ for how a candidate raises a challenge, and security and data protection for what is kept, for how long, and who else touches it.
Elsewhere on this site
Session replay
Scrub the whole sitting with the evidence laid over the same timeline — including the findings the guards cleared.
Screening developers
Answers that execute against test cases in 22 languages, with the console output the candidate actually saw.
Take-home projects
A multi-file repository against a deadline, reviewed as a diff — and an honest account of what a take-home cannot prove.
Campus and volume hiring
A roster, an assessment window, and one live console that answers the only question that matters on the morning: how many turned up.
Run one assessment and look at the record it produces
The fastest way to judge any of this is to sit your own test as a candidate and then open the review. Nothing needs to be configured first, and you can preview exactly what a candidate will see before you send it.