Trust centre

AI and automated decisions

Teachers write the questions and the key points to listen for. They can also choose a reusable rubric version for an assignment. Its shared criteria are assessed alongside the question key points. Links on classes, units and activities only suggest a rubric; the teacher explicitly chooses the version for each assignment. When a student answers, Microsoft's speech service turns the recording into a transcript, and an AI model checks the transcript against each key point. SayAble uses that check to suggest a mark. An answer with no question key points or shared rubric criteria is not sent to the AI model; the teacher marks it. Private marking notes are not sent to the AI.

For class content answers, SayAble saves the transcript and the question as soon as transcription succeeds, before AI marking. If marking is interrupted or fails, the answer stays saved with processing pending or failed. The student or teacher can retry marking the same answer without making another submission. Retries use the question and all marking criteria saved with that answer. The chosen shared rubric is locked when students first open the work. Editing a reusable rubric creates a new version; existing assignments and results keep their original version. If transcription fails, the temporary device copy described below can be used to send the recording again.

In Assess, students see no automated score or feedback. The teacher reviews each answer, sets the final mark and shares it with their feedback, and can change or ignore any suggestion. In Practice, students see automated feedback when processing finishes so they can try again. We keep the AI's suggestion and the teacher's mark side by side on each answer. A teacher can approve a mark privately, then release it to the student. Reopening released feedback hides it from the student until it is released again. We keep a history of review and correction actions, including who made the change, when, and the previous and new values.

Speech recognition and AI analysis can be wrong, and accent, pace and speech differences can affect a transcript. Compare the transcript with the recording when one is kept. Pronunciation is a separate question type, still a preview, and its scores are kept apart from content marks.

Student work is not sold, not used for advertising or profiling, and not used to train AI models.

Student data

Students do not have accounts or email addresses. For each student, a class holds:

• the name the teacher types into the class list (the form asks for a first name or nickname) and a four-digit PIN;
• for each answer: the question as it was asked, the transcript, the language, how long the recording ran, the AI suggestion (a score, the key points it found missing, and its feedback text), and the teacher's mark and feedback, with the history of review and correction actions;
• whether the teacher has turned on recording consent, and when the student last saw the recording notice;
• the audio recording, only where recording consent is on.

For teachers, we hold an email address for sign-in and an optional name, school and role.

We do not collect student email addresses, passwords, birth dates or school ID numbers. The site has no analytics or advertising trackers. SayAble's own database does not store IP addresses, but our hosting and font providers receive them when a page loads.

Audio recordings

In a class, every spoken answer goes to SayAble's server and from there to Microsoft Azure to be transcribed or scored, whether or not the recording is kept. The browser's own speech recognition is not used for class work. Microsoft states that it does not store audio sent for this kind of recognition.

The audio file is kept only if the teacher has turned on recording consent for that student. Without it, our server does not store the audio, and a database rule refuses it as well. Before recording, each student is told whether their voice will be kept and for how long.

To recover an interrupted submission, the student's device may keep a temporary recording from Finish until the answer is confirmed saved (and any permitted recording upload finishes) or the copy is discarded, even in a class that does not keep audio for teachers. Recovery is available for 24 hours. Expired copies are removed when SayAble next opens or checks for pending answers; a closed browser cannot run cleanup. Public demos and teacher previews do not keep these recovery copies.

Kept recordings are deleted after 30 days. Each one is given an expiry date 30 days after it is made, and a job scheduled to run once a day deletes expired recordings, so a recording can outlast its 30 days by up to a day. If a teacher withdraws recording consent, that student's kept recordings are deleted straight away, or at the latest by the next daily run. Only the teacher who owns the class can play a recording, through a link that stops working after 60 seconds. Recordings are not included in the database copies we make.

Access, retention and deletion

Teachers sign in by email; students join a class using a code, their name and a four-digit PIN. Teachers can see their students' PINs, and we store them readable rather than scrambled, because a PIN is there to keep classmates out of each other's work, not to keep anything from the teacher. A PIN belongs to one student in one class. Five wrong PINs in a row pause that student for fifteen minutes; twenty-five since the PIN was issued lock it until the teacher makes a new one. Each time a PIN is shown, printed or changed, we record which teacher did it and when; nothing shows that record in the product yet. We record when each student was last shown the recording notice, so their teacher can see who has seen it; that record is not consent, which stays the teacher's recording-consent setting.

Transcripts, marks, feedback and review history have no automatic expiry yet. They stay until the teacher deletes the student, the class or their own account. Removing a student from a class list keeps their results. Undoing an accidental submission keeps the answer and its history but removes it from the student view and class totals; the teacher can restore it. Excusing a question removes it from that student’s required work. These corrections are different from deletion. Deleting a student permanently removes their answers, transcripts, marks, associated review history and any kept recordings. Deleting a teacher account removes all of that teacher's classes, students and recordings. Error records, which can contain fragments of data, are deleted 90 days after the error last happened.

Teachers can archive a finished class. It leaves active class lists and becomes read-only for the teacher, who can still view or export its records and restore it later. Students cannot open an archived class, including through an existing session. Archiving does not extend the 30-day recording expiry.

Deleting a class is permanent and has no recovery period. The teacher sees counts of the students, assignments, answers and saved recordings and confirms the class name. Deletion removes the full roster, assignments, answers, transcripts, marks, review and consent history, and kept recordings for that class; the teacher's library and other classes stay. Access closes before audio files are removed, followed by their records. If cleanup fails, remaining records stay available to the teacher and deletion can be retried; recordings already removed cannot be restored. A results CSV is offered before deletion, but it excludes recordings, transcripts and AI working and is not a full backup.

When a student device learns that a class is archived or deleted, SayAble closes that class and removes its pending recovery copies; other class sessions stay. An offline or closed browser cannot be cleared remotely. Temporary recovery still expires after 24 hours and is cleaned up on the next open or check. Exports already downloaded are not removed.

The database is not yet backed up automatically. A copy made by hand during development can still contain records deleted since it was made. Our providers also keep their own logs, such as request logs, for periods they set. Ask us to confirm the scope and timing of deletion, including recordings, logs and backups, before making a commitment to a family or school.

Security

In place today:

• Every connection uses HTTPS: between browsers and SayAble, and between SayAble and its providers.
• Our providers encrypt stored data at rest; Supabase states that it uses AES-256. We rely on their statements and have not tested this ourselves.
• Each teacher can reach only their own classes and students. The database enforces this for everything a teacher's browser reads.
• Students have no direct access to the database. Their requests go through our server, which checks a signed session of at most ten hours against the class list on every request. Entering a class code does not reveal the class list, and class-code lookups, wrong names and PINs are rate-limited. Class-code lookups are counted per network using a one-way code derived from the network address, which changes every hour; the address itself is not stored.
• A spoken answer to a class question is saved only with words that Microsoft's speech service transcribed from audio sent under that student's own session. A browser cannot supply or change the words that are marked. A pronunciation score is saved only as Microsoft's speech service scored it.
• Transcription, pronunciation scoring and AI marking are limited per student, per teacher, and for the public demo per network and in total, so repeating them cannot run up unlimited use. The limit is set well above what an activity needs, including retries. A student who reaches it is asked to wait a minute, and their recording is kept to send again. These counts use the same kind of one-way code, changing every hour, and store no name, ID or address.
• Teachers sign in with a one-time link sent to their email. The link expires after an hour, and a new one can be requested at most once a minute.
• Our server uses no third-party code packages. The browser loads one library, Supabase's client, from our own site rather than from a third-party server.

Not yet in place:

• multi-factor sign-in for teachers, and a documented check that every staff account at our providers requires it;
• separation by school or school board (today, data is separated per teacher);
• automatic database backups, and a tested restore;
• a content security policy;
• an independent security review or penetration test.

Data residency

We do not claim that all SayAble data stays in Canada. Each service is set up separately, and we have not yet confirmed every setting in the providers' own dashboards. What we know today:

• Database, sign-in and recordings (Supabase): our records say the project is in Supabase's Canada (Central) region. We are confirming this.
• Speech (Microsoft Azure AI Speech): our records say the Canada Central region. We are confirming this.
• AI suggestions (Microsoft Azure OpenAI Service): our records say a regional deployment in Canada East, rather than a global one that can send requests to other countries. We are confirming the deployment type.
• Hosting (Vercel): pages are served from Vercel's global network. Our configuration does not pin SayAble's server code to a Canadian region, and Vercel's default for new projects is Washington, D.C. Until we confirm the setting, assume that answers pass through the United States on their way to Microsoft and Supabase.
• Fonts (Google Fonts): served from Google's global network. No student data is sent.
• Browser speech recognition (public demo only): where it runs depends on the visitor's browser; see Public demos. Class work does not use it.

Subprocessors

These companies process data for SayAble:

• Microsoft Azure AI Speech transcribes spoken answers and scores pronunciation. It receives the audio of each answer and its language, and for a pronunciation question, the phrase itself.
• Microsoft Azure OpenAI Service suggests which key points an answer covers. It receives the transcript, the question, its key points and any selected shared rubric criteria, its marks and the guidance on how much to say. It does not receive the student's name, unless the student says it in their answer. Microsoft states that this data is not used to train its models, and that it may keep requests its systems flag for abuse review.
• Supabase runs the database, teacher sign-in and recording storage. It holds everything listed under Student data.
• Vercel hosts the website and runs SayAble's server code. Every request passes through it, including audio and transcripts on their way to Microsoft and Supabase. Its request logs include IP addresses.
• Google Fonts supplies the typefaces. Every page, including the student app, loads them from Google, which receives the device's IP address and browser details.

Sign-in emails are sent through Supabase's sign-in service, or an email provider connected to it; we are confirming which. Email you send us is handled by Google Workspace.

Accessibility

We are working toward WCAG 2.2 AA. That is a goal, not a claim of conformance.

The app is built for keyboard use, with visible focus, labelled controls, support for reduced motion, and announcements for screen readers while a student records. It has not yet been tested with a screen reader, at high zoom, or on the devices schools commonly use, and it has not had an independent audit. If something gets in your way, please tell us.

Incident response

We do not yet have a tested incident-response or breach-notification process. Both are being drafted. Before a school pilot, we will agree with the school how and how quickly we tell it about an incident that affects its students, so that it can meet its own duties to families and regulators.

To report a security concern, email daniel@sayable.ca with "Security" in the subject.

Public demos

The teacher demo uses fictional sample data and keeps edits in memory until the page reloads. It does not connect to a teacher account. The student demo processes an answer when you submit one, using the same speech and AI services, but does not file it as a class submission or keep the audio. How often the demo can be used from one network, and by all visitors together, is limited; when it is busy it asks you to wait a minute.

The student demo, and a teacher's preview of their own activity, may also use the browser's built-in speech recognition, to show words on screen and as a backup transcript. Some browsers send that audio to the company that makes them; Chrome sends it to Google. SayAble has no agreement with those companies. Class work does not use the browser's speech recognition.

For schools and school boards

SayAble is a working beta. No school has yet completed a privacy impact assessment or security review of it, and a demonstration is not evidence of a completed security or accessibility assessment.

Before using real student data, we need to agree on student access, consent, retention, deletion and export, where each service processes data, and the school's own requirements. On request, we can walk through each service on this page, the retention settings and how deletion works. We do not currently claim Canadian-only data residency, WCAG conformance, or independently measured accuracy or classroom outcomes.

Privacy contact

For privacy questions, this page, the data flow for a school review, or a pilot discussion, contact Daniel Litvak at daniel@sayable.ca.