Evidence for a human decision
We capture what happened during an exam and show it to your reviewer on one timeline. We never fail anyone automatically.
Proctoring observes and records; it never refuses an attempt.
The platform stores what the exam client reports, timestamped, and presents it as a reviewer timeline. Whether an attempt is acceptable is a judgement your team makes afterwards — not a gate anyone has to pass. Nothing we capture can end an honest person's exam.
What we capture
Five kinds of observation, each timestamped and attributable to a single attempt.
Camera stills
Periodic JPEG stills, not a streamed video feed. The live preview the participant sees is deterrence; the stills are the evidence.
Screen images
Captured as evidence alongside the camera stills, on the same timeline.
Audio clips
Short clips, timestamped, so a reviewer can hear the room rather than guess at it.
Fullscreen events
Exiting and re-entering fullscreen are two separate timestamped records. The reviewer UI pairs them to show how long they were away.
Device fingerprint
A baseline snapshot when the attempt starts, then deltas as things change.
Bounded by design
Every stream is capped per evidence kind and per event type, so a misbehaving client cannot flood the record.
One timeline per attempt
Evidence and events merge into a single time-ordered timeline. Your reviewer reads it and decides.
There is no risk score, no verdict, and no automatic rejection. The platform's job is to make what happened legible; the judgement stays with your team, where such a decision belongs.
Illustrative example — not real attempt data.
What the browser can and cannot see
Exams are sat in the browser, and the attempt records the client that produced the evidence. That matters when you read the record, because a browser simply cannot see some things at all. It cannot enumerate running processes, detect a virtual machine, or notice a USB or HDMI device being plugged in.
So the honest reading of a quiet timeline is "we could never look", not "we looked and found nothing". We would rather say that plainly than let an absence of signals be mistaken for a clean bill of health — in a dispute, that distinction is the whole point.
Outside what a browser can observe
- Other processes running on the machine
- Whether the exam is inside a virtual machine
- USB or HDMI devices being connected
- A second screen, phone, or another person in the room
None of these are checked and cleared — they are outside what the platform can observe.
Camera and microphone status is declared, not detected
Participants tell us whether their camera and microphone are working. We do not try to detect it, and we never block the exam over it.
The reason is simple: a camera the browser cannot open is indistinguishable from one one that was covered. Refusing the exam on that signal would strand someone whose hardware genuinely failed — and that is a cost no honest participant should pay.
In the record, "never asked" and "told us it was broken" stay distinct, so a stretch with no camera frames can be read correctly instead of assumed to be evasion.
What proctoring cannot do
Most proctoring vendors will not write this section. We would rather you know now than discover it during a dispute.
Cheating cannot be prevented
Not in the absolute. A second laptop, a phone, or another person in the room defeats any software running on the exam machine. Anyone claiming otherwise is selling you something.
What we do instead
Deter, and collect evidence for review. Someone who knows the room is being recorded behaves differently — and where something does happen, your reviewer has the record to look at. The question paper itself is defended separately — see anti-AI measures.
What is genuinely solved
Exam traffic is protected by HTTPS, and correct answers are never sent to the exam device — so there is nothing on the wire worth intercepting.
Where the evidence lives
Evidence bytes — camera stills, screen images, audio clips — are stored in object storage. Only references and event rows live in the database. Evidence is visible to reviewers in the owning organisation, and to no one else.
Retention periods and participant rights are covered in the Privacy Policy. Note that for participant data, the organisation running the assessment is the controller and ZiniApps is the processor — requests are directed to the organisation that issued the assessment.