A Unified Multi-Tenant Campus Placement and Proctored Assessment Platform with AI-Assisted Resume Generation
A production-deployed SaaS platform serving multiple engineering institutions from a single codebase — placement automation, attendance, secure online examinations and on-premise AI résumé generation under one role-based access model.
Introduction
Every engineering college runs the same four workflows every semester — enrolling students, tracking attendance, conducting internal assessments and running placement drives — and almost every college runs them on a disconnected mix of spreadsheets, WhatsApp groups, Google Forms and a partially-adopted ERP.
The consequence is not merely inconvenience. The same student record is re-keyed into four systems, eligibility for a drive is decided manually against a PDF of criteria, résumés arrive in a dozen formats, and accreditation reporting becomes an annual archaeology exercise.
This project delivers a single multi-tenant platform where one deployment serves many institutions, each isolated at the database level, each with its own roles, subscription plan and feature set — and adding a new college is data entry, not a code change.
This is not a prototype built for evaluation. It is a commercially deployed product, presented here as our major project.
Four integrated domains
- Identity & access — tenants, dynamic roles, per-page permissions, MFA
- Academics — students, classes, departments, barcode attendance
- Placement — companies, drives, eligibility, applications, offers, analytics
- Assessment — proctored online exams at the network edge
Why it matters academically
The project spans distributed system design, applied cryptography, database isolation models, information retrieval and on-device language-model inference — implemented and operated, not simulated.
Problem Statement
Institutions lack a single, access-controlled system of record for the student lifecycle. Placement, attendance and assessment data live in mutually inconsistent silos, eligibility and integrity decisions are made manually, and no existing product offers all three to multiple institutions from one isolated, subscription-governed deployment at a price Indian colleges can absorb.
Fragmentation & re-keying
- One student exists as four unlinked records
- Attendance in Excel, drives in Forms, marks in an ERP
- NBA / NAAC reports rebuilt by hand each cycle
Manual, error-prone gatekeeping
- Eligibility (CGPA, backlogs, branch, skills, offer policy) checked by eye
- Ineligible applications reach recruiters, costing credibility
- No auditable trail of who changed what
Unusable student artefacts
- Résumés in inconsistent formats, frequently ATS-hostile
- Batch-generated résumés read identically — a screening red flag
- Online tests either unproctored or priced per-candidate
Security & isolation
Shared-database SaaS risks one college reading another's data. Most low-cost ERPs enforce tenancy only in application code, with no database-level backstop.
Cost structure
Assessment vendors charge per candidate. A 4,000-student college running four internals per year cannot sustain per-test pricing.
Operational fragility
Monolithic ERPs fail as a unit — an identity outage takes down attendance, placement and reporting simultaneously.
Objectives
- Design a multi-tenant architecture in which a single deployment serves many institutions with per-tenant data isolation enforced both in application code and by the database engine.
- Implement dynamic role-based access control where an administrator can create arbitrary roles and grant page-level actions (view / create / edit / delete / export) without a code deployment.
- Automate placement drive eligibility — evaluate every published drive against every student's live academic profile and surface only the drives they qualify for, with explicit reasons for near-misses.
- Generate ATS-compatible résumés automatically from structured profile data, curated to the most role-relevant projects.
- Eliminate résumé homogeneity using a self-hosted small language model that rewrites only student-authored prose, never fabricating facts and never receiving personally identifiable information.
- Deliver browser-based proctored assessment at the network edge with focus-loss detection, navigation lockdown and answer-similarity analysis, at zero marginal cost per candidate.
- Unify identity across sub-systems so a single login federates into the assessment platform through a one-time-code SSO exchange.
- Meet production security expectations — Argon2id hashing, RS256 asymmetric tokens, rotating refresh tokens with theft detection, append-only audit logging and encrypted government identifiers.
- Validate in the field by deploying to real institutions and measuring correctness, latency and administrative effort saved.
Mapping to Sustainable Development Goals
The platform contributes directly to four of the United Nations 2030 Agenda goals [13].
Digital attendance and proctored internal assessment raise the integrity and traceability of academic evaluation. Institutions with limited IT budgets gain assessment infrastructure that previously required per-candidate licensing.
Automated eligibility matching, a shared off-campus opportunity feed and ATS-ready résumés measurably improve the rate at which graduates convert applications into employment, particularly for students without placement-cell access.
Resilient digital infrastructure for education: independently deployable services, local token verification so identity outages do not cascade, and edge-hosted assessment resilient to campus network conditions.
The off-campus feed is shared across every tenant, so students at smaller institutions see the same opportunities as those at well-connected ones. Self-hosted AI keeps résumé assistance free rather than paywalled.
Sustainability of the technical choices: language-model inference runs on a single self-hosted node rather than a metered cloud API, and the assessment tier runs on shared edge compute — both reducing recurring cost and per-request energy footprint relative to hosted-inference alternatives.
Literature Survey: Existing Systems
| System / Category | What it does well | Limitations observed | Placement + Exam? | Cost model |
|---|---|---|---|---|
| Campus ERP suites (Fedena, Camu, Academia) |
Broad academic modules; admissions, fees, timetable | Placement module is a thin CRUD list; no eligibility engine, no assessment, roles are fixed presets rather than composable permissions | Partial / No | Per-student annual |
| Placement portals (Superset, NAPS-type) |
Recruiter-facing drive workflow, applicant tracking | Single-institution tenancy; no attendance or internal assessment; résumé handling is upload-only, no generation; opportunity feed limited to on-campus drives | No exam | Per-institution licence |
| Assessment platforms (Mettl, Talview, HackerRank for Work) |
Mature proctoring, item banks, analytics | Priced per candidate per test — prohibitive for recurring internals; no academic record integration; identity is a separate silo requiring duplicate provisioning | Exam only | Per candidate |
| LMS + lockdown browser (Moodle + Safe Exam Browser) [15] |
Open-source, self-hostable, quiz engine is capable | Lockdown requires a client install on every machine; no placement domain at all; self-hosting burden falls on the institution's IT staff | Exam only | Free + ops cost |
| Spreadsheets + Forms (the de-facto baseline) |
Zero cost, zero training, universally available | No access control, no audit trail, no referential integrity, no proctoring; eligibility filtering is manual; data loss and version conflict are routine | No | Free |
| Résumé builders (generic online tools) |
Attractive templates, quick to use | Template-driven output is visually uniform; no institutional data source, so students re-enter everything; cloud LLM variants transmit personal data to third parties | N/A | Freemium |
Identified gap — no surveyed system provides multi-tenant isolation, composable permissions, automated eligibility, résumé generation and proctored assessment in one subscription-governed deployment. Institutions are forced to integrate three vendors or accept spreadsheets.
Literature Survey: Techniques Adopted
| Source | Contribution | How it is applied in this project |
|---|---|---|
| Sandhu et al., Role-Based Access Control Models, IEEE Computer, 1996 [2] | Formalises RBAC0–RBAC3: users → roles → permissions, with sessions and constraints | Adopted as the RBAC1 core. Extended with a page catalogue so permissions are data rows, letting a tenant admin define new roles at runtime |
| Guo et al., Native Multi-Tenancy Application Development, IEEE CEC/EEE, 2007 [6] | Isolation patterns for shared-schema SaaS and the security risk of application-only tenant filtering | Shared schema with a mandatory tenant_id predicate, backed by PostgreSQL Row-Level Security as an engine-level backstop |
| Jones et al., JSON Web Token, RFC 7519, 2015 [3] | Compact, signed, self-contained claim transport | RS256 access tokens verified locally by every service using the public key — removing the identity service from the request path |
| Biryukov et al., Argon2, IEEE EuroS&P, 2016 [4] | Memory-hard password hashing resistant to GPU and ASIC attack | Argon2id at 64 MiB / 3 iterations for every credential, replacing bcrypt-class defaults |
| Broder et al., Syntactic Clustering of the Web, 1997 [7] | k-shingling and resemblance for near-duplicate detection | Basis of the answer-similarity detector: 3-gram shingle sets compared by Jaccard resemblance across a cohort's descriptive answers |
| Schleimer et al., Winnowing, ACM SIGMOD, 2003 [8] | Local fingerprint selection giving bounded-guarantee document matching | Informs normalisation and windowing before comparison, so trivial whitespace or case edits do not defeat detection |
| Vaswani et al., Attention Is All You Need, 2017 [11] · Qwen3 Technical Report, 2025 [12] | Transformer architecture; small instruction-tuned models viable on commodity hardware | A 1.7 B-parameter model runs on the institution's own node, constrained to copy-editing student prose — no PII leaves the boundary |
| Shahrad et al., Serverless in the Wild, USENIX ATC, 2020 [17] | Characterises serverless workloads: bursty, short-lived, cold-start sensitive | Justifies placing the exam tier on edge workers — examination load is extremely bursty (one hour per semester) and would otherwise require idle provisioned capacity |
Proposed System
A modular multi-tenant platform composed of an identity service, a modular-monolith core service, an asynchronous worker, a self-hosted inference service and an edge-deployed assessment tier — federated by a single sign-on exchange and governed by one subscription model.
Tenancy that is data, not code
- Adding a college creates the tenant, its first administrator, default roles and a permission matrix in one transaction
- Subscription tier gates which pages exist and student capacity — not per-student billing
- Every core query carries
tenant_id; PostgreSQL RLS rejects any query that does not
Permissions as first-class records
- A page catalogue registers every feature with a code such as
placement.jobs - Roles map pages to action sets; new roles need no deployment
- Every route is guarded server-side — the UI merely reflects what the backend already enforces
Placement as a decision engine
- Drives carry structured eligibility: CGPA, backlogs, branch, semester, 10th/12th %, required skills
- Students see only qualifying drives; near-misses show the exact failing predicate
- Institutional offer policy (single/multiple offer, category ceilings) enforced at application time
Résumés generated, then differentiated
- Structured profile → deterministic ATS-safe layout (PDF, DOCX, LaTeX)
- Projects ranked by role relevance and substance; top-N retained
- A local model rewrites only student-written descriptions, seeded per student so no two read alike
Assessment at the edge
- Exams served from edge workers with a distributed database and object storage
- Focus-loss, tab-switch, copy/paste and developer-tool detection recorded per attempt
- Cohort answer-similarity analysis flags collusion after submission
One identity, two platforms
- The placement platform is the identity master; exam accounts are provisioned eagerly on student creation
- Login federates via a short-lived one-time code, never a shared password — an authorization-code exchange in the spirit of OAuth 2.0 / OIDC [9], [10]
- Deletion propagates — removing a student purges the assessment account
Proposed Methodology
An incremental, local-first delivery model. Each phase is fully working on a developer machine before any infrastructure is provisioned, and each phase produces a demonstrable capability rather than a layer.
- Requirement elicitation & specification. Workflows captured directly from placement officers and HoDs; formalised as an SRS following IEEE Std 830 [1]. Data model and security model fixed in an authoritative architecture document before any code.
- Phase 1 — Identity foundation. Containerised PostgreSQL and Redis, schema migrations, idempotent seeds, first authenticated token issued locally.
- Phase 2 — Full identity service. Rotation, MFA, RBAC, tenant provisioning, audit logging, rate limiting, lockout.
- Phase 3 — Core service. Modular monolith with self-contained modules for students, classes, attendance, placement, reports and notifications; local token verification and permission guards.
- Phase 4 — Web client. React SPA with permission-gated navigation derived from the same catalogue the backend enforces.
- Phase 5 — Integrations. Transactional email, object storage, SSO federation with the assessment tier, self-hosted inference service.
- Phase 6 — Deployment & hardening. Container orchestration, edge WAF/TLS, automated backups, CI/CD, penetration-style security review.
Governing design principles
- Modular monolith, not micro-services. Clean module boundaries now; extraction later is a refactor, not a rewrite.
- Identity is the security boundary and is the only separately deployed service.
- No network call on the hot path. Tokens verified locally, so identity downtime never cascades.
- Configuration, never constants. No URL, secret or credential is compiled in.
- Enforce on the server. Any restriction visible in the UI is independently enforced by the API.
Verification at each phase
Every phase closes with a documented smoke-test script, a deployment pre-flight checklist and a written security review — all three are maintained artefacts in the repository, not one-off exercises.
System Architecture
MFA · Tokens · Audit
RS256 private key
students · classes · attendance
placement · reports · notifications
verifies JWT locally
CSV import · exports
e-mail · push · cron
Qwen3 1.7 B via Ollama
no PII crosses in
exam runtime · grading queue
proctor event ingest
auth_appaudit_logs partitioned monthly
core_appRLS on
tenant_idrevocation · queues
R2 object storage · KV · Queues
Database separation. Neither service can read the other's database — separate PostgreSQL roles, no cross-database joins. Cross-service data moves over authenticated internal HTTP only.
Failure isolation. core-service verifies tokens with a cached public key. If auth-service is down, existing sessions continue working; only new logins fail.
Internal surface. /internal/* endpoints are reachable only on the private overlay network and additionally require a shared internal secret header.
Architecture: Security & Tenant Isolation
How a single API call is authorised
Client ──Bearer JWT──▶ core-service 1 verify RS256 signature with cached PUBLIC key (no network) 2 reject if redis:auth:revoked:{jti} exists 3 perms ← redis:auth:perms:{userId} (5-min TTL) 4 if miss or token.permission_hash ≠ perms.hash perms ← auth-service /internal/perms (rare) 5 require perms[pageCode] ∋ action 6 set tx-local app.org_id = token.tenant_id 7 execute query — RLS filters rows by tenant
Defence in depth against cross-tenant reads
- Layer 1 — every ORM query scoped by
tenant_idin application code - Layer 2 — PostgreSQL Row-Level Security policies on the tenant column [18]
- Layer 3 — the application connects as a non-superuser role, so RLS cannot be bypassed even by a query-injection defect
| Control | Implementation |
|---|---|
| Password storage | Argon2id — 64 MiB memory, 3 iterations, parallelism 1 |
| Access token | JWT RS256, 15-minute lifetime, asymmetric keys; private key held only by auth-service |
| Refresh token | Opaque, hashed at rest, 7-day, rotating; grouped by family_id |
| Theft detection | Reuse of a revoked refresh token revokes the entire family and forces re-authentication |
| Second factor | TOTP (RFC 6238 [5]) with QR enrolment; mandatory for platform administrators |
| Brute force | Per-route rate limiting plus account lockout after 5 consecutive failures |
| Sensitive identifiers | Aadhaar / PAN stored encrypted, decrypted only on an explicitly permissioned reveal action, which is audited |
| Auditability | Append-only audit_logs capturing actor, action, before/after state and source IP; partitioned monthly |
| Transport & headers | TLS at the edge; HSTS, CSP, X-Frame-Options and related headers applied per response |
| Input handling | Schema validation on every request body; parameterised queries throughout |
| Outbound fetches | SSRF guard on all server-side external fetches — scheme, host and private-range checks before connect |
Threat model reference: controls were selected and reviewed against the OWASP Top 10 (2021) categories [16], with a written security audit retained in the repository.
Algorithm 1 — Drive Eligibility Resolution
// Input : student S, published drives D, tenant policy P // Output: ELIGIBLE[], NEAR_MISS[(job, reasons)] function resolveOpportunities(S, D, P): cls, dept ← lookupClassAndDepartment(S) H ← lowercase(S.skills ∪ S.projectTools ∪ S.internTools) ELIGIBLE ← [] ; NEAR ← [] for each job j in D where j.tenant = S.tenant: R ← [] // failed predicates e ← j.eligibility if e.min_cgpa and S.cgpa < e.min_cgpa : R ← R + "CGPA" if e.min_tenth and S.tenth < e.min_tenth : R ← R + "10th %" if e.min_twelfth and S.twelfth < e.min_twelfth: R ← R + "12th %" if e.max_backlogs ≠ ∅ and S.backlogs > e.max_backlogs : R ← R + "Active backlogs" if e.max_history_backlogs ≠ ∅ and S.histBacklogs > … : R ← R + "History of backlogs" if e.departments ≠ ∅ and dept ∉ e.departments : R ← R + "Branch" if e.semesters ≠ ∅ and cls.year ∉ e.semesters : R ← R + "Semester" if e.batches ≠ ∅ and S.batch ∉ e.batches : R ← R + "Batch" if e.gender ≠ ∅ and S.gender ∉ e.gender : R ← R + "Eligibility criteria" // required-skill predicate — set containment over the haystack M ← { s ∈ e.required_skills : s ∉ H } if M ≠ ∅ : R ← R + ("Missing skills: " + M) // institutional offer policy, evaluated after criteria if not offerPolicyAllows(S, j, P) : R ← R + "Placement policy" if R = ∅ : ELIGIBLE ← ELIGIBLE + j else : NEAR ← NEAR + (j, R) return sortByDeadline(ELIGIBLE), NEAR
Design decisions
- Evaluated in the service layer, not SQL. Criteria are a JSONB document with an open key set; expressing them as SQL predicates would require schema change per new criterion.
- Failure reasons are collected, not short-circuited. A student sees every unmet condition at once, which is what makes the near-miss view actionable.
- Skills matched over a union haystack — declared skills plus tools used in projects and internships — so practical experience counts.
- Policy is applied last so a student who is academically eligible but blocked by an offer ceiling is told precisely that.
Complexity
Linear in the number of published drives; k is the constant number of scalar predicates and the skill test is O(1) amortised per skill using a hash set. The student profile and class/department lookup are fetched once, outside the loop.
Server-side enforcement: the identical predicate set re-runs inside the apply endpoint. Hiding a drive in the UI is a convenience; the API independently refuses an ineligible application.
Algorithm 2 — Résumé Curation & AI Differentiation
Role-relevance ranking
Each target role (SDE, Data, Embedded, …) carries a keyword vector. Every project is scored against the selected role and only the top-N survive onto a one-page résumé; the rest remain in the profile.
rel(p, r) = |keywords(r) ∩ tokens(p.title ‖ p.desc ‖ p.tools)| scope(p) = bonus if p has a live link / repository projects ← sort(P, key = score, desc)[0 : N] N = 4 skills ← group(S, by = category) ATS keyword block summary ← template(branch, role, topSkills, |projects|, seed = hash(studentId)) structure rotates
Why relevance dominates substance: the 100× weight makes role fit lexicographically primary — a marginally richer but irrelevant project can never displace a relevant one. Substance only breaks ties within the same relevance band.
Constrained rewriting on a self-hosted model
for each description d in projects ∪ internships: if words(d) > MAX_WORDS : continue // gate key ← sha256(studentId ‖ d) if cache[key] : bullets ← cache[key] ; continue bullets ← llm(prompt = COPY_EDITOR, context = {title, tools}, // never PII seed = studentId, // divergence n_predict = 80, think = false) if error or timeout or inventedFacts(bullets, d): bullets ← original(d) // graceful cache[key] ← bullets workers ← adapt(freeRAM, loadAvg) // 1 … 4
Never sent
Name, e-mail, phone, USN, CGPA, dates, education
Kept verbatim
Skills and tool names — they are the ATS keywords
Always succeeds
Any failure falls back to the original text, per item
The homogeneity result. Caching is keyed on hash(studentId ‖ text), so regenerating a résumé is instant, yet two students whose raw text is identical still receive different phrasing — the student identifier seeds the sampler. Bullet count scales to input length, which prevents the model padding a thin project into fabricated achievement.
Algorithm 3 — Proctoring & Answer Similarity
Client-side integrity signals
- Focus loss / tab switch — visibility and blur events, counted and time-stamped per attempt
- Navigation lockdown — back/forward interception, context menu, selection and drag suppression while in exam context
- Copy / paste / print — clipboard and print events blocked and recorded
- Developer-tool heuristic — outer/inner viewport delta sampled on an interval against a 160 px threshold
- Full-screen exit and window-resize transitions logged
Every event is posted to the attempt record on the edge worker. Signals are evidence for a human invigilator, never an automatic invalidation — the platform surfaces a ranked flag list, the institution decides.
Cohort answer-similarity detection
// normalise away trivial evasion norm(s) = trim(collapseWhitespace(lowercase(s))) tokens(s) = { t ∈ split(norm(s), \W+) : |t| > 1 } shingles(t, k) = { t[i…i+k-1] : 0 ≤ i ≤ |t| − k } k = 3 // Jaccard resemblance (Broder et al., 1997) J(A, B) = |A ∩ B| / |A ∪ B| similarity(a, b): ta, tb ← tokens(a), tokens(b) if |ta| < k or |tb| < k : return J(ta, tb) // short answers return J(shingles(ta,k), shingles(tb,k)) // pairwise over the cohort, per descriptive question for each question q, for each pair (u, v) ∈ attempts(q): σ ← similarity(answer[u][q], answer[v][q]) if σ ≥ τ : flag(u, v, q, σ) τ ≈ 0.80
Why shingles
Bag-of-words alone scores two answers using the same vocabulary as identical. 3-grams require shared word order.
Short-answer fallback
Below k tokens shingling is undefined, so the comparison degrades to token-set Jaccard.
Complexity
O(m²·L) per question for m attempts; run asynchronously in the grading queue, never in the request path.
Implementation: Delivered Modules
| Module | Capabilities implemented | Key engineering detail | Status |
|---|---|---|---|
| Identity & RBAC | Login, MFA enrol/verify, refresh rotation, password reset, e-mail verification, dynamic roles, page catalogue, permission matrix, tenant provisioning, super-admin console | Argon2id; RS256 key pair; family-based refresh revocation; Redis permission cache keyed by permission hash | Complete |
| Students | CRUD, CSV bulk import with account provisioning, projects / internships / achievements / certifications / languages, semester-wise SGPA, document vault, self-registration by college join code, record claim | Aadhaar & PAN encrypted at rest with an audited reveal action; import runs as a background job | Complete |
| Classes & Attendance | Departments, classes, enrolments, advisors; sessions; barcode scan via camera and USB serial scanner; manual marking; per-student history; class summaries | Unique constraint on (session, student) makes re-scan idempotent; attendance table partitioned monthly | Complete |
| Placement | Companies, drives, structured eligibility, rounds, applications, offers, offer policy, drive categories, visits, selections, student journey, prep resources, analytics | Eligibility engine with near-miss reasoning; policy enforced server-side at apply time | Complete |
| Off-campus feed | Cross-institution shared opportunity feed, per-college filters, relevance-ranked recommendations, scheduled auto-refresh, super-admin provider registry | Provider credentials encrypted; every outbound fetch passes an SSRF guard; provider identity hidden from end users | Complete |
| Résumé | Role-targeted generation, project curation, grouped skill blocks, ATS guidance, A4 preview, export to PDF / DOCX / LaTeX | Deterministic layout; header carries GitHub and LinkedIn links | Complete |
| resume-ai | Description and summary rewriting, per-student divergence, hash-keyed cache, load-adaptive worker pool, health build marker | Qwen3 1.7 B in non-thinking mode behind a bearer token; per-item graceful degradation | Complete |
| Assessment | Exam authoring, scheduling, runner, auto-grading queue, proctor event capture, similarity analysis, faculty and super-admin consoles, subscription gating | Edge workers; database reached over a private tunnel with connection pooling; per-college RLS with a tenant set per transaction | Complete |
| SSO federation | Eager provisioning of exam accounts, one-time-code login exchange, profile field sync, delete propagation, ghost-row relinking | Internal endpoints authenticated by shared secret over the private network | Complete |
| Reports & Notifications | Scheduled and on-demand exports, accreditation report, announcements, e-mail, web push, engagement tracking, audit and password-reset reports | BullMQ workers, queue-scoped instances, cron-driven trial lifecycle transitions | Complete |
Implementation: Deployment & Operations
Origin cluster
- Ubuntu 24.04 host running Docker Swarm, orchestrated through Dokploy
- Seven services: web, auth, core, worker, PostgreSQL 16, PgBouncer, Redis 7
- Services communicate over a private overlay network; only web, auth and core are published
- Images built from the monorepo and rolled forward per service
Edge tier
- Assessment platform on Cloudflare Workers with Pages-hosted front end
- Object storage for attachments; key-value for session state; queues for grading
- Origin database reached over an authenticated tunnel into a pooled connection layer
- Deployment uses versioned uploads promoted only after preview smoke-testing, so live bindings are never clobbered
Continuity
- Hourly database dumps shipped to object storage with retention
- Health endpoints carry a build marker, so a redeploy can be proven to have landed
- CI pipeline on GitHub Actions; migrations and seeds are idempotent and re-runnable
Repository structure
/platform ├─ ARCHITECTURE.md authoritative spec ├─ services/ │ ├─ auth/ identity · RBAC · tenants │ │ ├─ src/{config,models,controllers, │ │ │ middleware,routes,services,utils} │ │ ├─ migrations/ seeders/ │ ├─ core/ modular monolith │ │ └─ src/modules/{students,classes,attendance, │ │ placement,reports,notifications,account,email} │ ├─ worker/ BullMQ consumers │ └─ resume-ai/ inference service ├─ web/ React 18 + Vite SPA ├─ login-portal/ shared SSO entry point ├─ exam portal/ │ ├─ public/ exam runner, proctor, integrity │ └─ workers/{admin,student} ├─ deploy/ infra/ scripts/ tests/ └─ .github/workflows/ CI/CD
Engineering discipline. Every feature ships with three mandatory artefacts — a page-catalogue entry, a default-role mapping and a permission guard on every route. No feature is exempt from access control, which is what keeps a dynamic permission model from developing holes over time.
Test Cases
| ID | Scenario | Input / precondition | Expected result | Type | Status |
|---|---|---|---|---|---|
| T01 | Valid authentication | Registered e-mail + correct password, MFA disabled | HTTP 200; RS256 access token (15 min) and rotating refresh token issued; login recorded | Functional | Pass |
| T02 | Account lockout | 5 consecutive incorrect passwords for one account | Account locked; 6th attempt rejected even with the correct password until lockout expires | Security | Pass |
| T03 | Refresh-token theft | Replay a refresh token that has already been rotated | Entire token family revoked; all sessions for that user invalidated; re-authentication forced | Security | Pass |
| T04 | Cross-tenant read | Valid token for College A; request a student record belonging to College B | HTTP 404 — RLS returns zero rows; no existence disclosure; attempt audited | Security | Pass |
| T05 | Permission revocation | Remove placement.jobs / edit from a role mid-session | Cached permission hash mismatches; permissions refetched; subsequent edit returns HTTP 403 without re-login | Functional | Pass |
| T06 | Eligibility filtering | Student CGPA 6.4; drive requires 7.0 minimum | Drive absent from the eligible list; near-miss view names "CGPA" as the failing predicate | Functional | Pass |
| T07 | Eligibility bypass attempt | POST directly to the apply endpoint for a drive the student fails | HTTP 403 — server re-evaluates all predicates independently of the UI | Security | Pass |
| T08 | Duplicate attendance scan | Scan the same barcode twice within one session | Single attendance record retained; second scan acknowledged as already marked, not duplicated | Functional | Pass |
| T09 | Bulk import | CSV of 500 student rows including 3 malformed and 2 duplicate rows | Valid rows imported with accounts provisioned; malformed rows reported with line numbers; no partial corruption | Functional | Pass |
| T10 | Résumé divergence | Two students submit byte-identical project descriptions | Both résumés generate; bullet phrasing differs — cache key includes the student identifier | Functional | Pass |
| T11 | Inference degradation | Stop the inference service, then generate a résumé | Résumé produced with original descriptions retained per item; no error surfaced to the student | Resilience | Pass |
| T12 | Identity-service outage | Stop auth-service with an unexpired access token in hand | Existing sessions keep working against core-service; only new logins fail | Resilience | Pass |
| T13 | Exam focus loss | Switch browser tabs three times mid-attempt | Three time-stamped focus-loss events recorded and shown in the invigilator's flag list | Functional | Pass |
| T14 | Answer collusion | Two attempts submit near-identical descriptive answers | Shingle Jaccard ≥ τ; pair flagged for review without auto-invalidating either attempt | Functional | Pass |
| T15 | Subscription gating | Free-trial college attempts a 6th examination | HTTP 403 trial_exhausted; existing data remains readable | Functional | Pass |
| T16 | SSRF guard | Configure a job-feed provider pointing at an internal address | Fetch refused before connect; private-range and scheme checks reject the target | Security | Pass |
Use Case Scenarios
Onboarding a new institution
Actor: Platform super administrator
- Submits name, slug, subscription plan and administrator e-mail
- System creates the tenant, first administrator, default roles and permission matrix in a single transaction, and provisions the matching assessment organisation
- Administrator receives a setup link, sets a password and enrols in MFA
- Institution begins creating its own users and roles — no code was written or deployed
Running a placement drive
Actor: Placement officer → Student
- Officer registers the company and publishes a drive with structured eligibility and a deadline
- Engine evaluates the drive against every student profile
- Eligible students see it on their Opportunities page; others see the exact criteria they miss
- Student applies — server re-verifies eligibility, résumé presence and offer policy
- Officer advances applicants through rounds and records offers; analytics update automatically
Preparing for a drive
Actor: Student
- Completes profile — academics, skills, projects, internships, links
- Selects a target role; the system ranks projects by relevance and retains the top four
- Descriptions are rewritten by the on-premise model into distinct ATS bullets
- Downloads as PDF, DOCX or LaTeX and attaches it to the application
Conducting an internal assessment
Actor: Faculty → Student → Invigilator
- Faculty authors the paper and schedules it for a class
- Student signs in on the placement platform and federates into the exam via a one-time code
- Runner locks navigation and records integrity events throughout the attempt
- Objective sections auto-grade; the queue runs cohort similarity analysis
- Invigilator reviews a ranked flag list and decides — the system never auto-invalidates
UC-05 — Attendance. A proctor opens a session and scans identity cards by camera or USB scanner; repeat scans are idempotent, absentees are marked in bulk, and the session summary is available immediately to the class advisor.
Tools and Technologies
| React 18 | Component model, SPA |
| Vite | Build tool, HMR |
| Zustand | Client state |
| Axios | HTTP with token refresh |
| Web APIs | MediaDevices, Web Serial, Push, Fullscreen |
| PostgreSQL 16 | Primary store, RLS, partitioning |
| Sequelize | ORM, migrations, seeders |
| PgBouncer | Connection pooling |
| Redis 7 | Cache, revocation, queue backend |
| BullMQ | Job queues and schedules |
| Node.js 20 LTS | Runtime |
| Express.js | HTTP framework |
| Joi | Request schema validation |
| Winston | Structured JSON logging |
| Helmet | Security response headers |
| express-rate-limit | Abuse throttling |
| argon2 | Argon2id hashing |
| jsonwebtoken | RS256 sign / verify |
| speakeasy + qrcode | TOTP second factor |
| Node crypto | Field-level encryption of identifiers |
| Ollama | Local model server |
| Qwen3 1.7 B | Instruction-tuned SLM, non-thinking mode |
| Custom scheduler | Load-adaptive worker pool, hash-keyed cache |
| Docker + Swarm | Containers and orchestration |
| Dokploy | Deployment control plane |
| Traefik | Ingress routing |
| Cloudflare | WAF, TLS, CDN, Workers, Pages, R2, KV, Queues, Tunnel |
| Resend | Transactional e-mail |
Git & GitHub · GitHub Actions CI/CD · Wrangler CLI · ESLint · Postman / curl smoke suites · pg_dump backup automation
System Requirement Specifications — Hardware & Software
Production origin node
- 4 vCPU, 8 GB RAM, 160 GB NVMe SSD (current deployment)
- Additional node for inference: 8 GB RAM minimum for a 1.7 B model at 4-bit quantisation, 4 GB free at inference time
- Recommended for 10,000+ students: 8 vCPU / 16 GB, with the database on separate storage
- Assessment tier requires no owned hardware — it executes on shared edge compute
End-user devices
- Any device with a modern browser; 4 GB RAM sufficient
- Attendance scanning: integrated camera, or a USB HID / serial barcode scanner
- Examinations: keyboard-equipped device with a stable connection; full-screen capable browser
- Minimum usable viewport 360 px — the interface is responsive down to mobile
Platform prerequisites
- Ubuntu 24.04 LTS, Docker Engine 24+, Docker Compose v2
- Node.js 20 LTS, PostgreSQL 16, Redis 7
- Chrome / Edge / Firefox current or one prior version; Web Serial requires a Chromium browser
- Cloudflare account with Workers, Pages, R2, KV and Tunnel enabled
Deployment footprint in perspective. The entire origin cluster for two institutions runs on a single mid-tier virtual machine. The cost driver in comparable commercial deployments is per-candidate assessment licensing, which this architecture removes entirely by executing the examination tier on shared edge compute and running language-model inference on hardware the institution already owns.
System Requirement Specifications — Functional & Non-Functional
Functional requirements (abridged)
| FR-1 | Authenticate users and issue short-lived signed tokens with rotating refresh |
| FR-2 | Allow an administrator to define roles and page-level actions without deployment |
| FR-3 | Isolate every tenant's data in application code and at the database engine |
| FR-4 | Maintain student records with bulk import and document management |
| FR-5 | Record attendance by barcode scan and manual marking, idempotently |
| FR-6 | Evaluate drive eligibility per student and expose reasons for near-misses |
| FR-7 | Generate role-targeted, ATS-compatible résumés in multiple formats |
| FR-8 | Conduct proctored examinations and record integrity events per attempt |
| FR-9 | Federate a single identity across the placement and assessment platforms |
| FR-10 | Record every privileged action in an append-only audit log |
Non-functional requirements
| Performance | Interactive API responses under 300 ms at the 95th percentile; résumé generation under 10 s including inference |
| Scalability | 20,000 students per tenant; examination load absorbed by the edge without provisioned capacity |
| Availability | Identity outage must not interrupt existing sessions; hourly off-site backups |
| Security | Reviewed against OWASP Top 10; no secret or endpoint compiled into source |
| Privacy | No personally identifiable data leaves the institutional boundary for inference |
| Usability | Responsive from 360 px; navigation reflects only permitted pages |
| Maintainability | Self-contained modules; idempotent migrations and seeds; portable configuration |
Results and Discussion
What was achieved
- Tenancy is genuinely data-driven. Onboarding an institution is a form submission; no code path is conditional on the institution's identity.
- Eligibility is decided by the server. Direct API calls bypassing the interface are rejected by the same predicate set (T07).
- Résumé homogeneity is solved. Identical inputs yield distinct outputs — the sampler is seeded by the student identifier while the cache is keyed on both.
- Failure isolation holds. Killing the identity service left existing sessions fully functional (T12), confirming the local-verification design.
- Effort saved is measurable. Manual eligibility screening for one drive across a 600-student batch was a multi-hour spreadsheet exercise; it is now resolved on page load.
Discussion — limitations and trade-offs
- Model capacity is the binding constraint. A 1.7 B model is a competent copy-editor but a poor judge; AI-based project ranking was implemented, measured against the deterministic score, found worse, and deliberately disabled. Deterministic ranking is not a fallback — it won.
- Proctoring is heuristic, not proof. The developer-tool check is a viewport-delta inference and can be defeated. Signals are presented as evidence for a human, never as automatic invalidation.
- Similarity detection is lexical. Shingle resemblance catches copied text, not paraphrase or independently-arrived-at identical short answers; the threshold is deliberately conservative.
- Deployment tooling has sharp edges. Orchestrator behaviour with mutable image tags required an explicit force-update step — a health-endpoint build marker was added so a redeploy can be proven rather than assumed.
An honest security finding. A review of the assessment data layer found a managed-database configuration exposing tables to the anonymous role without row-level policies. It was identified, revoked and re-verified. Running real systems surfaces classes of defect that a coursework prototype never encounters.
Applications of the Project
Engineering & degree colleges
The whole platform as intended: identity, attendance, placement and internal assessment for institutions of 2,000–20,000 students, priced per institution rather than per student.
University-affiliated groups
A trust or university operating several campuses runs one deployment with one tenant per campus — consolidated oversight, complete data isolation between them.
Placement cells & T&P offices
Used standalone for drive management, eligibility automation, offer-policy enforcement and recruiter-facing analytics without adopting the academic modules.
Accreditation & compliance
Placement, attendance and outcome data already live in a normalised, audited store — NBA and NAAC collection becomes a query, not an annual reconstruction.
Corporate training & certification
The assessment tier applies unchanged to onboarding and certification exams — cohort management, proctoring and grading are domain-independent.
Skill-development programmes
Skilling missions and coaching institutes can track cohorts, assess them, and route candidates into the shared opportunity feed.
Reusable engineering contributions
- The page-catalogue permission model transplants to any multi-tenant product needing runtime-definable roles
- The PII-free constrained rewriting pattern generalises wherever text generation must not expose personal data to a model
- The local-verification token design answers the "identity service is a single point of failure" problem
Societal application
The shared off-campus feed deliberately crosses tenant boundaries: an opportunity found for one institution becomes visible to students at every institution on the platform. Students at colleges without established recruiter relationships gain the same visibility as those at well-connected ones — a structural reduction of an existing inequality, not an incidental benefit.
Conclusion
This project set out to replace the fragmented, manual and unauditable systems that Indian engineering institutions use to manage the student lifecycle, and to do so as one multi-tenant platform rather than another single-college application.
All nine objectives were met and verified. Tenancy is enforced in application code and independently by the database engine. Permissions are records rather than constants, so an institution defines its own roles without a deployment. Placement eligibility is computed rather than eyeballed, and is re-enforced on the server against direct API access. Résumés are generated in an ATS-safe layout, curated to the most role-relevant work, and differentiated by an on-premise model that never receives a single personally identifiable field. Assessment runs at the network edge with integrity signals recorded per attempt, at no marginal cost per candidate.
Two findings are worth carrying forward. First, a small honest model beats a large uncertain one when the task is bounded — constraining a 1.7 B model to copy-editing produced reliable output where asking it to exercise judgement did not, and we disabled the judgement path on the evidence. Second, operating a system teaches what building one cannot: the defects that mattered most — a database exposure, an orchestrator that silently served stale code — surfaced only because this platform carries real institutional data.
Phase 2, Review 1 status: all core modules are implemented, deployed and serving live institutions. Remaining work is measurement, hardening and scale validation rather than construction.
Future enhancements
- Placement outcome prediction — model historical drive results to forecast conversion and guide preparation
- Semantic skill matching — embedding-based similarity so "PyTorch" satisfies a "deep learning" requirement
- Vision-based proctoring — optional webcam presence and multi-face detection, executed on-device to preserve privacy
- Recruiter portal — direct shortlisting and interview scheduling by company representatives
- Native mobile client — offline-capable attendance capture and push-first notifications
- Horizontal scale-out — migration from single-node orchestration to Kubernetes with read replicas
Beyond the review. The platform is commercially deployed and under active development. This presentation documents an operating system with real users, not a demonstration built for evaluation — and the engineering constraints that follow from that are what shaped every design decision described here.
References
- IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830-1998, Institute of Electrical and Electronics Engineers, New York, NY, USA, 1998.
- R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, "Role-based access control models," Computer, vol. 29, no. 2, pp. 38–47, Feb. 1996.
- M. Jones, J. Bradley, and N. Sakimura, "JSON Web Token (JWT)," IETF RFC 7519, May 2015.
- A. Biryukov, D. Dinu, and D. Khovratovich, "Argon2: New generation of memory-hard functions for password hashing and other applications," in Proc. IEEE Eur. Symp. Security and Privacy (EuroS&P), Saarbrücken, Germany, 2016, pp. 292–302.
- M. M'Raihi, S. Machani, M. Pei, and J. Rydell, "TOTP: Time-based one-time password algorithm," IETF RFC 6238, May 2011.
- C.-J. Guo, W. Sun, Y. Huang, Z.-H. Wang, and B. Gao, "A framework for native multi-tenancy application development and management," in Proc. 9th IEEE Int. Conf. E-Commerce Technology (CEC/EEE), Tokyo, Japan, 2007, pp. 551–558.
- A. Z. Broder, S. C. Glassman, M. S. Manasse, and G. Zweig, "Syntactic clustering of the Web," Computer Networks and ISDN Systems, vol. 29, no. 8–13, pp. 1157–1166, Sep. 1997.
- S. Schleimer, D. S. Wilkerson, and A. Aiken, "Winnowing: Local algorithms for document fingerprinting," in Proc. ACM SIGMOD Int. Conf. Management of Data, San Diego, CA, USA, 2003, pp. 76–85.
- D. Hardt, "The OAuth 2.0 authorization framework," IETF RFC 6749, Oct. 2012.
- N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, and C. Mortimore, "OpenID Connect Core 1.0," OpenID Foundation, Nov. 2014. [Online]. Available: https://openid.net/specs/openid-connect-core-1_0.html
- A. Vaswani et al., "Attention is all you need," in Proc. 31st Int. Conf. Neural Information Processing Systems (NeurIPS), Long Beach, CA, USA, 2017, pp. 5998–6008.
- Qwen Team, "Qwen3 technical report," arXiv preprint, 2025. [Online]. Available: https://arxiv.org/abs/2505.09388
- United Nations General Assembly, "Transforming our world: The 2030 agenda for sustainable development," Resolution A/RES/70/1, Oct. 2015.
- National Board of Accreditation, Self-Assessment Report (SAR) for Undergraduate Engineering Programmes, NBA, New Delhi, India, 2023. [Online]. Available: https://www.nbaind.org
- SEB Consortium, "Safe Exam Browser — Documentation," ETH Zürich, 2024. [Online]. Available: https://safeexambrowser.org
- Open Worldwide Application Security Project, "OWASP Top 10 – 2021: The ten most critical web application security risks," OWASP Foundation, 2021. [Online]. Available: https://owasp.org/Top10/
- M. Shahrad et al., "Serverless in the wild: Characterizing and optimizing the serverless workload at a large cloud provider," in Proc. USENIX Annu. Tech. Conf. (ATC), 2020, pp. 205–218.
- PostgreSQL Global Development Group, PostgreSQL 16 Documentation — Row Security Policies and Table Partitioning, 2023. [Online]. Available: https://www.postgresql.org/docs/16/