Roles & Access
Amal is built around five distinct roles, and the rights each role has are enforced in code, not just by convention. Every action on the platform flows through a permission gate. If a role does not hold the required permission, the request is rejected outright and no partial data is returned.
The five roles
Teacher
Teachers are the primary users of the platform. A teacher can see the classes they are assigned to, view each student’s reading picture, review and act on support recommendations, record context flags, and track how support is going over time. They cannot see classes they are not assigned to, and they cannot view children from other schools or organizations.
What a teacher can do is shaped entirely by which classes they have been linked to. That link is explicit and managed by an administrator: there is no automatic assignment, and a teacher does not inherit access to a class simply because they belong to the same school.
Student
Students interact with the reading tasks and the warm-up exercises. They do not sign in with a username and password. Instead, each student uses a short numeric code that is unique to their class. The code is easy enough for a first-grader to type without help. A teacher can regenerate a student’s code at any time, which immediately ends any existing student session.
Students cannot see other students’ results. They cannot see their own internal reading-ability estimate, benchmark levels, or any status label. What they see is only what they need to complete the current task.
Parent
Parents can see their own child’s growth picture, reported in growth language that is plain and supportive. They do not see raw scores, internal status codes, or any label drawn from clinical or international-assessment frameworks. If the platform sends a parent a notification, it passes through a stricter language filter before delivery, one that also removes numeric values that could be misread as grades.
A parent is linked to a specific child by a school administrator. The link is one parent account to one child in the current implementation (Wave 1). Reading a different child’s information is not possible regardless of whether both children attend the same school.
Principal
Principals can see the reading health of their school across all classes and teachers, in the same growth language used for teachers. They can view how classes compare over time and how groups of students are progressing, but they cannot modify any plan, reassign any student, or change anything a teacher has set up. The principal role is read-only on the instructional side.
Cross-school views are not available at the principal level. A principal sees their school and only their school.
Admin
Administrators provision the school network: they create organizations, schools, and classes; they create user accounts and assign them to roles; they link teachers to classes and parents to children; and they manage the lists of override codes and language-safety rules that the whole platform depends on. Admins cannot see individual student reading results unless they have also been assigned a teacher or principal role in addition.
A special super-admin level exists for platform operators who need to work across organizations. Every time a super-admin accesses a resource that belongs to a different organization, that access is logged automatically.
How permissions work
Behind each role is a specific set of permission codes. When a request arrives, the server checks whether the authenticated user holds the permission required for that action. The check happens after confirming the user’s identity and deriving their current permission set from the database, not from what was written into the login token alone.
Permissions are granular. Viewing a class roster requires one permission; editing a student’s accessibility settings requires another; submitting a context flag requires a third. A teacher who holds the view permission for a class does not automatically hold the manage permission for it.
There is no implicit escalation. A manager who oversees several schools has their scope listed explicitly on their profile. If that list is empty or misconfigured, the platform fails open by showing all schools in their organization rather than silently locking them out, because a mistaken configuration should not make the platform unusable for an admin who is actively trying to fix it.
Student quick codes
Students sign in through a different path from all other roles. A teacher or administrator creates the student account and the platform generates a short numeric code for that student within their class. The code is class-scoped: the same digits in a different class belong to a different student.
When a student enters their code, the platform checks it against the list of active codes for that class. If the code matches an active enrollment, the student is signed in. If the code has been regenerated or the enrollment has ended, the code is rejected.
The code is long enough to avoid accidental collisions within a class but short enough for early-grade children to use independently. If a collision comes up when generating a new code, the platform retries automatically. Rate limiting applies to code login attempts to prevent guessing.
Teachers can regenerate a student’s code from the student management view. The old code stops working immediately. Any session that was open under the old code is ended.
What changes between Wave 1 and later
In Wave 1, the specialist role (a reading-support specialist who advises on Tier 3 cases) sits inside the admin seat. A school administrator with the specialist flag handles the approvals that in later waves a dedicated specialist persona will own. The rest of the role model described here is the full intended design.
Parent linking in Wave 1 supports one parent per child. Multi-parent linking is planned for a later wave.
Where to go next
- Organizations & Classes explains how the school network is structured and how data is separated between organizations.
- Provision Users walks the steps an admin follows to create accounts and make assignments.