Security Practices

Protecting student information is a core responsibility, not an afterthought. This page describes how we secure the data entrusted to us. Our practices are reviewed at least annually.

1. Encryption

• All data is encrypted in transit using industry-standard TLS.
• Student data, including Richard conversation content, is encrypted at rest.

2. Access control and the Arming Gate

Sensitive records are held in a secured internal system we call the Chronicle. The Chronicle is protected by a mechanism called the Arming Gate, which is armed by default. This means that, by default, no one — including our own staff — has standing access to student records.

When an authorized employee needs to view a record for a legitimate operational reason, they must disarm the gate for that single action. The gate is per-action: it grants access only for the specific task, and it re-arms automatically as soon as that use is finished. There is no way to leave the gate open.

Every disarm event is itself recorded in the Chronicle — who accessed what, and when. Access is therefore always minimal, always deliberate, and always audited.

3. Token handling

For integrations that use single sign-on, we do not store individual users' sign-on tokens. We store only the district-level authorization tokens issued to us by the integration partner, and we support coordinated token rotation if a token is ever compromised.

4. Richard conversation safety and escalation

Richard is designed to be safe for children. When a student expresses distress, Richard responds with warmth, stays with the student, and encourages them to reach out to a trusted adult — and for serious situations, surfaces appropriate help resources directly to the student.

When Richard detects a genuine safety concern — self-harm, or a threat to someone's life — an escalation alert is raised to every adult who could act on it, simultaneously rather than in sequence. In a school that is every teacher and administrator at that school, together with the district's administrators; for a family account it is the parent or guardian. All of them see the same blocking banner and receive the same notification, and none of it can be switched off by a preference.

A school year has months in it where nobody is reading a staff inbox. Routing an alert to teachers in July is routing it to no one, so during a school's long break — a window each school sets for itself, because year-round and balanced calendars exist — the alert goes to the guardians the school has on file instead, with the district's administrators still included, since they are typically twelve-month staff. It reverts on its own when term begins; nobody has to remember to switch it back. Guardian notification here is not conditional on a data-sharing consent flag: the message contains none of the child's work, only that something was flagged and to check in.

Clearing the alert is deliberately not a button. It requires re-authenticating and typing a confirmation — the Arming Gate described above — and the act is written to the Chronicle under that person's name and the time. Clearing it clears it for everyone, which is how one adult tells the others they have acted. If a child does not get help, the question of who knew has an answer.

No notification contains anything the child wrote. Every adult is told that something was flagged and asked to check in — never handed a transcript. The student experiences Richard's calm reassurance and support; the escalation is directed to the adults responsible for their safety, not surfaced to the child as a threat.

Conversation limits are suspended during a safety escalation. If a student needs to keep talking while help is on the way, Richard will not cut them off at any usage cap — a child in a difficult moment is never dropped because of a limit. This override applies on every plan that includes Richard.

An escalation does not hand any adult a student's conversation. The gate is armed here as it is everywhere else: to read what the student wrote, an adult must disarm it — re-entering their password and typing a confirmation — and their name and the time are written permanently to the Chronicle before a single word is shown to them. If that record cannot be written, the conversation does not open. There is no way to look without being named.

Disarming is not a master key. It records who looked; it never widens what they may see. Even after the gate opens, an escalation exposes only what the student wrote from the moment of the flag onward, and only to the adults already responsible for that student. Nothing said beforehand is opened up by it, and no other student's conversation is ever within reach.

Closing an escalation — the moment an adult states that a child has been helped, which also ends that access — is gated and recorded the same way. Dismissing the alert banner without resolving it is recorded too, under the name of whoever dismissed it. The intent is plain: if anyone ever asks who knew, who looked, and who decided the matter was finished, that question has an answer.

Separately from safety escalations, whether a school's staff can read ordinary conversations is determined by that school's own agreement with us, decided when the contract is signed. It is not a setting an individual adult can switch on afterwards. Family accounts have no such option.

Richard does not build a hidden profile of a student, and does not create any secret record beyond the conversation itself and the safety escalation, both of which are protected like all other sensitive data. Conversation content is retained and destroyed on the schedule described in Data Retention & Deletion.

5. Incident response

• We maintain a written process to detect, contain, and respond to security incidents.
• After any incident we conduct a review to identify root cause and prevent recurrence.
• If a breach affecting student data occurs, we will notify affected schools within the timeframe required by applicable law and our agreements (commonly within 30 days).

6. Sub-processor security

Our hosting, payment, and email providers are held to recognized security standards. See the Sub-processors page for the current list.

7. Contact

Security questions: privacy@ydablocks.com (or send it through the contact form, which needs no mail app)