From Zero to One: Engineering a Desktop AI Exam Grading System

    Web-based exam grading platforms have digitized how test papers are scanned and distributed, yet the scoring of subjective questions still falls entirely on teachers. This article walks through the engineering practice of building a desktop application that bridges that gap: it takes over mainstream web grading platforms and automates the full screenshot → AI scoring → score entry → submission loop. It covers the key architecture decisions — a Chromium- and Node.js-based desktop container, a lightweight native HTML/JavaScript frontend, local OMR recognition with OpenCV.js, offline document parsing with pdf.js, provider-agnostic AI integration, and a no-backend privacy-first design — along with the main engineering challenges, including platform heterogeneity, scoring consistency, and offline operation, and the lessons learned over 61 iterations.

    Background: The Overlooked “Last Mile”

    Exam grading in K-12 schools has long since completed its digital transformation. Mainstream online grading platforms scan paper exams into images, and teachers score each question on screen. These platforms solved the “paper” problem of moving exams around, but not the “human” problem of scoring: with hundreds of papers to review, teachers still grade one paper at a time, one question at a time. Objective questions can be handled automatically by OMR (Optical Mark Recognition), but subjective questions depend entirely on the teacher’s professional judgment — and physical stamina.

    A natural conclusion follows: now that large language models offer sufficiently strong reasoning and vision capabilities, “scoring subjective questions against a rubric” should, in theory, be fully automatable. The real question is how to turn that idea into a tool teachers can genuinely use — and trust.

    System Positioning and Core Capabilities

    The system can be summarized as a desktop application that takes over mainstream web-based grading platforms to deliver AI-powered automated grading. It does not change the teacher’s existing workflow. Instead, it inserts an automation layer between the teacher and the grading platform, handing the repetitive cycle of “screenshot → score → enter → submit” over to the machine.

    Its core capabilities fall into three layers:

    • Browser-automated grading: takes over the web grading platform and automatically completes the full loop of capturing screenshots, calling the AI for scoring, entering scores, and submitting results, with support for unattended operation.
    • Intelligent question grading: for individual subjective questions, scores against rubrics defined by the teacher, attaching deduction reasons and comments so teachers can understand the AI’s grading logic.
    • Whole-paper grading: batch grading for an entire exam (multiple questions × multiple students), with automatic aggregation of totals, rankings, averages, and pass rates, and export to spreadsheets or structured documents.

    Technology Choices and Architecture

    Desktop Framework: A Cross-Platform Container

    The application runs inside a cross-platform desktop framework built on Chromium and Node.js. The decisive factor in this choice was the need for an embedded browser engine. Only with full browser rendering capability can the app “take over” existing web grading platforms — not by reverse-engineering their interfaces, but by simulating the operations a teacher would perform in the browser. This approach is completely transparent to the platform side: it requires no APIs from the platform and no cooperation from the platform vendor.

    Frontend Rendering: Lightweight First

    The frontend uses native HTML/JavaScript without any heavyweight framework. Rendering performance in a desktop app directly shapes the user experience, and the grading interface is not especially complex, so a native approach is more than sufficient. Mathematical formulas are rendered locally with KaTeX and mhchem, so chemical equations and math expressions display correctly even offline.

    Machine Vision: Local OMR Recognition

    The app embeds OpenCV.js (a roughly 10 MB WebAssembly module) for OMR recognition on answer sheets. Running vision computations locally avoids the privacy risk of uploading student answer sheets to third-party services and eliminates the latency of network round trips. OMR covers the objective-question portion; subjective questions are handled by the AI scoring module.

    Document Parsing: All Local

    pdf.js parses PDF exam papers and answer sheets locally, and a Markdown renderer handles text content. All document parsing happens on the device, with no dependency on cloud services.

    AI Integration: Open and Vendor-Neutral

    The system is not tied to any AI provider. Teachers can enter their own API endpoint, key, and model name in the settings, and it works with any AI service that follows the common API specification. Token usage is displayed in real time, helping teachers stay on top of costs. This design respects teachers’ freedom of choice and avoids the risks of vendor lock-in.

    Automatic Updates: Silent Upgrades

    Through the desktop framework’s auto-update module, delivered via a code hosting platform’s release channel, the app checks for updates silently. Teachers never need to download and install packages manually, which keeps maintenance costs low.

    No-Backend Architecture: Privacy First

    The system has no backend services at all. All grading records, scoring templates, and API keys are stored in the browser storage on the local machine. Exam content is sent only when AI scoring is invoked, and only to the endpoint the teacher has configured. This matters enormously in education — teachers and parents are extremely sensitive to the question of whether students’ answer sheets could end up with a third party. A no-backend architecture physically rules out any possibility of data being retained on the developer’s side.

    Core Workflow Breakdown

    The Automated Grading Flow

    1. ┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
    2. │ Take over the web │ → │ Capture screenshots │ → │ AI scoring against │
    3. │ grading platform │ │ of question areas │ │ the rubric │
    4. └──────────────────────┘ └──────────────────────┘ └──────────────────────┘
    5. ↓
    6. ┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
    7. │ Submit results to │ ← │ Fill scores into │ ← │ Generate comments │
    8. │ the platform │ │ score input fields │ │ and deductions │
    9. └──────────────────────┘ └──────────────────────┘ └──────────────────────┘

    The flow mirrors the exact sequence of actions a teacher performs in the browser: locate the question area, take a screenshot, send it to the AI for scoring, enter the returned score into the corresponding input field, and submit. The key lies in reliably identifying and manipulating the page’s DOM structure, and in parsing and validating the AI’s returned results.

    Turning Rubrics into Structured Prompts

    AI scoring only works if the rubric is translated into a prompt the model can understand. The system lets teachers describe grading criteria in natural language, for example:

    1. This question is worth 10 points.
    2. - 4 points for writing the correct formula;
    3. - 2 points for substituting the data correctly;
    4. - 3 points for the correct final result;
    5. - 1 point for the correct unit.
    6. If the result is wrong but the process is correct, award partial credit at your discretion.

    The AI checks the student’s answer in the screenshot against each criterion and outputs a score, deduction reasons, and a comment. The comment serves not only the student; it also helps teachers quickly verify whether the AI’s judgment is reasonable.

    Batch Processing and Score Aggregation

    In whole-paper mode, the system works through a two-dimensional “question × student” matrix. For each question, every student’s answer is sent to the AI in turn, and results are staged locally. Once everything is graded, the system automatically aggregates each student’s total score, computes rankings, averages, and pass rates, and exports the results as spreadsheets or structured documents.

    Engineering Challenges and Solutions

    Heterogeneous Grading Platforms

    Grading platforms differ dramatically in page structure. The system relies on a configurable adapter layer: on first use, the teacher visually marks the positions of key elements — question areas, score input fields, the submit button — and the system saves these configurations for reuse. The adapter isolates platform differences at the configuration level, leaving the core scoring logic untouched.

    Consistency of AI Scoring

    Large model output carries a degree of non-determinism. To keep scoring consistent, the system takes three measures:

    • Lower temperature: the temperature parameter is set to a low value when calling the AI API to reduce randomness.
    • Structured output constraints: the AI must return results in a fixed format (score, reason, comment), which makes parsing and validation straightforward.
    • Score range validation: returned scores are range-checked; anything outside the plausible range triggers a re-score or an anomaly flag.

    Offline Compatibility

    Some schools operate under restricted network environments. Document parsing, OMR recognition, and formula rendering all run offline. Only the AI scoring step requires a network connection, and even then the endpoint is configured by the teacher, not controlled by the developer.

    Privacy and Security by Design

    Education demands extremely high standards for data privacy, and the architecture reflects that:

    • No backend: the developer operates no servers and never touches student data.
    • Local storage: all records, templates, and keys stay on the local machine; there is no cloud sync.
    • On-demand transmission: exam images are sent only to the teacher-configured AI service at scoring time, and the payload excludes student identity information (with configurable anonymization).
    • Transparent and controllable: teachers can view, export, and delete their local data at any time and retain full data sovereignty.

    Conclusion and Future Directions

    At its core, this desktop AI grading system fills the “last mile” of automation between the digitization that grading platforms have already achieved and the manual scoring that teachers still carry out. The logic behind the technology choices is clear: use the desktop container’s browser engine to take over web platforms, use local vision computing to protect privacy, use open AI interfaces to respect teacher choice, and use a no-backend architecture to build trust.

    Across 61 versions, the biggest takeaway was not an accumulation of technical solutions but a deeper understanding of teachers’ real workflows. Teachers do not want a “smarter AI” — they want a tool that requires no change to existing habits, raises no worries about data leaks, and adds no learning curve. Technology only delivers real value when it fits into the actual scenario.

    Future directions include finer-grained rubric template management, stronger recognition of multimodal answers (handwritten formulas, charts and diagrams), and personalized scoring-preference learning based on historical grading data. However the feature set evolves, two principles will not change: privacy first, and teacher autonomy.