About

The technology behind Neo Innovations

A quick tour of what's actually running under the hood — from detection and matching to how the live dashboard stays fast.

See it in action Ask a question
Why Neo Innovations exists

Neo Innovations started as a technical project built for a college application — an attempt to go beyond a simple face-detection demo and build something that actually grappled with the hard problems of a real access-monitoring system: not just “can it recognize a face,” but “how does it handle a spoofed photo,” “what happens when the data leaks,” “who gets to see what,” and “what does honest security engineering actually look like when you're building it yourself, end to end.”

What began as a single-camera detection script grew, piece by piece, into a full system: GPU-accelerated recognition, liveness verification to catch spoofing attempts, encrypted storage, role-based access control, and a real deployed application — each addition driven by a genuine question about what a production-grade security system needs, not a checklist.

The name reflects that starting point: a first real attempt at building something new, grounded in the belief that understanding a system's weaknesses is just as important as building its strengths.

What this is built on

The principles behind how this project is built and documented.

  1. Honesty over polish.

    I'd rather document a real limitation than hide it behind confident marketing language. If something doesn't work yet, this site says so.

  2. Security is a practice, not a checkbox.

    I test my own claims — adversarially, against my own system — before I make them. If I can't verify something is true, I don't publish it.

  3. Understand the failure modes, not just the successes.

    A system's real strength is measured by how honestly it accounts for what it can't yet do, not by how impressive its feature list looks.

  4. Build the real thing before claiming the big thing.

    I'd rather build a small, honestly-documented system than an overstated one.

Founder

Kabir Singh Founder & Developer

A student building toward a career in cybersecurity. Neo Innovations started as a way to go beyond coursework and actually build, break, and defend a real system — end to end, alone, with no shortcuts on the parts that are hard to get right.

Supported by

Milestones

Real technical progress, not business traction — this is a solo portfolio project.

  1. 2026 Project founded, as a college application project.
  2. Milestone Core face detection + matching pipeline built and verified.
  3. Milestone GPU acceleration achieved — ~340x speedup over CPU-only processing (measured, RTX 4060).
  4. Milestone Liveness/anti-spoofing detection implemented and adversarially tested against photo-spoofing.
  5. Milestone Biometric data encryption at rest implemented.
  6. Milestone Full role-based access control system built and adversarially tested.
  7. Milestone Public deployment launched at neo-innovations.com.
  8. Milestone robots.txt and sitemap.xml published to support public search-engine indexing.

The evidence

One pipeline, six real stages.

Not a simplified diagram for marketing — this is the actual sequence detection.py runs on every frame, end to end.

  1. 01 Camera frame CAM-01 / CAM-02 — each its own capture thread The two CP Plus cameras (CAM-01 and CAM-02) mounted at a building corner
  2. 02 Lighting correction CLAHE on the LAB L-channel
  3. 03 Face detection CNN detector (dlib), GPU-accelerated
  4. 04 Matching ≥2 enrolled embeddings agree, tolerance 0.5
  5. 05 Liveness gate real blink required — EAR < 0.21, within 6s
  6. 06 Confidence tier authorized borderline unknown

A match requires at least 2 of a person's enrolled photos to independently agree, within a 0.5 distance tolerance — a single unusually close (or unlucky) enrollment photo can't decide a match alone. Liveness requires a real blink (eye aspect ratio under 0.21) within the last 6 seconds — it does not defend against a video replay of a blink, or a 3D mask; see the FAQ.

Read from the running process, not written by hand.

detection_modelCNN
accelerationCUDA (GPU)
match_tolerance0.50
alert_cooldown30s

Read directly from this server's config and GPU driver at the moment this page was requested — not a hand-maintained status page, and not continuously polled after load.

Verified evidence

Complete-miss rate cut from 20% to 12%.

Measured in a real before/after test on the same running process, comparing single-frame tier decisions against 3-frame temporal smoothing (a name must clear the match threshold in 2 of the last 3 detection cycles before it's trusted).

VerificationBefore/after comparison, same process, same test faces — see README.

0 false verifications under repeated spoofing attempts.

Tested against a printed photo and a paused video held up to the camera. Liveness requires a real blink (EAR under 0.21) within the last 6 seconds to pass.

VerificationDoes not defend against a video replay of an actual blink, or a 3D mask — this is a known, disclosed gap, not a claim of complete anti-spoofing coverage. See the FAQ.

The embeddings file fails to open as plain data without its separate key.

Enrolled face embeddings, raw enrollment photos, and contact-form submissions are each encrypted at rest with their own independent key — a leak of one data file alone doesn't expose the others.

VerificationVerified directly against the running encrypted files, not asserted.

Non-admin actions return 403; path traversal on feed IDs returns 404.

Every privileged dashboard action and every feed-scoped route is checked server-side against the requesting account's role and allocated feeds — not just hidden in the UI.

VerificationAdversarially tested directly against the running routes.

~340x faster with GPU acceleration.

~0.12s per frame with CUDA/cuDNN versus ~40.6s per frame CPU-only, measured on an RTX 4060 — the difference between usable live video and not.

VerificationMeasured, not estimated.

What's actually running right now.

Two cameras. One machine. No cloud infrastructure. Everything on this page is running on hardware in one room, right now.

  • Two cameras (CAM-01, CAM-02), each with its own capture thread, detector, and liveness state.
  • One machine, one process — FastAPI and Uvicorn, no cloud infrastructure, no managed database.
  • Flat-file storage: enrolled embeddings, raw enrollment photos, camera recordings, and contact submissions, each encrypted at rest with its own key.
  • The camera capture loop has its own automatic reconnect-with-backoff; there's no additional redundancy layer beyond that yet.
  • Cameras (including RTSP/ONVIF) can be added, edited, and removed from the admin panel, and the capture fleet reconciles to match — no process restart required.

What's real, split honestly by status.

Deployed

  • Session-based authentication; passwords bcrypt-hashed, never stored in plaintext. Unbounded-length passwords are handled safely — an oversized or multi-byte password fails closed as a normal rejection, not a server error.
  • Role-based access control on every feed-attributable dashboard route, enforced server-side.
  • Three independently-keyed encryption stores at rest: face embeddings, raw enrollment photos, contact submissions.
  • HTTPS (TLS) in transit on every connection to the site.
  • Camera reconnect with backoff and live health detection (live / reconnecting / offline / stale) — confirmed running continuously in production.
  • Roster Integrity + Authorized People access model — deployed, following three rounds of independent security review (CTO + Red Team).
  • TOTP two-factor authentication (with recovery codes) is implemented for every customer, operator, and admin account, plus server-side session/device management. Production enforcement is currently controlled by a runtime flag and is off by default in this deployment.

Not yet implemented

  • No third-party penetration test has been conducted.
  • No compliance certification of any kind — ISO 27001, SOC 2, GDPR, or India's DPDP — has been pursued or claimed.

Roster Integrity, the Authorized People access model, and two-factor authentication (TOTP + recovery codes) for every account type have shipped, each after independent security review — production enforcement of MFA is currently controlled by a runtime flag. An independent third-party penetration test, and re-enabling that enforcement, are next.

face_recognition / dlib CNN-based detection CUDA / cuDNN GPU acceleration OpenCV (CLAHE preprocessing) EXIF-aware image loading FastAPI + Uvicorn Jinja2 Session-based auth + bcrypt MJPEG streaming

Tech stack

9 components

Detection & Recognition

face_recognition / dlib Face detection and 128-d embedding generation via dlib's ResNet model, wrapped by the face_recognition library.
CNN-based detection dlib's CNN face detector (vs. the faster but less accurate HOG detector) for substantially better accuracy on angled faces and poor lighting.

Performance

CUDA / cuDNN GPU acceleration CNN detection runs on GPU when available — measured ~340x faster than CPU-only (~0.12s vs ~40.6s per frame on an RTX 4060) — the difference between usable live video and not.

Image Processing

OpenCV (CLAHE preprocessing) Contrast-Limited Adaptive Histogram Equalization on the L channel of LAB color space before detection, to even out poor/uneven lighting without blowing out bright regions.
EXIF-aware image loading Photos are loaded with EXIF orientation correction applied (Pillow) — without it, a portrait phone photo can load sideways and silently fail detection.

Backend

FastAPI + Uvicorn Async Python web framework serving the public site, auth, and dashboard.
Jinja2 Server-rendered templating for the public marketing pages.
MJPEG streaming Live annotated camera feed served as a multipart MJPEG stream — works in a plain <img> tag, no extra client-side library needed.

Security

Session-based auth + bcrypt Signed session cookies gate the dashboard; passwords are bcrypt-hashed, never stored in plaintext.

Want to see it in action, or talk about the project?

See the Demo Get in Touch
See Demo Get in Touch