1. System Modules Overview
NewtonEd is a full-stack AI-powered student education platform with a Laravel 12 backend API, a React 19 web app for admins and teachers, and a Flutter mobile app for students, teachers, and parents. The platform places AI-driven learning at the centre: from personalized explanations and topic understanding to learning analytics, weak-area detection, and parent voice chat. All clients use the same REST API with Laravel Sanctum authentication.
AI across NewtonEd: Student education is powered by AI learning analytics (topic mastery, weak areas, trends), AI Read More (on-demand explanations), AI Topic Understanding (self-check MCQs), AI Parent Voice Chat, and AI voice processing (Groq). Reports, recommendations, and insights are generated and personalized using this AI layer throughout the project.
1.1 Backend (Laravel)
| Module | Description |
|---|---|
| Authentication | Handles secure login, registration, and logout for all users. Supports password reset via OTP so students, teachers, and parents can recover access safely. Token-based authentication enables the web and mobile apps to stay in sync with the backend. |
| Profile | Lets each user view and update their own profile information, keeping identity and contact details accurate across the platform. |
| Dashboard | Delivers role-based analytics and summaries so admins see school-wide or branch-level activity and teachers see their classes at a glance. |
| School Update | Allows school administrators to maintain and update school-level information that drives the rest of the system. |
| Activity Logs | Keeps an audit trail of important user actions for compliance and support. |
| Timetable | Stores and updates the institution’s timetable so schedules stay consistent for students and staff. |
| Branches | Manages school branches so multi-branch institutions can organise data and access by location. |
| Departments | Defines departments within the organisation, supporting structure and reporting. |
| Designations | Maintains job titles and designations, often linked to departments, for staff and teachers. |
| Custom Roles | Lets schools define custom roles with fine-grained permissions so access aligns with policy. |
| Employees | Maintains the full staff roster so the school has a single source of truth for employment and roles. |
| Teachers | Manages teacher accounts and subject assignments. Supports teacher-specific flows on mobile so they can view their classes and lectures on the go. |
| Grades & Grade Sections | Organises academic structure: grades and sections, with subjects assigned to sections so curriculum and enrolment are clearly defined. |
| Students | Manages student records and powers the student experience: subjects, lectures, assessments, reports, and learning data. Feeds into AI learning analytics and parent views so every student’s journey is trackable and supportable. |
| Student Intelligence (AI) | Provides AI-backed intelligence metrics per student: overall and per-subject capability indicators, comparisons, and class overviews. These metrics enrich learning reports and help teachers and parents understand student strengths and growth. |
| Learning Analytics (AI) | The core AI education engine: topic mastery, weak-area detection, question-level performance, repeated mistakes, assessment trends, and retention. Produces student-, instructor-, and parent-facing learning reports and institution-level summaries so the whole ecosystem benefits from data-driven insights. |
| Parent Voice Chat (AI) | Enables parents to converse with an AI assistant that knows only their selected child. Questions about progress, weak topics, or recommendations are answered in natural language, with history kept for later review—putting AI-powered guidance in parents’ hands. |
| Subjects | Manages subjects and their assignment to grade-sections and teachers, forming the backbone of the curriculum. |
| Guardians | Manages guardian accounts and links them to students so parents can access their children’s data and AI reports appropriately. |
| Lectures | Stores and serves lecture content and media. Lectures are the primary learning material that students consume and that AI Read More and topic understanding enhance. |
| Events | Manages school and class events so calendars and dashboards stay up to date. |
| Read More (AI) | Delivers AI-generated explanations at different depth levels for lecture text, images, and video. Students request “read more” to deepen understanding without leaving the lesson; usage is tracked and feeds into learning analytics and weak-area detection. |
| Lecture Tracking | Captures how each student interacts with lectures: progress, topic engagement, quiz attempts, and Read More usage. This data is the main input for AI learning analytics and personalised reports. |
| Topic Understanding (AI) | Powers a teacher-less “Do you understand?” flow: AI generates multiple-choice questions for a topic and records the student’s attempt. Gives immediate feedback and feeds topic-level data into analytics so students can self-check and the system can identify gaps. |
| Assessments | Handles creation, attempt, and submission of assessments. Results feed into AI learning analytics (trends, weak areas, repeated mistakes) so student growth is measurable and actionable. |
| Groq Voice (AI) | Processes voice commands and voice input via an AI service so users can interact by speaking—supporting accessibility and hands-free use in the chatbot and voice assistant. |
| Attendance | Supports monthly views, bulk entry, and reports so attendance is easy to manage and review. |
| File Upload | Handles secure upload of lecture media and other files, with support for local or cloud storage. |
1.2 Web Frontend (React)
| Module / Area | Description |
|---|---|
| Auth | Secures the web app with login, token and cookie handling, and route protection so only authenticated users reach the dashboard and admin areas. |
| Layout | Provides the app shell with navbar and sidebar so admins and teachers have a consistent, navigable experience. |
| Dashboard | Shows analytics, statistics, recent activity, and a calendar so users see the big picture as soon as they log in. |
| Profile | Lets users view and edit their profile so identity and preferences stay up to date. |
| My School & Branches | Lets school admins manage school-wide settings and branches so multi-branch setups are easy to maintain. |
| Departments, Designations, Roles | Supports organisational structure and custom roles so schools can align permissions with their policies. |
| Employees, Teachers, Students, Guardians | Provides list and detail views for all people in the system so admins and teachers can manage and inspect records in one place. |
| Grades & Subjects | Manages grades, sections, and subjects so the curriculum is clearly defined and assignable to teachers and students. |
| Lectures | Lists lectures for admins and shows a role-based lecture detail for students: video, quiz, and AI-powered Read More sections so learning is interactive and supported by on-demand explanations. |
| Events | Manages school and class events so the calendar and dashboard reflect the latest schedule. |
| Assessments | Lets teachers and admins manage assessments and allows students to attempt them; results feed into AI learning analytics and reports. |
| Reports | Presents attendance, performance, AI-driven learning reports, and parent-oriented learning reports so teachers and admins get actionable insights and can share them with parents. |
| Global | Shared data tables, cards, snackbars, and theme support so the app feels consistent and professional. |
1.3 Mobile Application (Flutter)
| Feature | Description |
|---|---|
| Core | Provides theme, API and storage integration, navigation, text-to-speech support, and smooth transitions so the app is consistent, responsive, and accessible—including for AI voice and TTS features. |
| Auth & Splash | Handles login and token persistence, then redirects users by role after a short splash so students, teachers, and parents land on the right experience. |
| Student | The heart of AI-backed student education on mobile: main dashboard, subjects, subject detail, lectures with video and transcript, quizzes, assignments, and AI learning report. Students use Read More for deeper explanations, Topic Understanding for self-check MCQs, and see personalised reports on strengths and weak areas—all driven by the same AI analytics that power the platform. |
| Teacher | Gives teachers their dashboard, subjects, lecture creation and list, assessments, assignments, and AI-powered student and learning reports so they can support students with data-driven insights on the go. |
| Parent | Lets parents select a child and then view that child’s AI learning report and use AI voice chat to ask questions in natural language and get answers about progress, weak topics, and recommendations—putting AI guidance in parents’ hands. |
| Shared | Shared flows for attempting quizzes, viewing content in a webview, and using the AI chatbot and text-to-speech (voice assistant) so students and parents can learn and get help in a consistent, accessible way. |
2. Authentication Module
Backend (Laravel)
- Implementation: Laravel Sanctum for API token authentication. Web clients may use cookie-based session; mobile uses Bearer token.
- Controllers:
AuthController(login, register, logout, getUser),PasswordResetController(sendOtp, verifyOtp, verifyOtpAndResetPassword, resendOtp, getOtpStatus). - Middleware/Guards:
auth:sanctumon all protected routes; validates Bearer token or session cookie. - Database:
users,personal_access_tokens(Sanctum),password_reset_otps. - Token handling: On login,
$user->createToken('auth_token')->plainTextTokenreturned in response. Token stored client-side; sent inAuthorization: Bearer <token>. - Security: Validation on email/password; failed attempt returns 401; activity log on successful login.
- API endpoints: POST
/api/login,/api/register, POST/api/logout(auth:sanctum), GET/api/me; POST/api/forgot-password,/api/verify-otp,/api/reset-password,/api/resend-otp, GET/api/otp-status.
Web Frontend (React)
- State:
AuthContextholdsuser,authUser(from cookie),loading.currentRolederived fromauthUser?.user?.roles[0]?.slug. - Login form:
Login.jsx; callsapiService.post('/login', { email, password }); on success sets cookies and state. - Token storage:
Cookies.set('NewtonEdUserToken', token),Cookies.set('NewtonEdUser', JSON.stringify(user))with 7-day expiry. - API integration: Axios instance in
apiService.js; request interceptor addsAuthorization: Bearerfrom cookie. - Route protection:
AppLayoutchecksuseAuth().user; if absent,Navigate to="/". - Error handling: Response interceptor on 401 and message "Unauthenticated." clears cookies, dispatches snackbar event, redirects to / after 1.5s.
Mobile (Flutter)
- Screens:
LoginScreen;SplashScreenchecks auth and redirects to login or role dashboard. - API:
AuthProvider.login(LoginRequest)callsApiService.post('login', data: request.toJson()); parsesdata.useranddata.token. - Token management: Token and user JSON saved via
StorageService.saveToken,StorageService.saveUserData(SharedPreferences). - Secure storage: SharedPreferences for token and user data; no sensitive data in plain text outside app storage.
- Session:
AuthProvider.checkAuthStatus()reads token and user from StorageService; if both present, sets_isLoggedInand_currentUser. - Navigation guards:
RoleNavigationHelper.getDashboardRoute(user)returns /text-to-speech (student), /teacher-main (teacher), /parent-student-selection (parent), /teacher-main (admin); else /login.
Authentication Flow (Mermaid)
Authentication Sequence (Client → API)
3. Dashboard Module
Backend (Laravel)
DashboardController: getDashboardAnalytics() for all roles; getBranchAnalytics($branch_id) for school-admin and school-branch-admin. Returns aggregated stats (counts, recent activity). Data from schools, branches, employees, students, lectures, etc.
Web Frontend (React)
Dashboard.jsx under route /app and /app/dashboard. Uses DataContext/AuthContext; fetches analytics via apiService; displays cards, charts (Recharts), event calendar (react-big-calendar).
Mobile (Flutter)
Student: MainScreen (StudentMainProvider, mobile-main-new API). Teacher: TeacherMainScreen (TeacherMainProvider, teacher/mobile-main-new). Parent: ParentStudentSelectionScreen then child-specific views. Each dashboard loads role-specific data from backend.
4. School & Branches Module
Backend (Laravel)
SchoolUpdateController: getSchoolInfo, updateSchool (school-admin). SchoolBranchController: getBranches, createBranch, updateBranch, deleteBranch, toggleStatus. HandlesRoleBasedAccess trait scopes by school_id / branch_id. Tables: schools, school_branches.
Web Frontend (React)
My School: DynamicPageRenderer pageType "my-school". Branches: DynamicPageRenderer "branches" list; BranchDetail for /branches/:id. API calls to /school, /branches.*
Mobile (Flutter)
School/branch management is admin-only and primarily on web. Mobile focuses on student/teacher/parent flows (subjects, lectures, reports); no dedicated branch CRUD screens.
5. Academic Module (Grades, Grade Sections, Subjects)
Backend (Laravel)
GradeController: CRUD grades; scoped by school/branch. GradeSectionController: CRUD grade-sections; getSectionsByGrade, getAssignedSubjects. SubjectController: CRUD subjects; createUnassigned; getAssignedTeachers (EventController). Tables: grades, grade_sections, subject_grade_sections, subjects, teacher_subject_assignments.
Web Frontend (React)
Grades.jsx, GradeDetail.jsx, Classes.jsx, GradeSectionDetail.jsx; Subjects.jsx, SubjectDetail.jsx. DynamicPageRenderer for grades, grade-sections, subjects. Routes: /grades, /grades/:id, /grade-sections/:id, /subjects, /subjects/:id.
Mobile (Flutter)
Student: SubjectsScreen (SubjectsProvider, student/subjects/all), SubjectDetailScreen (SubjectDetailProvider, student/subject/{id}). Teacher: TeacherSubjectsScreen, TeacherSubjectDetailScreen (TeacherSubjectsProvider, TeacherSubjectDetailProvider). Data feeds into lecture and assessment flows.
6. People Module (Employees, Teachers, Students, Guardians)
Backend (Laravel)
EmployeeController, TeacherController, StudentController, GuardianController. CRUD + toggle-status for each. Teachers: assignSubject, unassignSubject; mobile: my-class-students, mobile-main-new, lectures/all. Students: mobile-main-new, subjects/all, subject/{id}, lecturesby/{subject_id}, lecture-student/{lecture_id}, assessments, report, learning-report, parents; student-data, get-lectures, mobile-report. Guardians: linked via guardian_student. Tables: employees, teachers, students, guardians, guardian_student, teacher_subject_assignments, teacher_grade_sections.
Web Frontend (React)
Employees, Teachers, TeacherDetail, Students, StudentDetail, Guardians, GuardianDetail via DynamicPageRenderer or dedicated components. Routes: /employees, /teachers, /teachers/:id, /students, /students/:id, /guardians, /guardians/:id.
Mobile (Flutter)
Student: MainScreen uses student/mobile-main-new; SubjectsScreen uses student/subjects/all; SubjectDetail, Lecture, Reports, StudentLearningReportScreen use student/* endpoints. Teacher: TeacherMainProvider uses teacher/mobile-main-new; teacher/lectures/all. Parent: ChildrenScreen (students-parents-by-auth); ParentStudentSelectionScreen; ParentLearningReportScreen (student learning report for selected child).
7. Lectures & Content Module (AI-enhanced)
Lectures are enhanced by AI Read More (on-demand explanations) and AI Topic Understanding (self-check MCQs). Tracking feeds the AI learning analytics pipeline.
Backend (Laravel)
LectureController: CRUD lectures; GET /lecture/serve-audio/{path} (public) for media. ReadMoreController: getLevels, resetLevel; readMore, readMoreWithImage, readMoreWithVideo (AI). LectureTrackingController: trackProgress, trackTopicEngagement, submitTopicQuiz, submitLectureQuiz, trackReadMoreUsage; getLectureProgress, getTopicEngagement, getTopicQuizAttempts, getLectureAnalytics. TopicUnderstandingController: generateMcqs, submitAttempt. Tables: lectures, lecture_topics, lecture_topic_quizzes, student_lecture_progress, student_lecture_topic_engagement, student_lecture_topic_quiz_attempts, student_lecture_quiz_attempts, student_read_more_usage, read_more_contents, student_topic_understanding_attempts.
Web Frontend (React)
Lectures.jsx list; LectureDetail.jsx (admin); RoleBasedLectureDetail.jsx for student view with StudentVideoPlayer, StudentQuizModal, StudentReadMoreSection, StudentTopicList. Fetches /lectures, /lectures/:id; tracking and read-more via API.
Mobile (Flutter)
LectureScreen (LectureProvider): getLectureForStudent, track progress, topic engagement, quizzes. LecturePlayer, LectureTranscript, ReadMoreModal, QuizModal. TopicLearningScreen for topic understanding flow. Teacher: TeacherLectureCreateScreen (TeacherLectureCreateProvider), TeacherLecturesScreen. Media played via video_player/audioplayers; serve-audio URL for backend media.
8. Assessments Module
Assessment results feed directly into the AI learning analytics engine—trends, weak areas, and repeated mistakes—so student growth is measurable and reports stay data-driven.
Backend (Laravel)
AssessmentController: getAssessments, getMyAssessments, show; createAssessment, toggleStatus, destroy; startAssessment, submitAnswer, submitAssessment; getSubmission, getAssessmentSubmissions. Tables: assessments, assessment_questions, assessment_status, student_assessments.
Web Frontend (React)
Assessments.jsx, AssessmentDetail.jsx; StudentAssessmentSection for student attempt flow. Routes: /assessments, /assessments/:id.
Mobile (Flutter)
AssessmentsProvider, QuizProvider; QuizScreen, AttemptQuizScreen (shared). Start assessment via POST .../start; submit answers via submit-answer; final submit via submit. ResultScreen for results.
9. Learning Analytics & Reports Module AI‑powered
The Learning Analytics & Reports module is the AI-driven intelligence layer of NewtonEd. It turns raw learning behavior and assessment data into actionable insights for students, instructors, parents, and the institution. The goal is to evaluate topic-level understanding, surface learning gaps through AI analysis, and deliver tailored feedback so every stakeholder can support improvement. AI is central to topic mastery, weak-area detection, and personalized report generation across the platform.
What the System Tracks (Signals)
Before any report is generated, the platform continuously collects learning signals from student activity. These include: how long and how completely a student watches lectures; which topics they complete or skip; time spent per lecture and per topic; when and how often they attempt assessments and assignments; and question-level performance (right/wrong, repeated mistakes). Lecture progress, topic engagement, quiz attempts (topic and lecture-level), and use of “Read More” explanations are also tracked. This behavioral dataset is the foundation for all analytics and AI-generated reports.
Pillars of Learning Analytics
- Topic mastery How well the student has understood each topic, derived from quiz results, completion, engagement, and Read More usage.
- Weak areas Topics or sections where the student consistently struggles; can be detected automatically from performance and behavior (e.g. high drop-off, repeated mistakes on the same concept).
- Question-level performance Which questions are answered correctly or incorrectly, and patterns across attempts.
- Repeated mistakes Same type of error across attempts, helping identify persistent misconceptions.
- Assessment trends Whether performance over time is improving, stable, or declining; assessment summary per student.
- Retention indicators Signals that suggest how well knowledge is retained over time.
- Learning context Aggregated context (e.g. subjects, topics, recent activity) used to personalize reports and recommendations.
Learning Report Variants (By Audience)
The same underlying analytics power different report variants so each audience gets the right level of detail and wording. The student variant focuses on self-improvement: which topics to focus on, strengths to build on, and clear next steps. The instructor variant supports teaching and intervention: topic understanding per student, weak areas, and class-level patterns for targeted support. The parent variant is written in plain language: overall progress, strengths and weak areas, engagement and consistency, assessment trends, and simple recommendations (e.g. “Focus on X at home,” “Consider discussing Y with the teacher”). An institution-level report aggregates learning analytics across the school for academic monitoring and strategic reporting.
Student Intelligence (IQ Metrics)
Beyond behavioral analytics, the system can compute intelligence-style metrics per student: overall and per-subject indicators that summarize capability and progress. These support subject IQ, IQ comparison (e.g. across subjects or over time), and class intelligence overview for instructors. Intelligence reports feed into the same learning report and performance views, giving a rounded picture of both “how they learn” and “how they perform.”
Parent Voice Chat with AI
Parents can talk to an AI assistant that knows only their selected child. They ask questions in natural language (e.g. “How is my child doing in math?” or “What are their weak topics?”) and receive spoken or text answers. The flow is: parent selects a student in the app, opens voice chat, speaks or types a question; the system sends the question with the selected student’s context to the backend; the AI uses learning analytics (topic mastery, weak areas, trends) to generate an answer; the answer is returned and optionally spoken back; the conversation can be stored so parents can review history. This gives hands-free, quick access to learning insights without navigating multiple screens.
End-to-End Flow (No Code)
Data flows from student actions (watch lecture, complete topic, take quiz, use Read More, submit assessment) into the backend, where progress, engagement, and results are stored. When a student, teacher, or parent requests a learning report, the system loads the relevant analytics (topic mastery, weak areas, trends, context), applies the correct variant (student / instructor / parent), and returns a structured report. The web app shows learning and performance reports for admins and teachers; the mobile app shows the student their own report, teachers see student and class reports, and parents see their child’s report and can use voice chat for on-demand questions. Institution reports aggregate data across students and branches for leadership.
Benefits by Role
Learning report request flow
Parent voice chat flow
10. Events & Attendance Module
Backend (Laravel)
EventController: CRUD events; getAssignedTeachers for subjects. AttendanceController: getMonthly (POST), storeBulk (POST), show (student), getReport (POST). Tables: events, attendances.
Web Frontend (React)
Events.jsx via DynamicPageRenderer (events). Dashboard calendar shows events. AttendanceReport.jsx uses attendance API.
Mobile (Flutter)
Calendar widget on student main; events may be shown in dashboard data. Attendance managed primarily on web (admin/teacher).
Remaining Modules Enterprise-Level Documentation
The following modules are integral to the NewtonEd platform: purpose, responsibilities, how it operates across backend, web, and mobile, benefits, and high-level flow. These modules support governance, operations, content delivery, and compliance.
Profile Module
Purpose: Allows every authenticated user to view and update their own profile (name, email, avatar, and other account details) in one place, ensuring data accuracy and a consistent identity across the platform.
Responsibilities: The backend stores and returns the current user’s profile and accepts updates with validation. The web app exposes a dedicated profile page inside the protected area; the mobile app exposes profile screens for both students and teachers, each scoped to the logged-in user.
Flow & benefits: User opens profile on web or mobile; the client requests the current user’s profile from the backend; the user may edit and submit changes; the backend validates and persists updates. Benefits: single source of truth for identity, reduced support burden, and better UX through self-service profile management.
Departments Module
Purpose: Models the organizational structure of the school or branch (e.g. Academic, Administration, Sports). Departments are used to group designations and employees and to align roles with the institution’s hierarchy.
Responsibilities: The backend provides full lifecycle management for departments, scoped by school or branch so that school-level and branch-level admins see and manage only their scope. The web app offers a departments management view (list, create, edit, deactivate) for admins. The mobile app does not expose department management; it is an admin-only, web-centric capability.
Flow & benefits: Admin navigates to departments on the web, views the list filtered by context, and creates or updates departments. Benefits: clear org structure, correct scoping for multi-tenant and multi-branch setups, and a foundation for designations and employee assignment.
Designations Module
Purpose: Defines job titles or roles within the organization (e.g. Head of Department, Subject Teacher). Designations are linked to departments and used when creating or managing employees and teachers.
Responsibilities: The backend manages designations with optional filtering by department so that admins can maintain a consistent job structure per department. The web app provides a designations management screen for admins. Mobile does not manage designations; this is an enterprise admin function on the web.
Flow & benefits: Admin creates or edits designations, optionally tying them to a department. When adding employees or teachers, the admin selects from these designations. Benefits: standardized job titles, better reporting and hierarchy, and alignment with HR and payroll practices.
Custom Roles Module
Purpose: Enables schools to define their own roles with fine-grained, module-level permissions (e.g. who can manage branches, grades, or assessments). This extends the built-in role set (school-admin, teacher, student, parent) with institution-specific access control.
Responsibilities: The backend maintains a list of modules and permissions and allows creating and updating custom roles with selected permissions. The web app provides a roles management interface where admins configure these roles. Mobile does not configure roles; it respects the permissions enforced by the backend for the authenticated user’s role.
Flow & benefits: Admin defines a new role or edits an existing one and checks which modules (e.g. branches, students, assessments) that role can access. When users are assigned these roles, the backend restricts actions accordingly. Benefits: compliance with school policies, principle of least privilege, and flexible governance without code changes.
Employees Module
Purpose: Represents all staff employed by the school or branch (including non-teaching staff). Employees can be linked to user accounts and to designations and departments; teachers are a subset of employees with additional teaching-specific data.
Responsibilities: The backend supports full CRUD and status toggling for employees, scoped by school or branch. The web app provides an employees list and forms for create and update. The mobile app does not manage employees; teachers and students use mobile for teaching and learning, not HR administration.
Flow & benefits: Admin adds or edits employees, assigns department and designation, and can activate or deactivate records. Benefits: a single roster for all staff, support for payroll and compliance, and a clear link between employees and teacher accounts where applicable.
Student Intelligence (IQ Metrics) Module
Purpose: Provides summarized “intelligence” or capability metrics per student—overall and per subject—to support comparisons, class overviews, and richer learning reports. These metrics complement behavioral learning analytics with performance-based indicators.
Responsibilities: The backend computes and stores intelligence metrics, exposes subject-level IQ, IQ comparison, and class-level overviews, and can generate intelligence reports. The web app consumes these for student detail and performance or learning reports. The mobile app surfaces the same data in student and teacher report screens so that students see their own metrics and teachers see class and student-level intelligence.
Flow & benefits: As assessments and learning activity are completed, the system can recalculate metrics. When a report or dashboard is requested, the backend returns the relevant intelligence data. Benefits: at-a-glance understanding of student capability, support for placement and intervention decisions, and consistent data for reports across web and mobile.
Read More (AI) Module
Purpose: Delivers on-demand, AI-generated explanations at different depth levels (e.g. simple, detailed) for lecture content. Students can request “read more” for text, images, or video segments to deepen understanding without leaving the learning flow.
Responsibilities: The backend manages explanation levels, calls the AI service to generate or retrieve explanations, and stores or caches read-more content. The web app shows a “Read More” section in the role-based lecture detail so students can request and view explanations. The mobile app provides a read-more modal or in-lecture panel and records usage for learning analytics.
Flow & benefits: Student selects a segment (text, image, or video) and requests a deeper explanation; the client sends the context to the backend; the backend returns AI-generated content; usage is recorded for analytics. Benefits: personalized scaffolding, better comprehension, and signals for weak-area detection in learning analytics.
Lecture Tracking Module
Purpose: Captures how each student interacts with lectures and topics: watch progress, topic-level engagement, topic and lecture quiz attempts, and use of Read More. This data is the primary input for learning analytics and progress dashboards.
Responsibilities: The backend receives progress and engagement events, stores them, and exposes progress and analytics for a lecture or topic. The web app sends tracking events when students use the lecture view and can display progress. The mobile app does the same during lecture playback and quiz attempts, and uses progress data to show completion and analytics.
Flow & benefits: As the student watches, completes topics, takes quizzes, or uses Read More, the client sends tracking events to the backend. Teachers and students can later view progress and analytics. Benefits: accurate learning signals, resumable progress, and data-driven reports and recommendations.
Topic Understanding Module
Purpose: Supports a “Do you understand?” flow by generating AI-driven multiple-choice questions for a topic and recording the student’s attempt. It enables teacher-less, self-check understanding and feeds into topic-level analytics.
Responsibilities: The backend generates MCQs for a given topic via the AI service and records attempt results. The web app may expose this in lecture or topic context where applicable. The mobile app has a dedicated topic-learning screen where students request MCQs, answer them, and submit; results are stored and can inform weak-area and topic-mastery analytics.
Flow & benefits: Student finishes a topic and requests a short quiz; the backend generates questions and returns them; the student answers and submits; the backend records the attempt and updates analytics. Benefits: immediate feedback, low dependency on teacher availability, and richer topic-level data for reports.
Timetable Module
Purpose: Stores and manages the institution’s timetable (e.g. class periods, subject slots). Admins can update the timetable and reset it to a default when needed, ensuring consistency across the academic calendar.
Responsibilities: The backend persists timetable data and exposes operations to update or reset the timetable. The web app provides an admin interface to view and edit the timetable. The mobile app does not manage timetables; students and teachers may see timetable-derived information (e.g. in dashboard or schedule views) that is supplied by the backend.
Flow & benefits: Admin opens the timetable on the web, makes changes or resets to default, and saves. The rest of the system can use the timetable for display or planning. Benefits: a single source of truth for schedule, support for curriculum planning, and consistent experience across the platform.
Activity Logs Module
Purpose: Maintains an audit trail of important user actions (e.g. login, data changes, access to sensitive resources). It supports compliance, security reviews, and troubleshooting.
Responsibilities: The backend records events from various controllers (e.g. login, CRUD on key entities) and exposes filtered views of activity logs (e.g. by user, by school, or all). The web app provides an activity logs view for admins to search and review. The mobile app does not manage or display raw activity logs; auditing is an admin, web-centric function.
Flow & benefits: When a user performs an action, the backend appends a log entry. Admins open the activity logs on the web and filter by date, user, or action. Benefits: accountability, forensic support, and meeting audit and compliance requirements.
Groq Voice Module
Purpose: Processes voice commands or voice input using an external AI (Groq) so that users can interact with the platform by speaking (e.g. ask questions, trigger actions). It powers voice-driven features such as the chatbot or assistant on mobile and, where integrated, on the web.
Responsibilities: The backend receives voice or transcribed input, sends it to the Groq service, and returns the AI response to the client. The web app may use this for any voice-assistant UI. The mobile app uses it in the chatbot and text-to-speech or voice-assistant screens to provide a hands-free, accessible experience.
Flow & benefits: User speaks or sends a voice message; the client sends the payload to the backend; the backend calls Groq and returns the result; the client displays or speaks the response. Benefits: accessibility, convenience for on-the-go users, and a modern, voice-first interaction layer.
File Upload Module
Purpose: Handles secure upload of files (e.g. lecture media, images, documents) to the backend, with storage on local disk or cloud (e.g. AWS S3), so that content can be attached to lectures, assessments, or other entities.
Responsibilities: The backend accepts multipart uploads, validates file type and size, stores files on the configured disk, and returns references (paths or URLs) for use in the application. The web app uses upload when creating or editing lectures and other content. The mobile app uses it when teachers create or update lectures (e.g. picking files or images from the device).
Flow & benefits: User selects a file in the web or mobile client; the client sends the file to the backend; the backend validates, stores, and returns a reference; the client saves that reference with the lecture or entity. Benefits: centralized, secure storage; scalability via S3; and consistent upload behavior across web and mobile.
Note: Parent Voice Chat is documented in full under Section 9 Learning Analytics & Reports, as it is part of the parent-facing analytics and AI assistant experience.