RES·Resilient Exams
FeaturesPricingAboutContact
Sign inGet started

Product

  • Features
  • Pricing

Company

  • About
  • Contact

Platform

  • Sign in
  • Get started

Legal

  • Privacy policy
  • Terms of use

RES · Resilient Exams

© 2026 Youniverse Business School. All rights reserved.

Every edge case has an answer.

Every capability here was built around a real failure mode. This is how each one works.

Offline-first exam engine

Before the exam starts, the service worker precaches the entire exam shell, the question bank, and all supporting assets. The student enters the exam already self-sufficient.

Every answer is written to IndexedDB the moment the student types it — before any network request is attempted. The sync queue drains opportunistically in the background, with exponential back-off and jitter on failure.

If the sync queue is still non-empty when the student submits, the submission flow drains it first. Nothing is discarded.

Server-authoritative time

The server sets the allocated end time when the session starts. The client renders a local countdown, but the server's clock is the only one that matters for submission.

The client can't extend its own session. Pause and resume are computed server-side from the accumulated paused duration. Time drift on the client is cosmetic.

Heartbeat and pause/resume

A dedicated Go service — separate from the Next.js app — handles heartbeats. Each heartbeat is a single database write, no joins, no transactions.

An async sweeper runs every ten seconds and finds sessions whose last heartbeat is more than thirty seconds old. It flips them to paused. The HTTP request handler does nothing except update a timestamp.

When a student reconnects, a resume endpoint computes the new allocated end time by adding the total paused duration. The student's clock jumps forward accordingly.

Anti-cheat telemetry

The client captures blur events, visibility changes, paste attempts, copy attempts, and fullscreen exits. Each is sent through the same idempotent write path as answers — with a client UUID for deduplication.

Exam authors can configure each event type per exam: hard block (paste is prevented; fullscreen is enforced on start), soft warning (event is logged but the student continues), or off.

The admin live dashboard shows every student's telemetry timeline in real time. Flags are surfaced without requiring the examiner to watch every tile simultaneously.

Signed recovery fallback

In the event of a complete network failure — power outage, router failure, anything — the student can download a signed, encrypted dump of their Dexie database directly from their browser.

The file is encrypted with the session's server-issued public key. The server's private key is required to decrypt it. A forged dump cannot be fabricated without the private key.

The admin uploads the file through the recovery UI. The signature is verified, the dump is decrypted, and every answer materialises as if it had synced normally. Uploading the same dump twice produces no duplicates.

Scoring and results

Multiple choice, multiple select, and true/false questions are auto-scored. The scoring worker runs in a BullMQ queue — not in the request handler — so 1,000 sessions can be scored without slowing the application.

Short answer and essay questions go to a manual grading UI. Examiners see the question, the rubric, and the student's response side by side. Grades are saved optimistically.

Results are not published until the examiner explicitly publishes them. Students see nothing until then.