The best online exam experience keeps the candidate focused on the exam, not on the verification technology. A learner opens a laptop, reviews the exam rules and completes a brief identity check before entering the test. If the platform performs additional checks during the session, those checks must be limited, transparent and proportionate.
Face technology is useful here because it can help answer whether the candidate presenting is consistent with the registered identity. It cannot, on its own, prove cheating or explain why a face was temporarily missing from a video frame.
Editorial illustration of a possible experience. Actual UI, device mounts and integrations vary.
Before the first question—and when the webcam view changes
A candidate sits at a desk wearing a headset and looking toward a laptop webcam. Before the test, the application guides framing and lighting, checks for a usable face, and runs a 1:1 comparison with the appropriate enrolled reference. The platform may incorporate liveness and document or account checks where its threat model requires them.
Later, the candidate leans down to pick up a pen or adjusts the laptop. A brief absence from the camera should create, at most, a reviewable event governed by exam policy—not an automatic accusation. The application should distinguish poor image quality, an interrupted connection, an inconclusive identity comparison and a deliberate rule violation. Only authorized exam staff should assess the context.
How the identity step connects to the business workflow
A practical implementation separates the camera interaction, the biometric result and the final business decision. AttFace Core can perform face detection, quality-related analysis, liveness checks where selected, and 1:1 verification or scoped 1:N identification. The partner application decides how to act on those results. Successful face matching alone does not grant access, certify attendance, authorize a transaction or resolve a disputed event.
Conceptual architecture, not a product screenshot or a statement that all pictured integrations are already deployed.
Separate candidate identity from proctoring conclusions
There are at least three distinct questions in an online examination:
- Initial identity: Does the person starting the exam correspond to the registered candidate?
- Session continuity: Is the person appearing at later checkpoints consistent with the same enrolled identity?
- Examination integrity: Did any event occur that warrants review under the assessment rules?
Face recognition can inform the first two questions. It cannot independently determine the third. A temporary camera outage, a person looking away, a poor-quality frame, or an uncertain face score is not proof of cheating.
This distinction should be visible in both the product architecture and the language used by reviewers.
Build around an appropriate registration reference
An examination platform must first establish how an enrolled reference is linked to the right candidate. Depending on the program, the source may be an approved registration image, supervised enrollment, or another identity-proofing workflow. The method should be documented, appropriate to the assessment risk, and consistent with privacy obligations.
If registration images are inconsistent in quality, the verification experience will inherit that problem. Capture guidance, image-quality checks, and enrollment retry procedures often matter as much as the matching model.
Avoid storing extra photos merely because the camera makes them available. Define a purpose for every retained image, template, and audit record.
A practical exam-verification sequence
Before the exam: the candidate sees the verification requirements, checks camera permissions, confirms the supported device, and learns what to do if a capture fails. Give candidates enough information to avoid a high-stress surprise on exam day.
At start: the application performs a user-initiated face capture, quality checks, and 1:1 verification against the candidate's reference. Where justified, it can add presentation attack detection (PAD, commonly called liveness) to assess certain spoofing attempts.
During the session: time-bounded or event-triggered checks may help assess session continuity. Their frequency should reflect the exam's risk and should not cause unnecessary interruption. Device state, permissions, and network conditions can produce anomalies unrelated to identity.
After the session: the system collects flagged events with timestamps and relevant context. A trained reviewer evaluates them under a published policy, rather than letting a model score automatically decide an academic outcome.
Illustrative candidate workflow; not an actual model-output screenshot.
Why 1:1 verification fits many exam workflows
Most exam platforms know the claimed candidate identity before the first question. That means 1:1 verification is often a natural fit: compare the presented face against the known candidate's enrollment instead of searching across every other applicant.
An identification search across many candidates is a different problem with different false-association risks. Use it only if the exam's enrollment and review requirements genuinely call for it.
A match score should be interpreted in the context of a preselected threshold, the image quality, and the system's evaluation conditions. It is not a universal percentage of identity certainty. For borderline captures, a guided retry or manual process is often more appropriate than silently moving the threshold to obtain a convenient match.
Liveness supports security, but it is not a guarantee
Presentation attack detection can help assess selected threats such as presenting a printed photo or a replay on another screen. It does not make every camera or application immune to more sophisticated injection and device-compromise attacks.
Plan for both sides of the problem: security against impersonation and usability for legitimate candidates. A real candidate in poor lighting should not repeatedly fail without a viable assistance path. A system may need an accessible alternative that follows the examination program's rules.
A meaningful security test defines attack types, device classes, retry limits, and the evidence collected when PAD cannot reach a usable conclusion.
Treat session events as reviewable signals
Consider the difference between these records:
| Observed event | Responsible interpretation |
|---|---|
| No face in one frame | Visibility interruption; request context or another sample |
| Different-looking face sample | Possible identity inconsistency; require corroboration and review |
| Multiple faces detected | Potential session event; interpret against exam rules and circumstances |
| Camera permission withdrawn | Device-state event; investigate before inferring intent |
| Failed liveness attempt | PAD result for the tested capture and threat scope; not a verdict |
Use neutral event names in product logs. “Identity requires review” is more defensible than “cheater detected” when the observation does not establish intent.
Design for accessibility, privacy, and proportionality
Candidates may have disabilities, limited bandwidth, older devices, or home conditions that make continuous camera use difficult. The assessment provider should describe available accommodations, an alternate verification path where appropriate, and the route for challenging a decision.
Document which biometric references, camera frames, recordings, metadata, and reviewer notes are stored; who can see them; where they are processed; and when they are deleted. In an examination context, recordings can reveal private details of a candidate's home. Collection should be limited to what the assessment genuinely needs and is permitted to process.
Human reviewers should receive role-based access and training, and candidates should know how adverse decisions can be appealed.
What to measure in a pilot
Test the entire candidate experience—not just the face model. Track successful initial verification, retries, manual-assistance frequency, time to start the exam, false-review volume, platform compatibility, upload failures, and reviewer resolution time.
Include representative camera conditions and network quality. Test both genuine and authorized adversarial scenarios under controlled conditions. Review the interaction between thresholds, retry policies, and event queues before launching at scale.
The best operational metric may be the percentage of eligible candidates who can complete a fair, supported verification journey without unnecessary interruption.
What is available today, and what needs integration
AttFace Core can provide detection, face quality, verification and relevant liveness checks for a proctoring platform. Scheduling, exam session logic, webcam permissions, rule configuration, evidence handling and human review must be implemented by the exam provider. The use case reflects an integration pattern and does not assert that AttFace Attendance is an exam platform or that every proctoring capability ships in the Core SDK.
Build the pilot around everyday people and devices
Test the real touchpoints shown in this story: a personally assigned phone, a wall-mounted phone or tablet, and a slim floor stand where appropriate. Include bright windows, colleagues walking together, glasses or PPE where relevant, a failed first capture, and a network interruption when the architecture permits local processing. Record first-attempt completion, retries, recovery time, auditability and administrator corrections—not just a face match score.
Make the next action explicit when image quality or identity confidence is uncertain. A repeat capture, a claimed-ID 1:1 flow, or an authorized assisted alternative is generally more responsible than quietly lowering the threshold. Document data retention, consent or other lawful basis, deletion and access controls for the deployment's jurisdiction.
Next step. Adding identity verification to an assessment platform? Contact AttFace to discuss capture, liveness, session rules and review boundaries.
