Security & compliance
Access is a question of capability and scope.
Not a job title. "Professor" is an employment record; "Head of Department" is a three-year appointment with an end date. Every one of the platform's 190 roles resolves to a set of capabilities scoped to exactly what that appointment covers — and access ends when the appointment does, without anyone having to remember to revoke it.
01
A role is a term of office, not a job title
One person routinely holds a dozen roles at once across different scopes — so authorisation resolves as capability × scope, never by role name. A Head of Department three years into a five-year professorship holds exactly what that appointment grants, and nothing more, and it lapses on its own when the appointment ends. No one has to remember to revoke it.
Capability × scope
Authorisation resolves per request against a person's active appointments — never a hardcoded role name.
Passkeys & 2FA
Passwordless sign-in and step-up authentication for the actions that deserve a fresh assertion.
190 roles, 91 capabilities
Every office an Indian school, college or university actually appoints, composed with scope so a wing head is not a principal.
Session & device control
Every signed-in device is visible and revocable from the account itself, by the account holder.
Full audit trail
Every sensitive read is logged, not just every write.
Who, what and from where, for every sensitive access — a tenant-wide audit trail your leadership can query, retained on a defined schedule, not kept forever by accident or lost after thirty days because nobody configured it. This is a screen in the product, not a spreadsheet someone maintains once a year for an inspection.
Impersonation register
"Sign in as" support access requires the account holder's consent and a step-up assertion from the support user — never silent, never a standing back door. Every impersonation session is its own row in the audit trail: who started it, whose account, when it ended. A trust console with no register of when someone else looked through your eyes is not actually a trust console.
Data residency & isolation
Hosted in India, isolated per tenant
Institution data is hosted within India, and every table carries a tenant boundary that the same capability × scope model enforces on every query — one institution's data does not become visible because another institution's admin made a mistake in their own console.
Backups
Automated, on a schedule, and actually restored
Backups run automatically on a defined retention schedule, and restore procedures are exercised rather than assumed to work — the same append-only discipline that makes the fee ledger auditable is what makes a restore a known-good operation instead of a first attempt during an incident.
Read the DPDP posture this authorisation model exists to support.
Built for India