Modern proctoring platforms use deep learning models to track faces, detect phone usage, and identify suspicious behaviour in real-time. Here's a technical breakdown of how ProctrMe's AI proctoring engine works under the hood.
The Technology Stack
ProctrMe's AI proctoring engine is built on two primary machine learning models that run entirely in the browser using TensorFlow.js, ensuring student privacy by processing video frames locally without sending them to any server.
TinyFaceDetector: Real-Time Facial Tracking
The first layer uses face-api.js with the TinyFaceDetector model — a lightweight convolutional neural network (CNN) specifically designed for real-time face detection on edge devices. Unlike heavier models like SSD-MobileNet, TinyFaceDetector was optimised for mobile and browser environments, achieving detection speeds of 20-30ms per frame on modern hardware.
The model processes webcam frames at configurable intervals (2-4 seconds depending on device capability) and detects the presence, position, and count of faces in the frame. This enables three critical integrity checks: (1) verifying the test-taker is present, (2) detecting if the test-taker looks away from the screen for extended periods, and (3) flagging if multiple faces appear in the frame, suggesting unauthorised assistance.
Why does browser-side inference matter beyond privacy? Latency and scale. A cloud pipeline must capture a frame, compress it, upload it, queue it for GPU inference, and return a verdict — often seconds later, and at a per-student server cost that grows linearly with cohort size. Local inference produces a verdict in tens of milliseconds at zero marginal server cost, which is what makes it feasible to proctor hundreds of students simultaneously without degrading anyone's exam experience.
COCO-SSD: Phone & Object Detection
The second AI layer employs the COCO-SSD (Single Shot Multibox Detector) model, trained on the Microsoft COCO dataset of 80 everyday objects. ProctrMe specifically monitors for "cell phone" class detections — when a student brings a phone into the camera's field of view, the model identifies it with typically 70-90% confidence and immediately triggers a violation alert.
Running COCO-SSD is computationally expensive, so ProctrMe uses an adaptive scheduling strategy: on desktop devices, it runs every 3rd face-check cycle; on mobile devices, every 4th-5th cycle. This balances security coverage with device performance, preventing the AI from causing lag during the exam.
Adaptive Performance Configuration
Not all devices are equal. A student taking an exam on a low-end Android phone with 2GB RAM needs a different processing strategy than a student on a modern laptop. ProctrMe's adaptive performance system automatically detects device capabilities and adjusts:
- Face detection input size: 128px on mobile (fastest) vs 160px on desktop (more accurate)
- Detection interval: 4 seconds on low-RAM devices, 3 seconds on mobile, 2 seconds on desktop
- Phone check frequency: Every 5th cycle on low-RAM, every 4th on mobile, every 3rd on desktop
- Score threshold: Slightly higher on mobile (0.35) to reduce false positives from lower camera quality
From Detection to Decision: How Violations Are Scored
Raw model output is noisy, and treating every detection event as a violation would flood proctors with false alarms. A student adjusting their glasses might briefly obscure their face; a poor webcam in low light might drop face detection for a frame or two. To handle this, detection events pass through a severity pipeline before anything is flagged.
Transient events — a single missed face detection, a borderline-confidence object detection — are recorded but held below the alert threshold. Sustained or repeated events escalate: a face absent for many consecutive checks, multiple faces persisting across frames, or a phone detected repeatedly in the same region of the frame. Only escalated events surface as real-time alerts on the proctor dashboard, each with a timestamp and violation type so a human can review the moment in context. The final judgement always belongs to the proctor and the institution's academic-integrity process, not to the model.
Limitations and Honest Trade-offs
No AI proctoring system is infallible, and it is worth being explicit about the boundaries. Object detection can miss a phone held below the camera frame or mistake a calculator for one at low confidence. Face detection performs worse in poor lighting and at extreme camera angles. Models trained on general-purpose datasets can show accuracy differences across demographics, which is one more reason automated flags must feed human review rather than automatic penalties.
These limitations are managed, not ignored: adaptive thresholds reduce false positives on low-quality cameras, pre-exam checks catch lighting and positioning problems before the exam starts, and every flag is stored as reviewable evidence rather than a verdict. The system's job is to make cheating risky and visible — not to replace human judgement.
Privacy-First Architecture
Unlike cloud-based proctoring solutions that stream video to remote servers for analysis, ProctrMe processes all video frames locally in the student's browser. No video footage is ever uploaded or stored. Only metadata — such as violation timestamps, types, and counts — is recorded in the session log. This approach aligns with GDPR and data minimisation principles while still maintaining rigorous exam integrity monitoring.