Separate database per school
Each school's operational data lives in its own database, and requests are bound to the school's own address.
Security and tenant isolation
School data is sensitive. BAINI separates schools at the database, binds every session to its school, and checks authority on the server for every request.
Each school's operational records live in that school's own database. Shared platform services — accounts, school directory, plans — sit in a separate control plane.
Pre-sign-in pages and branding are resolved from the school's verified address. An unknown address gets nothing — never a default school.
A signed-in session belongs to one school. Presented at another school's address, it is refused.
Permissions follow the role and the classes a person is assigned; checks run on the server for every request, not only in the screen.
Sensitive actions — configuration changes, approvals, report revisions — are recorded with who did them and when.
Published reports are never edited in place. Corrections are reissued as a new version; the earlier one is withdrawn.
Mobile sign-in is tied to an enrolled device; parents add a device PIN.
What we do not claim
Separate database per school
Each school's operational data lives in its own database, and requests are bound to the school's own address.
Audit trails
Sensitive changes — configuration, approvals, report revisions — are recorded for review.
Platform operations console
Provisioning, lifecycle and support access for BAINI's own operators.
Parent Android access
Phone-based registration, confirmation by the school and a device-bound PIN.
Ask us. We will show you the isolation and access model in detail, and be clear about what is still being prepared.