Data Privacy: What Sets SALLIE Apart

SALLIE has two halves. The agent runs on a machine your school controls: an appliance in a locked room, or a virtual machine on your own cluster. It holds the names and phone numbers of students and families, the photos and names of visitors, your state-reporting records, and the keys. Every staff screen is opened through the agent.

The cloud is SALLIE's shared service. It holds a code such as P-7Q2KX4M3 in place of each student and family, plus times, places, classes, buses, rules and the record of every change. It runs the screens and the rules, and it is where staff sign in.

When a page goes from the cloud to a staff browser, it passes through the agent, and the agent fills the names in. When a person types or says a sentence, the agent swaps the names for codes before it goes to the cloud. The cloud never serves a page that holds a student's or family's name, because it does not have one.

Staff names are the exception. Staff names and email addresses are in the cloud, because staff sign in there, and they are treated as directory information.

The AI model never sees a name. Staff can say “Jordan Lee is out sick today” (a made-up name), and the model that reads it sees “P-7Q2KX4M3 is out sick today”. One piece of plain code swaps names for codes before any text reaches the model and swaps them back after, and a test checks that no prompt ever holds a name from the demo roster. A name that could mean two people never reaches the model at all; SALLIE asks which one. The model only turns a sentence into one command from a fixed list. Plain code checks the command, works out what it would change, and shows that to a person. A person confirms every change that moves a student, messages a family or changes the school's set-up.

You do not have to take our word for it. The agent logs every message it sends to the cloud and every answer that comes back, each exactly as sent. Field rules decide which fields of a record may leave, and a field with no rule is dropped. Your school's administrator can read this ledger on the agent's admin console.

Each day the agent also runs a leak test. It plants a made-up student with a nonsense name, and that record travels every path a real one does. The agent then asks the cloud to search everything it stores for that name, and the answer must be zero everywhere. The name changes each time it is planted, so an old leak cannot hide behind a new name. This is a self-test, not proof: the cloud is the party being tested, and could answer zero whatever it held. The proof is the ledger, which only your agent writes. The agent's proof page shows the ledger with a search, the count of readable names ever sent, the latest leak test and how many days in a row it has passed, where the keys are, and which outside services are in use. Anyone on your network can open it, and no name is on it.

Your school holds the keys. The signing key is made on your agent the first time it starts, and stays there; only its public half is given to SALLIE, so the cloud can check that a message came from your agent. The key that seals the names is on your agent and nowhere else. The disk's recovery key is shown once at first setup and is yours to keep; SALLIE does not hold a copy. SALLIE holds no key to your agent. Remote access by SSH is off, and a support session happens only if someone at your school turns it on at the machine and sets the password.

Because we run the cloud, we can see what it holds: codes, schedules, classes, rooms, buses, the record of changes and who on staff made them, staff names and emails, staff chat in codes, counts of state-reporting gaps by student code, and the visit record for visitors in codes. We cannot see the name or phone number of any student or family, anything spoken into the microphone, the contents or names of shared files (they stay in your own Google Drive or OneDrive), visitor names, photos and ID details, state-reporting values and state ids, the text of family replies, or your agent's admin console.

These are the outside services. Anthropic provides the AI model, which is reached only through SALLIE's cloud; it sees codes only, and its retention follows Anthropic's API terms. Twilio sends texts on your school's own account and number; it sees a family's number and the text while the text is sent, and the agent deletes the message body from Twilio after delivery. Heroku is where SALLIE's cloud runs, and it holds what the cloud holds: codes, and staff names. Your own services, such as your student information system and your Google Drive or OneDrive, are reached by the agent directly when you connect them; the cloud does not talk to them. Speech-to-text, when it is turned on, runs on your agent, and the sound is never written to disk.

One more service is involved only if your school chooses it. SALLIE can check a visitor against a sex-offender registry, and that check is off until the school turns it on. With the state's registry file loaded onto your own agent, nothing leaves: the check is a lookup on the agent. With a manual check, a person types the name into the state's own site and records the result. With a search through an NSOPW-style service, the visitor's name and, when held, date of birth go to that service; that client has not been tested against a live service. In every case the cloud learns the result and no more, with the visitor's code and the code of the staff member who decided.

Some things are never kept, and others only for a time. The text of a family's reply is never stored. Speech is never written to disk, and text taken from speech is kept on the agent for seven days. A visitor's name, photo and the last four characters of a scanned ID stay on the agent and are deleted a year after the visitor was last seen, unless your own policy sets a different period. An export of your school's data stays on the agent until your school deletes it.

The limits, said plainly. Texts are simulated until Twilio is connected; until then no text is sent and the office calls. The agent is on your machine, so your school keeps it on and updated: operating system security updates install themselves, and agent updates wait for a person to say so. The disk is encrypted on the appliance and the virtual machine image, and the recovery key is the school's to keep; a Docker host has only the encryption its own host gives it. Backups of a virtual machine hold names, so they need the same care as the machine. Family replies come from Twilio to your agent, so one address must be reachable from outside, and none of the three ways to open it has yet been run against a live Twilio number. Some connections have been tested only against test copies, not a live system: PowerSchool through OneRoster, Google Drive and Microsoft OneDrive, and the virtual machine images on a real Hyper-V or vSphere cluster.