Role-separated portals
Administrators and students use purpose-built, separately authenticated surfaces. A student session can never reach an administrative route.
Security & data residency
Built to survive institutional procurement
Allocation decides who gets what. That makes it a system your committee will question, your IT team will audit, and your students will appeal. Here is exactly how Allotix is controlled — including what we do not claim.
The controls behind every allocation
Backend-enforced phase guards
Allocation, result publication and reporting are gated at the API layer, not just hidden in the interface. An action that is invalid for the current phase is refused by the backend.
Event-scoped data isolation
Every record lives under its allocation event. Backend event membership is the authoritative access check for a student's data — not anything the browser asserts.
Direct database access denied
Firestore security rules deny client access outright. All institutional data flows through the backend using the Admin SDK, so there is no client-side path to the database.
Authenticated service boundaries
Admin routes are protected by JWT. Student routes verify Firebase ID tokens. Internal task endpoints are protected by Cloud Tasks OIDC, so background work cannot be triggered externally.
Data stays in India
Institutional and student records are stored and processed in Indian data centres — they do not leave the country.
What we don't claim
Allotix checks your institutional email domain when students sign in. That check is there to guide people to the right login and to catch typos — it is a usability feature, and we do not present it as a security boundary. The boundary that actually holds is backend-verified event membership combined with a verified Firebase identity token. We would rather tell you that up front than have your IT team discover it during review.
Procurement
Security questions we get asked
Where is our student data stored?
In India. Student and institutional records are stored and processed in Indian data centres and do not leave the country. Allotix runs on Firestore for data, Firebase Authentication for student identity, and Cloud Run for the backend.
How do you stop a student from seeing another student's data?
Every record is scoped to an allocation event, and the backend checks event membership on each request as the authoritative access control. Firestore rules deny direct client access entirely, so the browser cannot query institutional data even if it tried — the backend is the only path in.
Does checking our institutional email domain make the system secure?
No, and we do not claim it does. The institutional email domain check exists to guide students to the right login and to catch typos. It is a usability feature. The real access boundary is backend-verified event membership combined with Firebase-verified identity tokens, which is what actually determines whether a request can read or write data.
Can an administrator run an allocation at the wrong time?
No. Events move through explicit lifecycle phases, and the API refuses actions that are invalid for the current phase. Allocation can only run in the allocation phase, and results cannot be published until allocation has completed. These guards live in the backend, so they hold regardless of what the interface allows.
Do you have an audit trail for allocation decisions?
Yes. Every allocation run records the order students were processed in, the preferences they submitted, and the seat state at the moment each student was allotted. This is what allows an academic office to answer an appeal with evidence rather than an assertion.
Need something for the committee?
We'll walk your IT and academic teams through the architecture, the data flows, and the deployment model on a call.