AuraHire

Most AI recruitment tools score candidates inside a black box: a number appears, a candidate is ranked, and no one can say why. That opacity is also where bias hides — if you can't inspect how a score was produced, you can't tell whether it leaned on a name, an address, a gendered phrase, or genuine skill.

AuraHire is my own thesis build, framed around a single defensible claim: explainable and fair AI-powered recruitment. The constraint I set was that the system is the artifact — no faked AI, no opaque scoring, no demo theatre. If a feature couldn't be defended in front of an examiner, it didn't ship.

A production-grade platform with three roles — candidate, recruiter, and admin — plus multi-tenant company membership, where one recruiter can belong to several companies and an active-company context governs every recruiter view.

Candidates get a resume-first onboarding wizard (upload, AI parse, review prefilled fields, set preferences, see a Profile Score), a job feed with per-job match chips, and one-tap apply. Recruiters get a rich-text job editor with inline bias flags, an application pipeline sortable by best match, interview scheduling, and offer generation. Admins get a command center, audit log, AI scoring configuration, and a bias and fairness monitor.

Two scoring engines run server-side on OpenAI with structured outputs — free-text parsing is forbidden, so every call returns a Zod-validated JSON document. The Profile Score weighs four components (Completeness 25, Skill Depth 30, Experience Clarity 30, Education Quality 15). The Match Score weighs four more against a specific job (Skills 40, Experience 35, Education 15, Cultural / Language Fit 10). That is eight transparent dimensions in total, each capped by its configured weight.

No score renders as a naked number. Every component carries its score, its max, its weight, a plain-language explanation, and one to three verbatim evidence excerpts pulled from the resume — each tagged positive, negative, or neutral with an estimated point contribution. Scores fall into plain-language bands (Strong at 70+, Partial at 40–69, Limited below 40) so a number is always paired with a human-readable label.

Reproducibility is baked into the data model: every score row stores the prompt version, the model used, latency, the redacted fields, the exact weights used, and the full raw model output. A historical score stays interpretable even after an admin re-tunes the algorithm, because the weights that produced it travel with it.

Fairness is enforced upstream rather than measured after the fact. Before any scoring model sees a resume, a hybrid PII redaction pass runs: a rule-based stage nulls name, email, phone, and social links, and an LLM-assisted stage scrubs residual identifiers from free-text fields. A redacted-fields list is persisted on every score row so the redaction can be audited. The scoring prompts are written to treat a redacted token as a present-but-withheld field, so candidates are never penalized for redaction.

Job descriptions are scanned for biased language across four categories — gendered, age-coded, ableist, and exclusionary — plus admin-defined custom terms. Flags surface inline in the editor as the recruiter types, and publishing a job with unresolved flags requires an explicit written override reason that lands in both the bias-flag record and the append-only audit log.

A Turborepo monorepo with a deliberately split frontend and backend: a Next.js 16 App Router frontend (Vercel) that is a pure UI layer with no database access and no AI keys, and a NestJS backend (Fastify adapter) that owns all business logic, data, AI, queues, cron, secrets, and email. Shared Zod schemas in a common package validate both the React forms and the backend DTOs, and an OpenAPI spec generates the typed TanStack Query client the frontend consumes.

Data lives in Supabase Postgres across 22 tables — modeled with Drizzle ORM — with Row-Level Security on every user-data table as the last line of defense behind frontend middleware, CORS, a Supabase JWT guard, and role plus active-company guards. Background work runs on four BullMQ queues over Redis (match scoring, match-preview precompute, profile-score recompute, and a re-score batch), with ten scheduled cron jobs for lifecycle tasks like archiving expired jobs, expiring offers, and interview reminders.

A Socket.io gateway backed by a Redis adapter pushes real-time events — new notifications, application status changes, interviews, offers, and completed score recomputations — to authenticated user and company rooms. Sixteen React Email templates cover the transactional lifecycle, switching transport from Mailpit in development to Resend in production.

A handful of constraints shaped the whole system and kept it academically defensible.