How the system handles personnel data

An evaluation is an employment record. What follows is how the platform is actually built, in specifics you can check on a call, rather than a list of adjectives.

Districts cannot see each other

Separation is enforced at the data layer, not by the screen a person happens to be looking at. Every record that belongs to a district carries that district, every query is filtered by it automatically, and the filter fails closed: if a request arrives without a district resolved, it matches nothing rather than everything. Permission checks in the browser are treated as a convenience for the user; the API re-checks every one of them.

A score cannot be rewritten after the fact

A published rubric version is immutable, and each evaluation records which version it was conducted against. Revising a rubric creates a new version and leaves every completed evaluation reading exactly as it did the day it was signed. This is the property that makes a historical score defensible in a grievance or an appeal.

Every export is on the record

Exporting evaluation data writes a permanent register entry: who ran it, when, the exact filter used, how many evaluations and rows it covered, whether scores were included, and how many were withheld. The exporter's name and email are stored with it so the record stays readable after that person leaves the district.

Written comments are personnel material and are deliberately excluded from the district-wide export, while the full narrative remains available on an individual evaluation.

Score disclosure is enforced by the server

When a district turns on the release gate, the numbers are withheld by the API, not hidden by the interface. Someone who guesses the address of their own report is served a report with no figures in it. Acknowledgement is blocked in the same way, so nobody is asked to sign off on results they cannot see.

Uploaded evidence is not web-reachable

Evidence files are stored outside the application's own folder, with no static file serving pointed at them. The application refuses to start if it is configured to store them somewhere reachable. Every download re-checks the requester's permission and that the file belongs to their district, and file paths are re-validated on each request rather than trusted because they came from the database.

There are no passwords to steal

Sign-in is a one-time passcode sent to a work email address and entered inside the app. Repeated failed attempts lock the account, and unlocking is a deliberate action with a reason recorded against it. Sign-in history is retained for roughly ninety days.

Changes to access are recorded

When somebody’s access changes — added, deactivated, reinstated, or their evaluator and evaluatee roles altered — the change is recorded with who made it and why. Separately, every record in the system carries who created it and who last changed it, stamped automatically rather than by whichever piece of code remembered.

Notifications are not best-effort

An email that has to go out is committed in the same transaction as the change that caused it, then dispatched by a worker that retries with backoff. A failure surfaces and is retried rather than being swallowed, so someone waiting to hear that their evaluation was submitted is not left waiting because a mail server was briefly down.

Deactivation keeps the record

Deactivating somebody removes their access and frees their seat, and keeps every evaluation, comment and piece of evidence they were part of. Nothing is deleted as a side effect of a person leaving.

Your data can leave with you

Your Evaluation Coordinator can request a complete backup of the district, evidence files included, without asking us. It is built in the background and you are emailed when it is ready. You choose the passphrase at the moment you download it and the file is encrypted with that passphrase, which we never store: nothing on our servers can open your backup. A backup file can also be opened in the app to preview what it holds, so a copy you are relying on is one you have checked.

The same Coordinator can request permanent deletion of the district from inside the app. A 30-day hold runs before anything is removed, and the request can be cancelled at any point during it. There is no exit process to negotiate and nothing to ask us for.

What we don’t claim

The platform ships in US English only today: multi-language support is built but not released, and there is no language picker.

You can take a backup and inspect it, but restoring one is not yet something you can do yourself. If you ever need a district restored from a backup, that is a conversation with us rather than a button.

And while your roster imports from a CSV, historical evaluations from another system do not come across on their own. Tell us what you have and we will tell you honestly what can be moved.

Doing a security review?

Tell us what your district's process needs and we will answer it directly, including the questions this page does not cover.

Get in touch