1. Introduction, Scope, and Architectural Philosophy
Monarkh is operated by INJENA GROUP FZE LLC, holding Sharjah Publishing City Free Zone Licence No. 4431251.01 (hereinafter referred to as “the Company,” “we,” or “our”). The Company has engineered the Monarkh Suite™ (hereinafter referred to as “the Service”) to function as an advanced, privacy-first Communication Enhancement Layer, deliberately distinguishing itself from traditional Student Information Systems (SIS). The Service is designed to bridge the gap between institutional educational systems and familial communication channels without unnecessarily centralizing sensitive student data. Recognizing the inherent vulnerabilities in legacy platforms that aggregate extensive dossiers of minor data, the Company has architected the Service upon a foundational “On-Device-First Privacy” cryptographic framework.
This Privacy Policy constitutes a legally binding disclosure detailing the exact mechanisms by which data is collected, processed, segregated, encrypted, and retained across both enterprise and consumer deployments. This document has been drafted to align with the stringent regulatory requirements of the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), the United Arab Emirates Federal Decree-Law No. 45 of 2021 on Personal Data Protection, and the UAE Child Digital Safety Law No. 26 of 2025. This policy applies universally to all participating educational institutions, school districts, educators, parents, legal guardians, and students interacting with the Service across all supported global jurisdictions.
2. Lexicon of Defined Terms
To ensure absolute clarity regarding the technical and legal parameters of the Company’s data processing activities, the following terminology is utilized throughout this Privacy Policy and the subsequent Terms of Service.
3. Data Collection Mechanisms and the On-Device-First Privacy Model
The Company’s data collection practices are strictly bifurcated between data stored locally on the User’s end-device and data transmitted to the Company’s cloud infrastructure. This bifurcation is the cornerstone of the on-device-first privacy model, ensuring that the Company never possesses the cryptographic material necessary to reconstruct a student’s identity.
3.1. Local Device Storage and the On-Device Privacy Filter
Upon the initiation of the Service, a parent or legal guardian connects their external communication account (e.g., Google Gmail, Microsoft Outlook) via standard OAuth 2.0 protocols. The Service requests the minimum necessary scopes to access incoming messages. Crucially, the parsing of these messages occurs on the client side, directly on the User’s mobile device or local machine.
The native application deploys an “On-Device Privacy Filter,” an advanced local algorithm that scans incoming text to identify direct identifiers, including real student names, physical addresses, and unencrypted contact details. Before an email leaves your phone, the app replaces your children’s names with tags, and only your phone can turn those tags back into names. The Company fundamentally lacks the technical capacity to access, mirror, or extract the contents of these local keystores, thereby ensuring that the most sensitive PII remains inaccessible to the Company’s remote servers and any potential threat actors targeting the cloud infrastructure.
3.2. How our servers process your data
After that step, the app sends the email to the Company’s cloud servers, which process it and store it in relational and vector databases.
The transmission utilizes Transport Layer Security (TLS 1.3) to protect the data in transit. The cloud servers receive the User’s own registered children’s names as codes that only the User’s device can turn back into names; other names are hidden on the servers only in school mail, in mail from senders the User marks “child-sensitive”, and in uploads the User marks “Child-sensitive”.
After each automatic mail check (when the app opens, on its timer, or in the background, but not when you pull to refresh), the app tells us how it went: what started it, how it ended, how many emails it found and sent, the time, the app’s version, your phone’s system, and a random code for this install. It is linked to your account, kept only as one line in our server logs, and never includes anything about any email: no sender, subject, address, content or name.
3.3. Pocket and Tier 2 Data Processing
In addition to automated communication ingestion, the Service features a “Pocket,” an encrypted repository allowing parents, legal guardians, and educators to manually upload Tier 2 educational materials. These materials may encompass individualized education programs (IEPs), pedagogical assessments, permission slips, and multimedia assignments.
Because the Company must host these files to facilitate collaborative sharing, Tier 2 Data is stored within secure cloud buckets (e.g., Amazon S3 or Google Cloud Storage) and is encrypted at rest using AES-256 server-side encryption. However, the visibility and distribution of Tier 2 Data are governed by strict, user-controlled toggle protocols. Users choose who can see each file: “Private” (only the account that uploaded it), “Everyone” (everyone in the family) or “Custom” (the family members the user picks). The Company asserts no ownership over this User-Generated Content and processes it strictly as a neutral hosting provider.
4. Artificial Intelligence Processing and Large Language Model Integrations
The Service heavily integrates a proprietary in-app Artificial Intelligence assistant to extract temporal calendar events, summarize extensive pedagogical communications, and provide an interactive chatbot interface for organizational queries. The deployment of AI within an educational technology framework requires profound privacy safeguards, particularly concerning the handling of sensitive communications.
4.1. Asynchronous Ingestion and Vectorization
AI processing within the Service occurs during an asynchronous ingestion phase.
4.2. Third-Party LLM APIs and No-Training Commitments
To power the natural language processing capabilities of the in-app AI assistant, the Company transmits pseudonymized, privacy-filtered prompts to third-party Large Language Model (LLM) Application Programming Interfaces (APIs). Current providers include Google (Gemini). The current list of AI subprocessors is maintained on our Subprocessor Disclosure page.
The Company is in the process of executing Data Processing Agreements (DPAs) with each AI subprocessor to contractually enforce zero data retention and prohibitions on training. Until DPAs are fully executed, the Company relies on the providers’ standard API terms, which include opt-out mechanisms for model training. The Company uses Google Vertex AI for AI processing: on Google’s EU endpoint for the app, and on Google’s global endpoint for the children’s portal chat. The status of each subprocessor’s DPA is disclosed on our Subprocessor Disclosure page.
4.3. Pedagogical Guardrails and Ethical AI Deployment
The Company recognizes the risk of AI platforms inadvertently facilitating academic dishonesty. Consequently, the student-facing iteration of the in-app AI assistant is hard-coded with a strict “Guide, Don’t Answer” pedagogical protocol. Utilizing advanced system prompts and output filtering mechanisms, the AI is engineered to provide Socratic questioning, study frameworks, and conceptual explanations, but is explicitly restricted from generating completed essays, solving mathematical equations directly, or providing direct answers to academic assessments. This approach ensures that the Service functions as a supplemental tutoring aid rather than a mechanism for academic bypass.
5. Data Segregation
A critical vulnerability in legacy educational platforms is the risk of cross-contamination, wherein a parent inadvertently gains access to the records of another student, or siblings access each other’s distinct educational communications.
The Service applies layered access controls designed to restrict data access based on verified relationships.
- Profile References: an internal identifier for each account, which the access checks use to match data to the people allowed to see it.
This segregation is designed to prevent unauthorized horizontal data leakage between siblings or unrelated users within the same educational institution.
6. Children’s Privacy
The Company considers the privacy of minors to be of paramount importance and subjects the Service to the most stringent international regulatory frameworks governing children’s data. The compliance posture adapts dynamically based on whether the Service is deployed via enterprise institutional channels or individual consumer acquisition.
6.1. B2B Enterprise School Integration
When the Service is deployed via direct contract with an educational institution or school district (the B2B track), the Company operates exclusively in the capacity of a “School Official” possessing legitimate educational interests under the Family Educational Rights and Privacy Act (FERPA).
In this enterprise context, the educational institution maintains ultimate ownership, control, and governance over the educational records. The Company merely acts as a data processor executing instructions on behalf of the institution. The Company explicitly warrants that it shall not utilize any student data, whether raw or pseudonymized, for behavioral targeting, profiling, or advertising purposes under any circumstances. The institution remains responsible for obtaining any necessary parental consents required by local jurisdictions prior to provisioning student accounts.
6.2. Parents Who Sign Up Directly
When the Service is adopted directly by a parent or legal guardian independent of a school contract (the B2C track), the Company assumes the role of the data controller.
7. Global Regulatory Compliance: UAE, GDPR, and CCPA
The Company operates a globally distributed infrastructure and is committed to upholding the specific statutory rights granted to users across diverse legislative frameworks.
7.1. United Arab Emirates Personal Data Protection Law (Law 45 of 2021)
For operations and users situated within the United Arab Emirates, the Company strictly adheres to the UAE Federal Decree-Law No. 45 of 2021 regarding the Protection of Personal Data (PDPL). The Company upholds the fundamental rights of UAE Data Subjects, including the right to request the correction of inaccurate data, the right to restrict processing, and the right to demand the cessation of processing, particularly concerning direct marketing or profiling.
In compliance with Article 5 of the PDPL, all data processing is conducted fairly, transparently, and lawfully, supported by the explicit consent of the data owner or established legitimate interests. Should a verified data subject request the cessation of processing, the Company’s architecture ensures the immediate deletion of the pseudonymized cloud data, effectively rendering any localized residual data isolated and inaccessible.
7.2. UAE Child Digital Safety Law (Law 26 of 2025)
The Company is committed to meeting its obligations under the UAE Federal Decree-Law No. 26 of 2025 regarding Child Digital Safety, which establishes a comprehensive framework to protect minors in the digital environment. Pursuant to this law:
- Commercial Prohibitions: The Company strictly prohibits the use of children’s data for commercial purposes, targeted electronic advertising, or any form of behavioral profiling.
- Commercial Gaming Ban: The Service inherently blocks all access to online commercial gaming, betting, or wagering functionalities, ensuring the environment remains strictly pedagogical.
- Parental Controls: Custodians and legal guardians are provided with comprehensive, user-friendly tools to actively monitor, supervise, and restrict the digital content accessible by their children.
- Harmful Content: The Company is committed to complying with all applicable laws regarding harmful content. The Company will cooperate with competent authorities in accordance with applicable law.
7.3. GDPR (European Union) and CCPA (California)
For users within the European Economic Area (EEA) and the United Kingdom, the Company complies with the General Data Protection Regulation (GDPR), relying on user consent and the performance of a contract as the primary legal bases for processing. The on-device-first architecture explicitly fulfills the GDPR Article 25 mandate for “Data Protection by Design and by Default.” For users in California, the Company complies with the CCPA, explicitly affirming that the Company does not “sell” or “share” personal information for cross-context behavioral advertising.
8. Sub-processors and Third-Party Data Sharing
The Company operates under a strict paradigm of data minimization and operational necessity. We do not rent, trade, sell, or otherwise distribute User information to any third parties for marketing or advertising purposes.
8.1. Authorized Infrastructure Providers
To deliver the Service, the Company engages third-party service providers (Sub-processors) to facilitate critical infrastructure components. The current list of Sub-processors, including purpose, data shared, hosting region, and DPA status, is maintained on our Subprocessor Disclosure page.
The Company is in the process of executing Data Processing Agreements (DPAs) with each active Sub-processor. The DPA status for each provider is disclosed on the Subprocessor Disclosure page and updated as agreements are executed.
8.2. Compelled Legal Disclosures
The Company reserves the right to disclose pseudonymized backend data or localized metadata if legally compelled to do so by a court of competent jurisdiction, a valid subpoena, or a binding administrative order. In such events, the Company will, to the extent legally permissible, provide the User with prior written notice of the request to allow the User an opportunity to seek a protective order or quash the subpoena.
Where student names have been pseudonymized by the on-device privacy filter, the identity mapping required to re-personalize them is encrypted with keys held on the User’s device, and the Company cannot reverse that mapping from its servers alone. Cloud-stored records containing personal data remain subject to production where the Company is legally compelled to disclose them, as described above.
9. Data Retention and Deletion: The Automated Data Lifecycle Protocol
The Company rejects the industry practice of indefinite data retention. Instead, the Service implements a highly structured, automated data lifecycle management system designated as the “automated data lifecycle” protocol, ensuring strict adherence to the principles of data minimization and storage limitation.
9.1. Automated Archiving and Cascading Sweeps
The automated data lifecycle protocol monitors the temporal relevance of ingested communication vectors. When an academic term concludes, or when a specific data payload (such as a summarized calendar event) exceeds its operational utility timeframe, the protocol transitions records to an archived status. Archived records are excluded from active queries and search results. The Company retains archived pseudonymized data for the duration of the User’s account. Upon account deletion, all associated data is removed in accordance with the deletion process described in Section 9.2.
9.2. Account Deletion and the Right to Erasure
Users retain the absolute right to terminate their accounts and request deletion of associated data at any time. Upon receiving a verified deletion request, the Company initiates removal of the User’s account data, pseudonymized profile references, and associated records across all storage layers. The Company is actively remediating its deletion cascade to ensure complete coverage across all storage systems, including relational databases, vector databases, and caching layers. An updated deletion SLA will be published once the remediation is verified.
For users situated in the European Union and California, this mechanism supports the statutory “Right to be Forgotten” and “Right to Deletion.” The Company emphasizes that while deleting the cloud-based account removes cloud-stored data, the User must manually delete the native application from their physical device to remove the localized Apple Keychain or Android Keystore data. The Company cannot remotely access a User’s local hardware enclave.