Architecture & methodology
Designed to be explained in a viva.
Clear layers, a normalised schema, a provable formula and an honest ML component.
System layers
Layer 1
Browser
Responsive UI, forms, charts
Layer 2
Application
Auth, validation, routes, business rules
Layer 3
ORM
Typed models and queries
Layer 4
Database
Relational records
Layer 5
ML pipeline
Train, evaluate, version, predict
The browser never directly accesses the database or model files.
Database design
users
id, name, email (unique), password_hash, role, created_at
attendance
id, student_id → users, subject, classes_held, classes_attended
marks
id, student_id → users, subject, assessment_type, score, max_score
complaints
id, student_id → users, category, description, status, timestamps
predictions
id, student_id → users, risk_level, model_version, created_at
Attendance algorithm
With A attended, T held and target fraction p, the minimum additional consecutive attended classes is:
If T = 0 the app shows “No classes conducted yet” instead of dividing by zero.
Risk methodology
- • Features: attendance %, prior assessment %, assignment completion.
- • Split by student and chronologically to prevent data leakage.
- • Compare baseline, Decision Tree and Random Forest using precision, recall, F1 and confusion matrix.
- • Demo uses synthetic data; outputs are support signals, never final decisions.
Test plan
| ID | Scenario | Expected |
|---|---|---|
| T01 | Valid student login | Student dashboard opens |
| T02 | Student requests another student's records | Access denied |
| T03 | A=30, T=40, target 80% | 10 future classes required |
| T04 | T=0 | Helpful message, no division by zero |
| T05 | Student creates complaint | Stored with status Open |
| T06 | Admin updates status | Owner sees new status |
| T07 | Mark above maximum | Validation rejects entry |
| T08 | Model evaluation | Metrics generated and saved |