FaceCertify

Background

This was our S6 mini project at APJ Abdul Kalam Technological University. A team of four. We were looking for a problem that was real, not just something that sounded good in a project report.

Exam impersonation is one of those problems that doesn't have a great solution at most institutions. ID-card verification happens in a rush, invigilators are managing a lot at once, and a paper ID is easy to misuse. We wanted to see if facial recognition could make that verification step more reliable and less manual.

What we built

FaceCertify is a web-based system where a student walks up to a webcam at the exam hall. The system captures their face, matches it against a pre-trained model, and if it finds a match, it shows their exam details -- subject, classroom, seat number -- and marks attendance automatically. An admin panel lets the exam coordinator manage student records and view attendance logs without touching any code.

The rate limiting is set to three recognition attempts per IP per day, which is a basic safeguard against someone systematically trying to match faces that aren't theirs.

How the recognition works

The face_recognition library (built on dlib) extracts a 128-dimensional vector from any face image. You can think of it as a fingerprint -- a mathematical representation unique to that person's face geometry. During training, the system generates these vectors for multiple photos of each student and stores them.

At exam time, the same process runs on the webcam capture. The resulting vector is passed to an SVM (Support Vector Machine) classifier that maps it to a student identity. If confidence is above 70%, it's accepted as a match. Below that, it's rejected.

Training phase:
  10-20 photos per student → face encoding (128D vector) → SVM trains on these

Inference phase:
  Webcam frame → encode face → SVM predicts → confidence check → result

The system also handles failure gracefully. If recognition fails, it shows how many attempts remain and gives a clear message rather than just an error.

Architecture

Browser (webcam capture)
    → POST /recognize (base64 image)
    → Flask decodes → face_recognition encodes → SVM predicts
    → Lookup student in CSV
    → Return details + mark attendance

The admin panel sits alongside this. It's session-authenticated and lets coordinators add students, view the real-time attendance log, and upload updated models.

Data storage

We used CSV flat files rather than a database. For a fixed set of registered students in an exam hall context, it was the right call. CSV files are easy to inspect, easy to hand over to a coordinator, and require no database setup on the institution's end. The attendance log is a simple append-only CSV with name, timestamp, and status.

My contribution

I worked on the overall system architecture, the Flask backend and recognition API, the admin dashboard, and the rate limiting logic. The four of us divided the remaining pieces -- dataset collection, training pipeline, and the frontend pages.

API response

{
  "name": "anson",
  "exam": "History",
  "classroom": "G707",
  "seat_no": "7",
  "attendance": "Marked"
}

What it doesn't do (and why)

Lighting conditions significantly affect recognition accuracy -- this was a known constraint. The admin credentials are hardcoded, which is fine for a demo environment. CSV doesn't scale to thousands of students. We knew all of this going in; the scope was an exam-hall pilot, not a production system.

Despite those limits, in testing it correctly identified all registered students under normal lighting conditions, which was what we set out to demonstrate.

Tech stack