Privacy Policy

1. Who is the data controller

SchoolSlate is self-hosted software. The school, board, or district that operates an instance is the data controller and decides what data is collected and why. SchoolSlate Technologies provides the software and, where contracted, hosting or support — acting as a data processor on the controller's instructions.

Because the application, database, and AI model all run on infrastructure controlled by the operating school, student and staff records are not transmitted to SchoolSlate or to any third-party service in normal operation.

2. What data the platform handles

Account data: names, email addresses, roles, and the school/board (tenant) a user belongs to.

Student & family records: enrollment and admissions data, sections and rosters, attendance, assessments and grades, report cards, fees and invoices, and parent–teacher messages.

Operational data: audit logs (who did what, and when), and documents you upload (e.g. admission documents, curriculum/textbook material).

Technical data: authentication tokens and standard server logs needed to run the service securely.

3. How data is used

Data is used solely to operate the school: managing people and roles, admissions and enrollment, academics, communications, fees, and the school-life features (meals, clubs, transport).

We do not sell data, we do not use it for advertising, and we do not use student data to train external AI models.

4. AI and student data

SchoolSlate's AI features run on a model hosted on your own servers (e.g. Ollama or vLLM). The assistant answers from your school's own uploaded documents, and generation is grounded only in subject, grade, and the material you provide — never in student personal data.

No prompts, documents, or answers are sent to OpenAI, Google, or any external AI provider. AI processing stays inside your infrastructure.

5. Tenant isolation & security

Each school/board is a separate tenant. Every record carries a tenant identifier and access is enforced at the database level with row-level security, so one tenant can never read another's data.

Access is role-based; passwords are hashed; sessions use short-lived access tokens with refresh. The operating school is responsible for transport encryption (TLS), backups, and infrastructure hardening in its environment.

6. Compliance by jurisdiction

When a board is created it declares a country, and the platform applies the matching regime — FERPA & COPPA (United States), GDPR (EEA/UK), DPDP (India), and a conservative default elsewhere — governing consent expectations, audit-log retention, erasure handling, and breach-notification timelines.

7. Children's data

Student records frequently concern minors. Collection is limited to what the school needs to operate, parental/guardian consent is handled according to the declared jurisdiction (e.g. COPPA in the US), and access is restricted to authorized staff and the student's own parents/guardians.

8. Retention & deletion

Records are retained for as long as the operating school requires them and according to its jurisdiction's policy. Audit logs are append-only and retained per that policy.

Erasure and data-export requests are handled by the operating school as controller; the software provides the tools to support them.

9. Your rights

Depending on your jurisdiction you may have rights to access, correct, export, or erase your data, and to object to or restrict certain processing. Because the school is the controller, please direct such requests to your school administrator, who can fulfill them within the platform.

10. Curriculum content

Only openly-licensed or school-licensed textbooks should be uploaded. Each document records the rights basis on which it was added.

11. Changes to this policy

We may update this policy as the software evolves. Material changes will be reflected here with a revised effective date.