Security overview
This page answers the questions district IT leaders ask us most, in the order they ask them. The short version of every answer: the strong guarantees in DistrictWise are architectural — they hold because of how the system is built, not because a policy says so.
Does one district's data influence results for another district?
No — structurally impossible in the current architecture. There is no training loop, no shared index, and no cross-tenant retrieval path. Nothing a district's staff types can change what any other district's staff sees.
- No fine-tuning, anywhere. The model is Anthropic's stock Claude via API; the codebase contains no training or feedback code. Our API key is pinned to a dedicated workspace, and Anthropic's commercial API terms bar training on our traffic.
- Retrieval is per-district. Search runs against one district's corpus per request, in that district's own index. Other tenants' indexes are never loaded. Vector embeddings are computed locally on our server and cached inside the district's own corpus store.
- Queries don't feed anything. Usage logs exist for billing and quality; nothing is ever read back into retrieval, ranking, or any model.
What is shared across customers is the product itself: the application code, the California Ed Code law layer (public statute), the curated clarifying-question library, and role taxonomy templates — all vendor-authored, none derived from any customer's query stream by any automated process.
How are tenants isolated?
Every staff seat is cryptographically bound to its district when it is provisioned. A request that names any other district is refused at the API layer with a 403 — on answers, rule findings, change feeds, and incident filing alike. The binding survives PIN resends and seat reassignment. There is no district picker anywhere in the staff product, because a seat can only ever see its own district.
What happens to student names?
They are masked in the browser, before transmission. Names, emails, phone numbers, addresses, and cued student IDs are replaced with placeholders on the user's device; the map to restore them never leaves the browser. The masking is fail-closed — if it cannot verify success, the request is blocked and nothing is sent. Un-masked student identity does not reach our servers or the AI model.
How is access controlled?
- Licensed seats only — each seat is an individual staff email, provisioned by agreement with the district
- PIN sign-in issues a short-lived, tamper-evident session token; PINs are stored HMAC-hashed, never in plaintext
- The staff interface auto-locks after inactivity
- Administrative access to the production system is over a private network only — the box exposes HTTPS to the public internet and nothing else
Infrastructure
- Dedicated production instance on U.S.-based AWS infrastructure — not shared with any other product
- TLS for all traffic; the application server is bound to localhost behind an HTTPS reverse proxy
- Secrets held off the application tree with restricted OS permissions; automatic security updates enabled
- Districts retain ownership of their data and may request deletion at any time — see the privacy policy
In writing
Our Data Processing Agreement commits contractually to what the architecture already enforces: customer data is not used to train or fine-tune any model, nor to provide services to any other customer. We put it in the contract because a written commitment should outlive any future architecture decision.
Questions your review needs answered that aren't here? Ask us directly — technical answers from the people who built it, not a sales layer.