CHAPTER 2: JUSTIFICATION AND SELECTION OF TECHNICAL ARCHITECTURE
2.1 The Technological Dilemma: Algorithmic Determinism (DAG) vs. Probabilistic Models (LLMs)
The deployment of artificial intelligence technologies in school settings requires balancing system adaptability with students’ cognitive safety. Given the emergence of free-generation large language models (LLMs), this research makes the deliberate and reasoned choice of a hybrid deterministic architecture driven by a Directed Acyclic Graph (DAG).
A. Eradicating the Risk of Hallucination and Semantic Drift
LLMs are structurally probabilistic prediction engines. Due to this nature, they are prone to mathematical hallucinations and are incapable of strictly guaranteeing adherence to long-term scaffolding instructions. In the context of a Socratic dialogue intended for 12–13-year-old students, the agent cannot afford any approximation. The DAG engine (Module 2) ensures that each transition node corresponds to a logical state validated by the teacher, eliminating any risk of conversational drift or accidental disclosure of the solution. Furthermore, using a DAG (rather than a monolithic tree) resolves the problem of combinatorial explosion by enabling the reuse of common feedback nodes (e.g., unit errors or perimeter/area confusion).
B. Experimental Standardization and Internal Validity of Evidence
From a quantitative research methodology standpoint, validating the efficacy of the Maher agent requires strict control of independent variables. If the agent relied on an unconstrained LLM, two students exhibiting the exact same micro-error would receive different phrasing for their hints. Such variability would introduce a major confounding bias, invalidating any attempt at interindividual statistical comparison. The DAG formalism standardizes scaffolding trajectories (Focus, Decomposition, Metacognitive Anchor), ensuring that performance variations measured at the end of the experiment result exclusively from the students’ learning dynamics.
2.2 Justification of the Backend Ingestion Pipeline and Content Industrialization (Human-in-the-Loop)
The promise of genericity in the Maher agent rests on its ability to process any textbook from the official curriculum. To achieve this, the architecture deploys a Dual-Engine Multimodal Ingestion Pipeline at the centralized VPS server level (Python 3.11 / FastAPI).
[Textbook PDF] ──> [Llama-Vision / LayoutLM] ──> [Visual-to-Code Pipeline] ──> [OpenCV/SymPy Verifier] ──> [Teacher Validation]
The combined use of vision models (Llama-3.2-Vision / Claude 3.5 Sonnet) and layout analysis models (LayoutLM) addresses the need to automate textbook chunking without loss of information. To immunize the system against vision biases regarding geometric figures and tables, the architecture translates these graphical elements into absolute vector scripts (GeoGebra, TikZ, or pure JSON structures).
The choice to integrate a deterministic Geometric Verifier (OpenCV / SymPy) prior to human validation is an essential mathematical safety barrier. Before submitting the content to the teacher, the system checks the consistency of geometric properties (e.g., validation of trigonometric or algebraic relationships on extracted figures). This Human-in-the-Loop approach culminates in a Design Freeze on the teacher dashboard, ensuring that no untimely modifications corrupt the lightweight JSON package (under $500\text{ KB}$) sent to the tablets.
2.3 Choice of Front-End Framework and Tactile Assessment Ergonomics
A. Hardware Agnosticism via Flutter
Moving toward empirical deployment requires an environment that guarantees system portability. The open-source Flutter framework (Dart) was chosen to structure the tablet mobile application (Module 3). This decision responds to the heterogeneity of school computer fleets (the coexistence of Apple iPads and entry-level Android tablets). Flutter compiles source code directly into native machine instructions, ensuring that the interface and tactile response times (strictly under $50\text{ ms}$) remain identical across all terminal fleets.
B. “Tap-to-Target” Ergonomics and Reduction of Extraneous Load
To comply with Cognitive Load Theory (Sweller) requirements, the user interface radically bans virtual keyboard entry as well as complex drag-and-drop interactions. On resource-constrained tablets ($2\text{ GB}$ of RAM) equipped with low-cost touch screens, drag-and-drop generates frustrating pointing errors that extraneously overload the student’s working memory. The Tap-to-Target paradigm (Tap-to-Select, followed by Tap-to-Place), supported by minimal target zones of $48 \times 48\text{ px}$, converts interaction into robust sequential selections, maximizing accessibility for students with Dys or ADHD disorders.
C. Quantifying Creativity in a Finite Environment
To evaluate divergent creative thinking (Guilford/Torrance) without introducing free text entry (which is complex to analyze locally offline), the interface implements a combinatorial micro-manipulative canvas. The architecture captures:
- Fluency by counting distinct valid configurations generated.
- Flexibility by detecting method category shifts within the JSON matrices of possible solutions.
- Originality by real-time algorithmic calculation of the statistical rarity of the student’s configuration against all recorded possible answers.
2.4 Logistical Resilience and Sovereignty: The Encrypted Offline-First Architecture
A. Fleet Rotation Logistics (4:1 Ratio)
Facing the critical field constraint (10 tablets for 40 students), the software architecture incorporates a rotation wave orchestration module (Module 4). To avoid cutting into useful instructional time, session access is achieved in under a second via the native integration of Flutter camera/NFC modules to scan pseudonymized QR Code/NFC badges. Granular state saving within the local database allows the session progress to be frozen instantly to the millisecond during wave transitions (every 12 minutes), initiating a 30-second warm-up (reactivation) phase upon the student’s return to preserve working memory.
B. Security by Design, SQLCipher, and xAPI Telemetry
The telemetry protocol adopts the xAPI (Experience API) standard under IEEE 9274.1.1. Every tactile interaction, latency period, or help request is transcribed as a standardized Actor-Verb-Object triplet and stored locally.
To guarantee absolute data segregation and comply with GDPR requirements regarding minors’ data, the application operates on an Offline-First principle. Local physical storage is fully locked down by the SQLCipher extension with AES-256 bit encryption at rest. Student identifiers undergo salted hashing (salted SHA-256 hash) right at the source. The centralized VPS server (KVM 2) serves solely as an asynchronous receptacle at the end of the day for synchronizing encrypted event logs, ensuring total impermeability to school internet connectivity failures.