Appearance
OA Simulator & Exam Integrity: Results, Analytics & the CP Simulator Compared
Part 5 of 5 in the OA Simulator & Exam Integrity series.
Proctoring & Detection Logic closed the integrity side. This closing page covers what a candidate actually sees afterward, where that result lives, and — because Ediky ships a second timed-practice mode that looks superficially similar — an honest comparison against the CP (competitive programming) Simulator, which solves a genuinely different problem with almost none of the machinery from this series.
The result page scores; the judge doesn't
OAResultPage (desktop) and OAResult (website) both prefer the sealed result written onto the attempt at submit time (attempt.result), and only recompute via computeAttemptResult() for legacy attempts saved before that field existed. This mirrors the judging-vs-scoring split already documented for the coding runner in Judge0 & Code Execution: a background Worker (web) or the local synchronous judge (desktop) decides pass/fail per test case, but the OA engine — not the judge — decides what those verdicts are worth, per Marking Schemes & Scoring. The result page also re-fetches the full body of each attempted question on demand (the same getQuestion() path used everywhere) to build the topic-wise weak-area breakdown, rather than carrying every question's full content through the live exam session — a deliberate memory/bandwidth trade the exam itself never pays.
rendering diagram…
drag to pan · ctrl / ⌘ + scroll to zoom
History is a personal trend line, not a cohort percentile
Both result pages compute a score-history chart: every finished attempt this candidate has taken, oldest to newest, with the current one labeled "This." It is deliberately a trend against your own past, not a percentile against other test-takers — Ediky has no cross-candidate grading pool to compare into, and inventing one would be dishonest. The weakTopics() helper from the shared engine is what makes this more than a vanity chart: concatenating perQuestion arrays across several past attempts and re-running the same 60%-solve-rate filter is what "Retry Weak Areas" targets, so a candidate's third attempt can be generated specifically against what their first two got wrong.
Regrade with AI exists for one honest reason: the nine-provider fallback chain that grades free-text CS Fundamentals answers (see AI Pipeline) can degrade mid-exam, or a rubric can be updated after the fact. Re-running grading and writing fresh verdicts back onto the attempt is strictly a post-hoc correction — MCQ answers are graded deterministically client-side and never touch this path.
Where a result actually lives
Consistent with the storage split covered in Task 1: the website writes attempts to users/{uid}/oaAttempts in Firestore, with the server-recorded startedAt as the timer's source of truth (see OA Structure & Timer Logic). The desktop build keeps OA attempts fully local — useOAAttempt.js reads and writes through saveOaAttempt/getOaAttempt against the local SQLite database, with no background upload to Firestore. This is a stricter version of the general desktop pattern (local storage instead of Firestore, documented in Desktop Features & Data Flows): an OA attempt, its full audit chain, and its risk score never leave the candidate's machine unless the candidate exports them.
OA Simulator vs. CP System: two timed formats, one shares almost nothing with the other
CP System ("God's Will") is a 600-problem competitive-programming set organized into timed contests, and it is easy to assume it reuses this series' machinery because both are "timed practice." It doesn't, beyond the timer itself:
| OA Simulator | CP System | |
|---|---|---|
| Source of truth for "solved" | Ediky's own judge (Judge0) or AI grading | Codeforces itself — a CF proxy checks the candidate's real submission history for an OK verdict |
| Timer | Server (startedAt) — same model | Also server-backed startedAt — same integrity model, same reason auth persistence is indexedDBLocalPersistence |
| Marking | Configurable, difficulty-tiered, negative marking | None — solved/unsolved only, no partial credit |
| Section structure | Sequential/one-way sections, per-unit timers | Flat problem list per contest, no sections |
| Integrity monitoring | Full risk engine + hash chain (desktop); useAntiCheat (web) | None — verification against Codeforces' own judge is the only check |
| Purpose | Simulate a company's hiring screen | Rating-climbing practice against real archived problems |
The CP System's honor system is really Codeforces' own: a candidate cannot fabricate a solve because the verification call hits codeforces.com directly, not a local claim. That is a fundamentally different trust model from the OA Simulator's — CP doesn't need a risk engine because it isn't grading anything Ediky itself could be tricked about.
What this series covered, and what it plugs into
Five pages: the three timing shapes and the forfeit-on-early-exit timer model (OA Structure & Timer Logic); the shared, difficulty-tiered marking engine with negative marking and coding partial credit (Marking Schemes & Scoring); the policy-driven risk engine and its three-layer tamper-evident hash chain (Risk Engine & the Hash-Chained Audit Log); the DOM, process, and MediaPipe vision sensors feeding it, plus the separate progressive mark-penalty system (Proctoring & Detection Logic); and this page's results pipeline and honest comparison against CP.
Every page depended on what came before it in this documentation set: Task 1's Firestore/SQLite split is what makes the web/desktop OA storage divergence explicable rather than arbitrary; Task 2's dashboard patterns are the surface the score-history and weak-topic analytics ultimately render into; Task 3's judging pipeline is exactly what a "solved" DSA question in this series' marking scheme is built on top of. Architecture, interface, judge, and exam — four layers of the same product.
Self-assessment
Word count for this page: 918 words (over target to give the OA-vs-CP comparison and the closing cross-reference their full weight rather than trimming either).
← Previous: Proctoring & Detection Logic↩ Series start: OA Structure & Timer Logic