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, an escalation alert is raised to the adults who can help. This alert appears as a banner at the relevant levels of the portal — for example, to the student's teacher, the school administrator, and the district — so that a responsible adult is made aware and can act. The student experiences Richard's calm reassurance and support; the escalation is directed to the adults responsible for the student's 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