Built so your security review is the easy part.
Everything your technology director, legal counsel, or board will ask about Orchen, the data lifecycle, the security architecture, the sub-processors, and an honest account of where our compliance roadmap stands today.
Last updated July 2026 · Questions or document requests: emil@orchen.ai
Six commitments, each enforced in the architecture.
These are not policy statements layered on top of the product. Each one is a design decision you can verify in a walkthrough.
Source conversations deleted in 7 days
Raw student transcripts are deleted within seven days, after the nightly pipeline distills them into profiles, concept progress, and narratives. Insight compounds across the year from those distillations; crisis-flagged content keeps its context until resolved.
No model training on student data
Student data is never used to train AI models, ours or our providers'. Provider terms prohibit use of transmitted data beyond generating the requested response.
No data sales, no advertising
Orchen is paid by schools, full stop. There is no advertising business model and no third party purchasing student data, now or planned.
Row-level security on every table
Access control is enforced at the database layer, not just in application code. A teacher's query physically cannot return another school's rows.
Immutable audit logging
Every staff access of student data writes an insert-only audit entry with server-side actor verification. The trail cannot be edited or deleted.
School-controlled visibility
Parent visibility runs on a five-tier model with school-set defaults and ceilings. Crisis flags route only to the school's designated contact.
A single conversation, end to end.
The path of one student-AI conversation through Orchen, from creation, through analysis, to deletion. Every step is logged, scoped, and documented.
A student opens a new chat. A session row is created; each message is stored against it with row-level security scoping it to the student. During this window, the conversation is visible only to the student.
Messages save as they happen. Topic classification updates every five student messages. Concept progress increments. Crisis detection scans every message and routes any flag to the school's designated counselor.
The analysis pipeline runs nightly: learning profile updates, concept distribution updates, struggle and strength tags refresh, and weekly advisor narratives compile.
The source conversation is deleted from the messages table. The session row remains with derived insight attached. The advisor dashboard shows the synthesis; the conversation that produced it is gone.
Learning profiles, concept progress, and longitudinal trajectory remain, governed by the school's retention policy. Crisis flags are exempt from automatic deletion because of their safety significance.
A nightly pg_cron job enforces each school's configured retention rules across messages, sessions, quiz results, and profile snapshots.
Student or school admin initiates deletion. The profile soft-deletes, crisis flags anonymize (preserving the safeguarding record without personal identifiers), and a full structured data export is available beforehand. The audit log of the deletion itself persists.
Enforced in the database, not promised in a PDF.
The privacy guarantees here are structural, enforced at the database layer, where an application bug can't quietly undo them.
Row-level security on every table
Every table carries RLS policies enforced at the Postgres layer. Role checks run through SECURITY DEFINER helpers to prevent recursion, and service-role operations are isolated from end-user role-based access, the two cannot accidentally cross.
Insert-only, RPC-mediated, server-verified
Direct writes to the audit_log table are blocked. All entries go through the log_audit_event RPC, which verifies the actor server-side. Every staff access of student data is recorded; school administrators can review their school's log at any time.
TLS in transit, encrypted at rest
All traffic between clients, the application, and the database runs over TLS. Data at rest is encrypted by the underlying infrastructure provider.
Role changes blocked at the trigger level
A database trigger prevents non-admins from modifying their own role, premium status, or age flags, privilege escalation is stopped in the database, before application code is even involved.
No consent record, no persistence
Students without an active consent record operate in a non-persistent Guest Mode: their interactions are never written to the database. Consent is tracked, versioned, and revocable.
Forced credential rotation, no self-registration for parents
Admin-created accounts must set a new password on first login. Parents cannot self-register, accounts exist only because a school created them, which keeps the account perimeter under institutional control.
Who can see student data.
Six roles, each scoped to what the role needs. Boundaries are enforced architecturally, not by policy documents.
| Role | What they can access |
|---|---|
| Student | Their own conversations, assignments, flashcards, quiz results, goals, and journal. The private workspace is invisible to every other role. |
| Teacher | Learning profiles and synthesis for students in their classes. Raw conversations only when a session has been explicitly shared. |
| Advisor | Weekly narratives, learning profiles, and crisis flags for assigned students. Shared sessions only for raw conversation access. |
| Parent | Summary data at the school-configured visibility level (1–5). Level 5 includes redacted, read-only transcripts; every access is logged. |
| School Admin | School-scoped administration: users, settings, consent records, audit logs, visibility configuration. |
| Orchen | Platform-level access for compliance, support, and audit purposes only. All access is logged. |
Where your data goes, and why.
Orchen uses a small number of infrastructure providers. None of them may use student data for any purpose beyond delivering the service.
| Provider | Purpose | Data involved |
|---|---|---|
| Supabase | Database, authentication, edge functions, file storage | All platform data, encrypted at rest, US-hosted |
| Google (Gemini) | AI model inference for tutoring, writing analysis, and synthesis | Conversation content transmitted per-request; not retained for training |
A current, complete sub-processor list with data processing terms is available on request and is incorporated into our Data Processing Agreement. Schools are notified before any new sub-processor handles student data.
FERPA, COPPA, and state privacy law.
The same posture satisfies all three: collect less, keep less, log everything, and keep the school in control of the record.
Orchen operates as a school official
Under FERPA, your school controls the education records; Orchen processes them as a school official under the school's direct control, with a legitimate educational interest. Access, amendment, and deletion requests route through the school, and our audit logs satisfy FERPA's documentation requirements for record access.
Under-13 protections enforced by role gates
Students under 13 require verifiable parental consent managed through the school's consent process. Without an active consent record, the platform's COPPA-aware role gates place the student in non-persistent Guest Mode, no data is written.
Data minimization as the default posture
State student-privacy statutes vary, but nearly all reward the same posture: collect less, keep less, log everything. The 7-day source deletion, school-configurable retention, and immutable audit trail are designed so that posture holds across jurisdictions. Your counsel reviews the DPA against your state's requirements before deployment.
An honest account of our current posture.
Trust pages usually list what a company has. Ours also lists what we don't have yet, because you deserve to make this decision with complete information.
Architecture-level controls, live in production
Row-level security, immutable audit logging, consent gating with Guest Mode, the 7-day source deletion pipeline, per-school retention enforcement, crisis flag lifecycle tracking, structured data export, and right-to-be-forgotten tooling. Each is verifiable in a technical walkthrough.
SOC 2 certification
Orchen itself isn't SOC 2 certified yet, but it runs on SOC 2 Type 2-certified infrastructure (Supabase), with all data encrypted in transit and at rest. Our own SOC 2 Type 2 audit is on the roadmap as we move from founding pilots to broader deployment. If your procurement requires our own certification today, we'd rather tell you that here than in month three of an evaluation, and we're glad to walk your reviewer through every control in detail.
Third-party penetration test
An independent penetration test is planned ahead of our first full-school deployments. Schools participating in our founding program will receive the results when complete.
Continuity, protected by contract
What an early-stage company offers instead of a decade of audits: an architecture where the privacy promises are structural rather than procedural, direct access to the people who built it, and contractual terms, the school owns its data, a full structured export is available at any time, and defined wind-down terms guarantee an orderly exit with data returned and deleted on schedule, whatever happens to the vendor. That is the deal we offer, in writing.
Documents available on request.
Email emil@orchen.ai with your school name and we'll send these within one business day:
Data Processing Agreement
Retention windows, deletion rights, breach notification terms, and the full sub-processor list.
Security overview
A technical summary of the controls on this page, written for IT directors and security reviewers.
Architecture walkthrough
A live session with the founder covering RLS policies, the audit log, and the deletion pipeline against the production system.
Also see our public Privacy Policy and Terms of Service, and the full platform architecture.
What reviewers ask us.
If conversations are deleted in 7 days, how do advisors see anything useful? ⌄
The analysis runs before deletion. Each night, conversations feed the learning profile, concept tracking, and the weekly advisor narrative. By the time the source transcript is removed, the synthesis your staff actually uses already exists, and that's all they ever needed. Advisors were never going to read raw transcripts at scale anyway.
Does Google see our students' conversations? ⌄
Conversation content is transmitted to Google's Gemini models per-request to generate AI responses, the same way any AI product works. The terms governing that access prohibit using the data to train models or for any purpose beyond generating the requested response. No student account information is required for inference, and Google is listed in our DPA as a sub-processor.
What happens to our data if Orchen shuts down? ⌄
Your school owns its data, contractually. You can request a full structured export at any time during the contract, and you have a 30-day export window after termination for any reason. After that window, all school and student data is deleted. The export covers profiles, derived insights, assignment data, and quiz results in machine-readable formats.
Who at Orchen can read student conversations? ⌄
In the ordinary course, no one. Analysis is performed by AI, not by staff reading transcripts. Platform-level access exists for compliance, support, and audit purposes, and every such access writes an audit log entry. There is no support workflow that involves browsing student conversations.
How does crisis detection interact with the deletion policy? ⌄
Crisis flags are exempt from automatic deletion because of their safety significance. A flag moves through a tracked lifecycle, open, reviewing, resolved, or escalated, with a 24-hour urgency indicator, and it routes only to the school's designated counselor. If a student account is later deleted, flags are anonymized rather than destroyed, preserving the safeguarding record without the personal identifier.
Can we verify any of this, or do we take your word for it? ⌄
Verify it. The architecture walkthrough is a live session against the production system, RLS policies, the audit log behavior, the deletion job, with your technical reviewer in the room asking questions. For founding schools, we treat the security review as part of the partnership, not an obstacle to it.
Put your hardest reviewer in the room.
Book a walkthrough and bring your technology director. We'll go as deep as they want to go.
Book a walkthrough →Or request documents directly: emil@orchen.ai