Privacy Policy — ALAMA BN CBC Reports

1. Who runs this

ALAMA BN CBC Reports is a school administration and documentation workspace built for Kenyan CBC schools. It is developed and operated by the platform owner you registered with.

Your school is the controller of its own records. We hold them on the school's instruction. A parent or guardian who wants something changed in a learner's record should ask the school first — the headteacher can edit or remove it in the workspace immediately.

Questions about this policy go to the same people who run the school account: bonfacenyarega@gmail.com or +254 745 322 445.

2. What we hold

School details — name, contact email and phone, address and logo, plus the classes and subjects you set up.
Staff accounts — name, role, email, phone number, a hashed password, and (if the teacher chooses to add one) a signature image.
Academic records — exams and CATs, marks, sheet status, remarks, and the results a headteacher publishes.
Applications and notices — the details submitted through the Register a school form, plus records of messages we sent back.
An audit trail — in-app notices and staff actions, kept per school and visible to that school's headteacher.
Server settings — including the AI provider keys and mail credentials the platform owner stores. These never leave the server; see AI Use.

3. Learner records

A learner row holds an admission number, a UPI where your school uses one, the name, the class, and a flag for whether the learner has left. There is no date of birth, no gender and no photograph field — the workspace never asks for a learner's picture.

Parent phone and parent email exist as columns in the database, but no screen writes to them today. If we ever turn that on, this page changes first.

When a learner moves on, the school marks them as left. The record is kept in the class history so past result sheets still add up, and the headteacher can restore it.

4. Documents and files

Generated schemes, lesson plans, notes, mark lists and report cards are rendered when you ask for them. We do not keep a server-side copy of every document your teachers produce.

The exception is the term archive: when a headteacher deliberately files a term's results, that snapshot is stored so the school can compare terms later. Two images are stored as part of the school's own branding and sign-off: the school logo and a teacher's signature.

Because documents are not backed up by us, the school should keep the exported Word, PDF or Excel files it submits — those downloads are your copies of record.

5. Who sees what

Every account belongs to exactly one school. The school filter is applied in the database query itself, not in the browser, so a request can only ever return the signed-in user's own school.

A class or subject teacher sees the classes and subjects assigned to them. Trying to save marks for a subject they are not assigned to is refused by the server.
A headteacher sees the whole school: classes, staff, exams, marks, published results, reports, settings and the audit trail.
The platform owner administers schools and accounts. They can provision and remove access; the school's academic records are managed by the school.

There is no parent or learner login, and no public page shows any school's data.

6. Sign-ins and sessions

Passwords are stored only as a scrypt hash. Activation codes and reset codes are stored hashed too.
A new headteacher's first sign-in uses the six-digit activation code sent to them — never a password we invented for them.
Sessions are a random token held in an HttpOnly, SameSite=Lax cookie that expires after 14 days. No credential is ever placed in browser storage.
Failed sign-ins are counted per account and per address: five failures lock the attempt for fifteen minutes.
Two-factor authentication (TOTP with recovery codes) is available and optional. We do not currently switch it on for anyone.

7. The AI assistant

Only teaching context goes to an AI provider — class, subject, term, weeks, strand and sub-strand, plus the teacher's own brief and the school and teacher name. Learner names and marks are never included, and the workspace warns staff not to type them into the assistant.

We log that a user made a request and when, so the owner can see load and stay inside provider limits. Prompts and answers are not stored. The full picture, including which providers are used and what is not yet controlled, is on the AI Use page.

8. Email and WhatsApp

We use your phone number or email address to deliver what the account needs: application decisions, activation codes, temporary passwords and staff alerts. Email goes out through an SMTP account held by the platform owner; WhatsApp messages go through Meta's WhatsApp Cloud API. Message content is not used for anything else and is never sold or shared for advertising.

Codes travel in message text. An activation code or a temporary password is readable by whoever holds the phone or mailbox. Staff should change a temporary password at the first sign-in, and a school should tell staff to delete those messages once used.

9. Hosting and third parties

The website is served by Cloudflare Pages.
The API runs as serverless functions and the database is PostgreSQL on Supabase.
Sub-processors are the parties that help us operate: the AI providers listed on the AI Use page, DuckDuckGo when a staff member turns on live search, Meta for WhatsApp, and the mail provider that sends our email.
One script — the spreadsheet reader used for Excel import — is loaded from cdnjs.cloudflare.com when needed. Nothing else remote is fetched to run the workspace.

We do not claim a specific data location or an uptime guarantee; if you need either in writing for a board or a county office, ask and we will discuss it before you register.

10. Cookies and analytics

One cookie: the session cookie that keeps a signed-in staff member in the workspace. There is no analytics tool, no advertising pixel, no social embed and no consent banner on this site. Nothing is dropped on the public landing page for a visitor who never signs in.

11. Retention and deletion

School data is kept for as long as the school's account is active. There is no automatic purge after a term or a year — your marks stay where the headteacher left them.
Sessions expire after 14 days. Reset codes last 15 minutes; activation codes last 7 days. Rate-limit counters and AI usage counters are trimmed to their window.
Removing a school is a hard purge: accounts, sessions, classes, subjects, learners, exams, marks, CATs, remarks, archives, leavers, notices and audit entries go with it. It is done on request and is not reversible.

To close a school account, the headteacher or an owner contact writes to bonfacenyarega@gmail.com or calls +254 745 322 445. Export your documents first.

12. Your choices

A staff member can sign out at any time, which deletes the server-side session, and can change their own password.
A school can correct or retire any learner record from the workspace without asking us.
A headteacher can choose not to use the AI assistant; everything the assistant drafts can be written by hand instead.
The owner can switch the AI feature off entirely for the platform.

We handle a request about personal data as fast as we can and will tell you if we cannot do something. We may update this policy as the product changes; the date at the top moves when we do. Material changes are announced to school accounts by email or WhatsApp.

What your school's records look like on our side