Exam integrity
Exams are on the Pro plan.
Students sit exams on their own devices, unsupervised by the software. Quorum records what a browser can honestly observe. This page is about reading those records without over-reading them.
Controls that prevent
These change what is possible, and are set up in Set up an exam.
| Control | Stops |
|---|---|
| Shuffle questions / choices | Copying from a neighbour's screen |
| One question at a time | Photographing the whole paper at once |
| No backtracking | Working the paper out of order with help |
| Access code | Sitting the exam without being where you said it out loud |
| Require session attendance | Sitting it without having been in the room |
| Short window | A forwarded link being useful later |
Signals that record
These do not prevent anything. They leave a trace.
Device identity. Each attempt records the browser it came from. The same signals as attendance check-in, stored in more than one place so clearing cookies does not produce a fresh identity.
Duplicate session detection. If the same attempt is opened somewhere else, it is detected and recorded. This is the signal that catches an attempt being shared — a link and ID handed to someone else while the student also has it open.
Leaving the page. Switching tab or app is recorded, as is the window losing focus.
Connection events. Refreshes and reconnections are logged, which is how an interrupted attempt is distinguishable from an evasive one.
The client may only report what a browser can observe. Starting, submitting, timing out, and duplicate-session detection are recorded by the server, not taken on the browser's word.
Reading the events honestly
This is where exam integrity tooling does the most damage in the wrong hands.
A tab-switch event means a tab was switched. That is all. Ordinary innocent causes:
- A notification, a call, or a message arriving.
- The browser backgrounding a tab on a phone that locked.
- Checking the time.
- A second monitor.
Volume is not proof either. A student on a phone with an unstable connection can generate a long trail of blur and reconnect events without doing anything wrong.
Duplicate session detection is the strongest signal here, because it describes something specific — the same attempt open in two places — rather than something ambiguous. It still has innocent causes: a phone that reloaded the page, or a student who opened the link on a laptop after their phone battery died.
None of this proves cheating, and none of it identifies who was at the keyboard. Quorum identifies a student by university ID. Someone else holding the link, the ID and the code sits the exam indistinguishably.
The events describe what a browser did. They do not describe who did it or why.
Handling a suspicion
- Look at the whole attempt — the timeline, not one event. Nineteen blur events over ninety minutes on a phone is noise; three tab switches clustered around the two hardest questions is a pattern worth asking about.
- Compare against the cohort. If half your class shows the same trail, it is your exam conditions, not thirty independent cheats.
- Ask the student. Nearly all of these have ordinary explanations.
- Describe, do not accuse. "Your attempt was opened on a second device twenty minutes in — can you tell me what happened?" is answerable and fair. "The system detected you cheating" is neither, and will not survive an appeal.
If exam conditions genuinely matter, invigilate the room. The software is a record of what happened, not a substitute for supervision.