What our proctoring records, and what it deliberately doesn't

Proctoring software has a reputation problem, and most of it is earned. The category trained everyone to expect black-box suspicion scores, automatic failures, and accusations nobody can examine. Assessly's proctoring is built the other way round: the software records what happened, with times and context, and faculty decide what it means.

This is the plain version of that: what gets recorded during a proctored paper, who decides what happens next, where the software does act on its own and why, and what it refuses to do.

What it records

The proctoring catalogue has thirteen modules. The faculty member setting the paper chooses which apply. A practice quiz and an end-term exam should not carry the same machinery, and most papers use a handful. The modules fall into four families:

• Who is sitting it. Camera and audio monitoring tied to the signed-in student. The camera checks that the student is in frame; the microphone records sustained speech, not a cough
• The environment. Full screen is required, leaving it is recorded, and so is switching away from the paper
• One student, one device. A second sign-in to the same attempt from another device is blocked and recorded
• Input. Text pasted into the editor is recorded, with its length and a fingerprint of what was pasted

Each record carries a time. So what reaches faculty after the paper is a timeline, not a verdict:

• 10:18:40 left the paper for 4 seconds
• 10:31:07 pasted 212 characters into problem 2
• 10:44:52 left full screen

Two properties hold for every module. First, the student is told before the paper starts which modules are on and what each one watches. Second, whatever the faculty member enabled is sealed when the attempt begins. The rules cannot change halfway through, in either direction.

Who decides what a flag means

When a paper's records cross the thresholds the faculty member set, the submission is flagged for review. A flag is a question, not an answer. The faculty member reads the timeline and chooses what happens:

• Dismiss it, when the record has an innocent explanation
• Note it, so it is on file without any consequence
• Warn the student
• Deduct a number of marks they choose
• Disqualify the attempt
• Escalate it to the college's own process

They can record a note with the decision, and the student is told the outcome. The student can then appeal, in writing, from their results page. The appeal goes back to faculty, who can uphold the decision, overturn it, or reduce the deduction. Every step is recorded against the person who took it.

The same raw signal can support opposite conclusions, which is why a person has to draw them. A tab switch during an open-book paper means nothing. Forty tab switches and three large pastes during a closed-book exam mean something. Software sees the same event in both.

A flag with context can be reviewed, contested and upheld. A verdict from software can only be appealed against a black box.

Where the software does act on its own

Saying "people decide everything" would be too simple, and it would not be true. There are two places where the paper enforces a rule without waiting for anyone:

• A limit that ends the paper. A faculty member can set one for a signal. The usual rule is three: the third time a student leaves full screen or switches away, the attempt is submitted. The student is warned each time before the last, and the work saved up to that point is still marked
• Leaving the exam uses up the attempt. Closing the paper and walking away cannot buy a second, fresh attempt later

Neither is a judgement about cheating. They are exam rules, like "no phones on the desk", applied the same way to everyone. What the software never does is decide that a student cheated. No flag, on its own, zeroes a score.

What it deliberately doesn't do

There is no composite cheating probability. We do not compress a session into one accusatory number, because that number would be doing faculty's job badly while looking scientific.

We learned this the hard way. Until August 2026, Assessly ran a detector that put a percentage on how likely a student's written explanation was to be AI-generated. When we audited it, it did not measure what it claimed. It read only the explanation, never the code, while three screens labelled the result as flagged code. The model underneath was built to catch prompt-injection attacks, not to tell who wrote a paragraph. Across more than three thousand graded submissions it produced a number for fewer than forty, and every one of those numbers was 0 or 100. One student's nine-word explanation, spelling mistake included, was flagged for "polished language with no grammatical errors".

We withdrew it from every screen on 26 August 2026. The old numbers are no longer shown to anyone, staff or student. We have not replaced it, because nobody can currently tell reliably whether a paragraph was written by a person or a model, and a tool that pretends it can will be wrong about real students.

Why evidence beats accusations

Misconduct processes at universities are close to legal ones: there are committees, hearings and appeals, and the standard is evidence that survives scrutiny. A proctoring system that outputs accusations creates work and risk, because every case starts with defending the tool. A system that outputs a timeline lets faculty walk into a review with facts.

It is also fairer to the student. They know what is watched before they start, they can see the decision and the reason for it, and they can answer it.

Honest limits

No proctoring stops a sufficiently determined person, and anyone who says otherwise is selling something. A second phone below the desk is outside what a browser can see. Lockdown raises the cost of cheating and records the attempt; it does not make cheating impossible.

The stronger protection is the paper itself. When it asks the student to explain their code as well as write it, work that slipped past the room still has to survive "tell us what you did and why". We cover that side in Stopping AI cheating in coding exams.

To see the integrity timeline on a real paper, book a demo.