Privacy policy

1. Comprehensive Introduction, Scope of Application, and Operational Definitions

Welcome to the Unim digital platform, an integrated ecosystem specifically engineered to optimize, streamline, facilitate, and coordinate campus service interactions, food ordering management, and logistical workflows. This expansive, multi-tiered Privacy Policy serves as our absolute baseline declaration regarding the collection, transmission, processing, sorting, compilation, indexing, usage, and eventual lifecycle termination of user data matrices. Within the architectural context of the Unim system, we operate with a profound commitment to data integrity, transactional visibility, and modern algorithmic transparency. It is the core intent of this extensive regulatory document to remove any ambiguity, hidden assumptions, or unclear procedures regarding how our software network interfaces with your private information strings.

This policy applies globally and without reservation to all individuals, groups, administrative personnel, restaurant owners, courier agents, delivery workers, student clients, or third-party observers who actively download, register with, deploy background processes for, log into, or otherwise interact with any frontend viewport or backend terminal controlled by Unim. This includes native mobile application builds deployed via operating system distribution tracks, compiled desktop environments, web-based progressive caching layers, local network edge nodes, and administrative control panels. By initiating an account configuration loop, authenticating your terminal session, or maintaining an active connection to our localized microservices, you are explicitly confirming that you have meticulously read, syntactically comprehended, and completely harmonized your legal expectations with the exhaustive technical workflows specified within the text of this document.

In this document, terminology such as "the Platform," "Unim," "our service," "we," "us," or "our" refers strictly to the administrative entity governing the Unim software suite, its underlying code repositories, and structural cloud servers. Conversely, terms such as "the User," "You," "Your," "Student Client," or "Vendor" denote any individual node or active entity querying our Application Programming Interfaces (APIs). The scope of this policy is strictly bounded by active operational logic, meaning it governs data actions happening in real-time as well as long-term analytical aggregations committed to our database storage shards over extended multi-year periods.

2. Deep-Dive Taxonomy of Ingested Information Elements

To establish absolute transparency and fulfill our structural design requirements, we map out every layer of data ingestion into clean, distinct categories. Our system does not passively capture information without a direct, mathematically justifiable necessity anchored in our core application business logic. Every single character, token, or structural file metadata element recorded by our ingestion frameworks is fundamentally required to power a feature or secure a network transaction pipeline.

2.1 Directly Provided Identity and Profile Datasets

When an individual initializes an account registration loop or authenticates via our external service components, our frontend validation controllers capture specific forms of high-fidelity personal data. This manual input track gathers explicit data blocks, which include:

• Full Personal Representation Nomenclature: This field is collected to establish real-world identity parameters within the campus database layout. It is distributed across vendor receipts, transaction histories, and delivery logs to facilitate accurate localized identification during the final handoff phases of an active order lifecycle.
• Cryptographic Authentication Coordinates: Captured as a primary index key to map user accounts securely. This string serves as the mandatory validation target for sending reset tokens, updating security keys, and passing transaction confirmation receipts. It acts as the anchor for the user profile within our authentication sub-layers.
• Telephonic Communication Channels: Collected during form setup to establish an urgent real-time voice or SMS link between ordering students and restaurant owners. This is strictly utilized to resolve supply-chain bottlenecks, such as out-of-stock ingredients, menu substitutions, or uncollected food items.
• Academic Institutional Metadata To ensure the integrity of localized campus pricing scales and geographical boundaries, our forms log matriculation parameters, college affiliations, and campus location keys. This prevents out-of-bounds queries from mixing independent food court systems.

2.2 Automated Network Telemetry and Device Hardware Mapping

Whenever a client application connects to our virtual private servers or initiates a secure network request, an automated logging layer intercepts the handshake to gather telemetry data. This is an invariant system background process designed to prevent programmatic spam, block brute-force attacks, and detect modified application files. This automated capture stream processes the exact operating system framework version, local network internet protocol (IP) addresses, device hardware identifiers (such as unique hardware hashes), localization parameters, system language preferences, device screen resolutions, and active system uptime counters. This information is processed strictly within our protective operational layer and is never shared with third-party advertising networks.

2.3 Academic Identity Verification Artifacts

To preserve the security, integrity, and exclusive campus-specific commercial frameworks of Unim, we require student clients to complete a mandatory student verification process. When initiating this verification loop, the platform collects and processes:

• On-Device Camera and Media Access: Upon receiving your explicit, hardware-level runtime permission consent, the application accesses your device camera or chosen local storage photo library solely to acquire a visual representation (photograph) of your official physical student identification card.
• Visual ID Card Image Storage: The student ID photograph you provide is securely uploaded to our encrypted cloud storage buckets. Student IDs are handled strictly to ensure local platform compliance. These images are used for a period necessary to facilitate reliable system verification, handle fallback manual administrative reviews, and troubleshoot automated extraction errors.

3. Detailed Backend Processing, Database Architecture, and Multi-Document Aggregations

Data processing on the Unim platform moves entirely away from traditional, risky, client-driven updates. To ensure absolute data security, prevent malicious parameter injection, and maintain a highly secure multi-tenant environment, all core business logic mutations happen exclusively behind our microservice proxy firewall layer. When an action occurs on a client viewport, the app builds a structured payload and routes it via HTTPS to our centralized server environment.

Once a request clears our cryptographic validation filters, the backend initiates multi-tiered aggregation operations across our database infrastructure. For example, when a restaurant owner alters an order lifecycle state (such as changing a status to accepted, ready, or completed), our server does not merely update a single isolated row. To drive our real-time administrative dashboards and maintain accurate reporting, the backend initiates an atomic database batch script that writes to multiple structural collection targets concurrently.

This process updates individual order records, modifies the student's personal transaction history logs, adjusts specific platform metrics, increments multi-document restaurant performance figures, and recalculates regional campus order counts. This complex approach ensures that our campus metrics remain perfectly synchronized across all live sessions without requiring slow, expensive database-wide reads. Furthermore, these statistical tracking operations log specific platform milestones, item popularity metrics, seasonal peak hours, and user tier advancements, ensuring the platform remains highly optimized for high-volume campus crowds.

3.1 Automated and Manual Student Validation and Cross-Referencing

When you submit your student ID photo, the Unim backend securely parses the image using a structured Vision LLM framework to extract textual keys under a strict schema. The validation engine processes this extracted information through the following gates:

• Database Whitelist Alignment: The extracted institutional name and structure are compared against our pre-verified Firestore universities collection (which hosts valid campus naming variants, academic domains, and structural geographic profiles) to confirm that the ID is issued by an active, supported campus.
• Identity Matching: The extracted full name and student details are algorithmically compared against the profile details you provided during registration. To ensure a smooth user experience, our system utilizes token-based match calculations to verify name matches across minor discrepancies (e.g., missing middle names or abbreviation differences).
• Tamper & Fraud Detection: The verification engine automatically scans the card's visual structure, typography, layout, and lighting conditions to identify signs of digital alteration, spoofing, or computer-screen photo duplication.
• Manual Administrative Review: In cases where the automated system flags the card due to low lighting, physical wear, glare, or unrecognized formatting, the securely stored ID photo will be queued for manual inspection by an authorized member of the Unim administration team to finalize your onboarding.

4. Real-Time Cloud Messaging and Background Notification Routing

A core element of the Unim campus experience is instant transactional feedback. When a restaurant vendor processes an order state transition through our backend API, our server automatically builds an optimized push notification payload. This messaging flow uses the Firebase Cloud Messaging (FCM) platform to deliver alerts to the student client device.

To receive these updates, the student client application requests standard operating system permission blocks immediately following an approved login event. Once permission is granted, the app fetches a unique FCM registration token from Google's servers and merges it directly into the student's Firestore user document under the `fcm_token` field. If this token is rotated or updated by Google, an active background stream listener intercepts the refresh event and updates the database record automatically. When our backend detects an active token, it formats a personalized message string—including the specific restaurant name and the unique order pickup code—and transmits it instantly as a background push notification. This allows the student to see the exact state of their lunch without needing to keep the app open continuously.

5. Data Retention Lifecycles, Security Safeguards, and Third-Party Disclosures

All data traffic passing through the Unim ecosystem is strongly encrypted during transit using enterprise-grade Transport Layer Security (TLS) protocols over HTTPS connections. This prevents network sniffers, proxies, or intermediate nodes from viewing user tokens, API headers, or order parameters. We maintain a strict policy against selling, leasing, or trading user data arrays to data brokers or advertising brokers for monetization purposes.

Data remains inside our active, sharded database nodes for as long as necessary to fulfill the operational features of the application, manage financial accountabilities, and protect our platform security records. When an account lifecycle reaches a verified deletion request, our backend initiates a structured scrubbing routine that removes personal profile documents, deletes associated registration tokens, and anonymizes historical order items to protect long-term platform statistics without exposing private personal identities. Administrative logs tracking security events, bans, and system alterations are retained permanently in encrypted logs to meet platform auditing requirements.

6. User Rights, Adjustments, and Structural Compliance Amendments

Users maintain full authority over their private profiles within our platform boundaries. You have the right to view your collected profile records, update your communication numbers, adjust your registration details, or revoke notification permissions through your operating system settings panel. Any change made to a profile document updates our centralized database layer instantly, meaning your updated details will reflect across all restaurant terminals on the very next order transaction loop.

As our technical infrastructure grows, our cloud providers update their systems, and local campus requirements change, this privacy document will adjust accordingly. Every update will be published directly to this page with an updated modification date at the top of the file. We encourage users to check this page periodically to remain informed about our data handling, security boundaries, and storage choices. Continuing to access, browse, or place orders through Unim after an update is posted constitutes full, informed consent to our updated privacy policies.

7. Contact Us

If you have any questions, concerns, requests, or complaints regarding this Privacy Policy or the way your personal information is collected, processed, stored, or protected, you may contact the Unim Dev team email address support@unim.pro.

We review all privacy-related requests and aim to respond within a reasonable timeframe in accordance with applicable data protection laws and institutional regulations.