Juvenotes: AI for Med Exam Prep
- Juvenotes is an AI-powered platform that automatically converts academic documents into exam-style question banks, enhancing revision efficiency in low-resource settings.
- It employs a pipeline integrating OCR via Azure Document Intelligence and AI generation using OpenAI o3-mini to extract and structure educational content.
- The system features mobile-first, bandwidth-optimized design with institutional tagging and human validation to meet local curricular and infrastructural challenges.
Juvenotes is an AI-powered medical education platform for automatically converting academic documents—especially past exam papers and related teaching materials—into structured, exam-style question banks for students. It is described both as an automated content-generation pipeline and as a low-resource-aware study platform optimized for Kenyan medical schools, with design choices centered on mobile access, bandwidth sensitivity, institutional tagging, and human validation. In the reported Kenyan case study, Juvenotes was implemented as a real-time pipeline built around Azure Document Intelligence for OCR and Azure AI Foundry using OpenAI o3-mini for question and answer generation, then integrated into a web platform backed by a relational database and search services (Korir et al., 7 Jul 2025).
1. Definition, scope, and educational setting
Juvenotes addresses a specific bottleneck in medical education: the slow, labor-intensive conversion of existing academic documents into usable revision resources. The platform takes uploaded educational documents, extracts their contents, identifies question structures, generates answers and explanations, and stores the outputs as structured question banks. The resulting materials may include multiple-choice questions, short-answer questions, answers, answer options, explanations, and metadata linking questions to source paper, course, concept, and institution (Korir et al., 7 Jul 2025).
The system is situated in a broader low-resource educational context. The motivating paper places Juvenotes against the World Health Organization’s projection of a shortage of about 6.1 million health workers in Africa by 2030 and emphasizes that medical education in low- and middle-income countries is constrained by insufficient medical educators and training infrastructure, slow manual authoring of study materials, limited broadband access, expensive mobile data, intermittent electricity, and e-learning systems that remain small pilots and fail to scale. It also cites a figure that only 36% of Africans have broadband access, which directly informs Juvenotes’s emphasis on mobile-first and bandwidth-optimized interaction design (Korir et al., 7 Jul 2025).
In functional terms, Juvenotes is not a document repository. It is a transformation system that converts raw academic materials into searchable, tagged, interactive study content. The platform supports filtering by school, course code, and concept or topic, which is important in settings where curricular emphasis varies by institution. The authors also stress that generic AI outputs may not match local curricular and guideline contexts unless prompts and review practices are adapted accordingly (Korir et al., 7 Jul 2025).
2. End-to-end transformation pipeline
The Juvenotes pipeline begins with document ingestion through a web interface. Users upload educational documents, especially PDF files of past exam papers, and the platform provides upload progress indicators and real-time processing logs so that long-running OCR and AI stages remain visible to users under weak or unstable connectivity. Once uploaded, the document is sent from the web application to a Python-based AI engine over a persistent WebSocket connection (Korir et al., 7 Jul 2025).
The OCR stage is handled by Azure Document Intelligence. According to the reported implementation, it extracts raw text, paragraphs, lines, words, tables, layout information, key-value pairs, and document structure. The Read OCR model is specifically used for scanned exam papers, and the output is JSON representing document structure. This stage is central because source materials in low-resource institutions may be scanned, poorly formatted, or heterogeneous in layout (Korir et al., 7 Jul 2025).
After OCR, the extracted text and structure are forwarded to Azure AI Foundry, using OpenAI o3-mini, version 2025-01-31. The model is prompted to identify exam-style question-answer pairs from the source content, generate high-quality answers, and produce outputs aligned with the platform’s database schema. The paper mentions fields such as question, choices, correct answer, and explanation, and states that the system handles different question types, including multiple-choice and short-answer items (Korir et al., 7 Jul 2025).
The generated output is then parsed and inserted into PostgreSQL. The paper explicitly names the tables questions, mcq_choices, saq_parts, and past_papers, indicating that AI outputs are mapped into a relational schema rather than preserved as unstructured text. Original documents and intermediate artifacts such as OCR JSON are stored in Azure blob or object storage for persistence and auditing. Once inserted, the generated questions become immediately available through the web interface, with search indexing supported by MeiliSearch and Algolia. Student responses, ratings, and engagement data are then logged, while faculty can flag and correct problematic content before republication (Korir et al., 7 Jul 2025).
| Stage | Main component | Output |
|---|---|---|
| Ingestion | Web interface and WebSocket transfer | Uploaded academic document |
| OCR | Azure Document Intelligence | Structured JSON with text and layout |
| Generation | Azure AI Foundry with OpenAI o3-mini | Structured question-answer content |
| Persistence | PostgreSQL and object storage | Question records, metadata, source artifacts |
| Delivery | Web frontend plus search services | Searchable, tagged study content |
This workflow is best described as upload → OCR → LLM transformation → schema insertion → student delivery → feedback logging → faculty correction/validation. The final validation step is essential, because the platform is explicitly not treated as fully autonomous (Korir et al., 7 Jul 2025).
3. System architecture and data model
Juvenotes uses a containerized microservices architecture intended to support portability, resilience, and independent scaling. The core system has two main services. The web service is built with Vue, TypeScript, and AdonisJS, and is responsible for the user interface, session handling, institutional affiliations, API routing, database schema and business logic, and mapping generated questions to courses and concepts. The AI engine is implemented in Python, exposes a WebSocket API, and orchestrates OCR and LLM calls while formatting model outputs for insertion into the database (Korir et al., 7 Jul 2025).
Both services are containerized with Docker and deployed on Ubuntu virtual machines in Azure. Coolify is used for automated builds and orchestration, with trunk-based development and branch-triggered rebuild and redeploy workflows. Inter-service communication is secured over internal Azure networks, and the architecture is justified partly by the fact that OCR and LLM workloads are bursty and more compute-intensive than routine browsing or answer submission (Korir et al., 7 Jul 2025).
The data layer is organized around PostgreSQL, described as Supabase-hosted PostgreSQL in the architecture descriptions. The schema spans user management (users, roles), institutional integration (institutions, institution_courses), educational content (courses, concepts, past_papers, questions, mcq_choices, saq_parts), engagement tracking (user_mcq_responses, user_saq_responses, user_study_sessions, analytics, user_study_times), and feedback and progress (question_feedbacks, user_concept_progress). The relational design allows each generated question to be linked to curricular context, source provenance, and later user performance (Korir et al., 7 Jul 2025).
Several supporting services are also named. MeiliSearch and Algolia are used for search indexing; Cloudinary for media hosting; PostHog for analytics; Mailgun for email notifications; and M-Pesa for mobile payments. The paper also states that processed results and metadata such as confidence and timestamps are stored for auditing and analytics, although it does not define a formal confidence formula or thresholding rule (Korir et al., 7 Jul 2025).
4. Low-resource design logic
A defining characteristic of Juvenotes is that it is not merely AI-enabled; it is engineered for low-resource medical education environments. The frontend is described as mobile-first and responsive because many students use low-cost smartphones rather than laptops. The interface is also repeatedly characterized as lightweight and bandwidth-optimized, with progress indicators and real-time OCR and AI logs designed to reduce user uncertainty during slow or interrupted processing (Korir et al., 7 Jul 2025).
The platform includes institutional tagging and local-context support. Students can filter content by school, course code, and concept or topic, while prompts are described as incorporating local context such as Kenyan guidelines. This is intended to reduce misalignment between generic AI-generated content and national or institutional expectations. The system is also described as free for partner institutions and as supporting accessibility-oriented features including large fonts, high contrast, and language support (Korir et al., 7 Jul 2025).
Offline-capable features and intermittent sync are explicitly discussed as practical mitigation strategies, although the paper does not provide implementation-level details such as service workers, local storage technology, or conflict-resolution algorithms. The authors instead emphasize that the pilot revealed the need for expanded offline synchronization and offline access. This suggests that low-resource adaptation was treated not as a one-time interface choice, but as an ongoing operational requirement (Korir et al., 7 Jul 2025).
These design choices are tightly coupled to the reported deployment environment. Poor and inconsistent internet affected uploads, responsiveness, and continuity of study access, while unreliable electricity created further constraints. In that context, real-time processing visibility, mobile-first presentation, and bandwidth-sensitive interaction are not ancillary user-experience features; they are part of the system’s core educational strategy (Korir et al., 7 Jul 2025).
5. Evaluation, reported outcomes, and operational constraints
The reported evaluation is a seven-month pilot across five Kenyan institutions: University of Nairobi, Moi University, Kenyatta University, Egerton University, and KMTC. The pilot included both medical students and faculty. Faculty uploaded past papers and used the generated banks, while students used the resulting question banks through the platform interface (Korir et al., 7 Jul 2025).
The main reported outcomes are operational rather than experimental. Juvenotes reduced content curation time from days to minutes, increased daily active users by 40%, and, according to the paper, 90% of surveyed students reported improved study experiences or higher satisfaction compared with traditional methods. Students were said to value especially instant access to questions and immediate feedback. At the same time, the authors explicitly note that the evaluation relies on usage analytics and user surveys rather than controlled educational-effectiveness studies, and they call for stronger future evaluation frameworks such as pre/post testing, quasi-experimental designs, and higher-level assessment models (Korir et al., 7 Jul 2025).
The deployment also exposed several practical constraints. Intermittent connectivity remained a recurring challenge, affecting uploads and continuity of access. AI-generated errors were reported as a further limitation, including domain inaccuracies and imperfect local alignment. The mitigation strategies described include human-in-the-loop review, faculty review and correction, student feedback logging, prompt fine-tuning, and future model fine-tuning on local curricula. The paper also notes that long-term sustainability depends on faculty involvement, institutional investment, technical support, and curricular integration (Korir et al., 7 Jul 2025).
Governance and privacy are addressed in broad terms. The paper states that data is encrypted in transit and at rest, that the system complies with Kenyan and international standards, and that no personal data is sent to AI services beyond academic necessity. It does not, however, provide a detailed retention policy, consent framework, or institutional review protocol. This leaves the governance account substantial in principle but limited in implementation detail (Korir et al., 7 Jul 2025).
6. Position within educational technology research
Juvenotes occupies a distinct position among educational systems that structure learning around documents, notes, or interactive workflows. Unlike U-Note, which is a paper-centric classroom capture and access system linking handwritten notes to teacher audio, slides, web pages, and whiteboard events, Juvenotes is focused on converting uploaded academic documents into searchable, structured revision materials for later study (Malacria et al., 2012). Unlike MOON, which formalizes intended Jupyter notebook execution scenarios as a script and guides students through notebook workflows with live visual cues, Juvenotes does not target notebook execution order or runtime pedagogical scenario control (Casseau et al., 2023).
This contrast clarifies Juvenotes’s technical and pedagogical identity. Its central problem is not note-to-media synchronization, as in U-Note, nor notebook-state guidance, as in MOON. It is automated academic-content transformation under low-resource constraints. Where U-Note treats the notebook as the anchor for accessing recorded classroom context and MOON treats the notebook as a stateful interaction script, Juvenotes treats the uploaded academic document as the raw material for generating institutionally tagged exam-practice content (Malacria et al., 2012, Casseau et al., 2023).
A plausible implication is that Juvenotes belongs to a class of systems centered on workflow compression: it shortens the path from source document to student-facing study material. Its strongest demonstrated contribution is therefore operational. The reported shift from days to minutes in content curation, together with the 40% increase in daily active users, indicates that the platform’s immediate value lies in accelerating the production and delivery of revision resources under conditions of weak connectivity, limited faculty time, and constrained infrastructure (Korir et al., 7 Jul 2025).
More broadly, the system illustrates a hybrid model of educational AI deployment. Cloud OCR and LLM services provide speed and scale; mobile-first and bandwidth-sensitive design provide usability in constrained settings; and faculty review, institutional tagging, and local-context prompting provide a mechanism for trust. The paper’s own account consistently treats those three elements—automation, contextual adaptation, and human validation—as inseparable components of the platform rather than alternative design choices (Korir et al., 7 Jul 2025).