Every layer of Orchen, in detail.
The homepage tells the story. This page documents the architecture: how the AI is built, what the insight layer actually computes, how the role system works, and what the compliance posture looks like underneath.
For IT directors, curriculum leads, and school heads in active evaluation.
A chat surface, an assignment shelf, a flashcard library, and a private workspace.
Students see Orchen as a conversation. Behind that conversation: a system that adapts to how they think, an assignment workflow that their teachers configured, a flashcard library built automatically from their conversations, and a private workspace nobody else can see.
Orchen guides through questions rather than handing over answers
The Socratic pattern is hard-coded into the system prompt; it is not a setting that can be toggled off. Students cannot ask the AI to simply provide the answer and expect compliance.
Four modes, selected in real time
Verbal exploration, structured guidance, examples-first, step-by-step — selected in real time based on the student's response patterns. A student who learns by example sees examples first. A student who learns by reasoning gets prompted to reason.
Teacher assignments appear in the chat sidebar
When a teacher creates an assignment, it appears in the student's chat sidebar with a Launch screen. The student clicks through, sees a hook designed for their grade level, and works with Orchen on the assignment in conversation. Submission and reflection happen in-chat.
Concepts extracted from conversations, graded semantically
Orchen extracts key concepts from chat sessions and offers to save them as flashcards. Cards group by subject. Students can quiz themselves; quizzes use semantic grading, not exact-word matching. Teachers can also create standalone quizzes that the student takes through chat.
Goals, journal, and preferences nobody else can see
Students set goals, write private journal entries, and adjust their own learning preferences. None of this is visible to teachers, advisors, or parents unless the student explicitly shares it. Privacy here is not a setting — it is architectural.
Images handled natively alongside messages
Students can upload images alongside their messages. The AI handles them natively. A student stuck on a physics diagram can photograph the diagram; Orchen sees it and guides accordingly.
Pedagogy encoded as system behavior, not as marketing language.
Orchen's pedagogical posture is not a description in a privacy policy. It is a set of specific rules encoded into the AI's system prompt and reinforced through how the product is structured. Each rule is operational, not aspirational.
Orchen asks before it answers
When a student arrives with a question, the AI's first move is almost always to ask the student what they have tried, what they understand so far, or what specifically is stuck. Only after the student has engaged does Orchen begin to guide.
Two wrong answers, then a new approach
After two consecutive wrong answers on the same concept, Orchen switches approaches — different example, different framing, different entry point. The student does not get repeatedly pushed toward the same dead end.
Two question types, two responses
Orchen distinguishes between conceptual questions ("why does this work this way?") and mechanical questions ("how do I compute this?"). It responds differently to each. Concept questions get unpacked through reasoning. Mechanical questions get scaffolded through steps.
The example stops before the final step
Rather than working a complete example for the student to copy, Orchen works partial examples that stop before the final step. The student finishes. This preserves the productive struggle that learning requires.
When the student has it, Orchen stops
When a student has arrived at the answer through their own work, Orchen recognizes it and stops guiding. It does not extend the conversation unnecessarily. Recognition is part of the pedagogy.
The system prompt extends per discipline
The system prompt extends differently for math, writing, science, history, and other subjects. Each module encodes the pedagogical strategies appropriate to that discipline. Writing assignments get prewriting scaffolds. Math assignments get worked-example logic.
Three assignment kinds, each carrying metadata
Teachers create three kinds of assignments. Each carries metadata: lesson context, key concepts, vocabulary, common misconceptions, success criteria, scenario hook, and a parent-friendly explanation. The AI uses this metadata to teach the assignment well, not just to run it through chat.
A dedicated essay surface with rubric-aware feedback
For essay assignments, students enter a dedicated writing surface with TipTap-based editing, prewriting worksheets (explore → thesis → outline → ready), draft checks with rubric scores, inline comments tied to specific paragraphs, and mechanical feedback (grammar, punctuation, style) configurable by school policy.
Structured insight, computed nightly, surfaced where it matters.
Every conversation Orchen has with a student feeds an analysis pipeline. The pipeline produces structured insight — learning profiles, concept distributions, struggle and strength tags — that surface to the people responsible for that student. Source conversations are deleted within seven days. What remains is the synthesis.
Pace, examples, modality, and what works
Each student's profile captures their pace, preferred examples, modality preferences (verbal vs. visual vs. example-based vs. step-by-step vs. conceptual), and the kinds of guidance that work for them. The profile updates continuously as the student interacts.
Four buckets, not a leaderboard
Every concept the student encounters across every conversation is tracked. Mastery state is one of four buckets — demonstrated repeatedly, demonstrated once, in progress, not yet touched. Teachers see the class as a distribution across these buckets, not as a leaderboard of who scored what.
Tagged by subject, surfaced as chips
Specific topics where the student gets stuck or excels, tagged by subject and updated as patterns become clear. These appear as colored chips on the advisor dashboard and in the weekly narrative.
A structured narrative per advisee, every week
For every student in their caseload, advisors receive a structured weekly narrative — independent effort level, curiosity depth, critical engagement signals, and any concerning patterns. The narrative is generated automatically from interaction data, not from surveys or self-reports.
Years of trajectory, synthesized
The longer a school stays with Orchen, the deeper each student's profile becomes. A senior who has used Orchen since freshman year has a four-year trajectory captured as structured insight — not as transcripts to scroll through, but as a synthesis of how their thinking has changed.
Subject tags update as the conversation evolves
Conversations are re-classified every five student messages. Subject tags update as the conversation evolves. The sidebar stays organized without the student having to maintain it.
Every conversation scanned, every flag tracked
Every conversation is scanned for concerning content — self-harm indicators, distress signals, references to harm by others. Detected content is flagged automatically and routed to the school's designated counselor. Every flag carries a 24-hour urgency indicator and moves through a full lifecycle (open, reviewing, resolved, or escalated).
Six roles. Each sees only what their role needs to see.
Orchen's data model is organized around six roles. Each role has a defined view of student data — scoped, narrative, and synthesized. The boundaries between roles are enforced architecturally, not through policy documents.
Own work only, private workspace invisible to all
Sees their own conversations, their flashcards, their assignments, their goals, and their private journal. Sees nothing about other students. The student's private workspace (goals, journal, preferences) is invisible to every other role unless the student chooses to share.
Structured insight, not raw transcripts
Sees structured insight for students in their classes — learning profiles, concept distributions, recent session summaries, struggle and strength areas. Sees assignment progress and writing rubric scores. Does not see raw transcripts unless the student or school explicitly grants that access.
Weekly narratives and immediate crisis flags
Sees weekly synthesized narratives for every advisee in their caseload. Receives crisis flag notifications immediately. Can write notes to parents through the parent communication system. Sees shared sessions only — students choose what to share.
Weekly digests at the school's visibility level
Receives weekly digests at the visibility level the school has set. Sees conversation starters, supporting techniques, subject activity, and overdue assignments. The five visibility tiers range from summary-only to full transcript access; each school sets its own default and maximum.
Configures everything school-level
Configures everything school-level: AI identity, mechanical feedback toggles (grammar, punctuation, style — each independently configurable), parent visibility defaults and maximums, crisis routing contacts, white-label branding for premium schools.
Service-role isolated, never views conversations
Full user management with audit logging. Service-role isolated from school-level operations. Never views student conversations except through documented privacy-bounded review for product improvement, logged and disclosed.
You set the defaults. The defaults are yours.
Orchen's behavior is configured at the school level. The configuration covers what the AI looks like to students, what data parents can see, how mechanical writing feedback is delivered, where crisis flags go, and how the product is branded.
A tutor that matches your institutional voice
The system prompt that defines how Orchen presents itself can be configured per school. Premium schools can override the default model. The tutor's name, voice, and pedagogical defaults match the school's institutional voice.
Grammar, punctuation, style — each independent
Three categories — grammar, punctuation, style — toggle independently per school. A school that wants Orchen to flag only grammar (and leave style to the teacher) configures that. A school that wants all three configures that. A school that wants none gets a writing workspace without mechanical highlights.
Five tiers, with a default and a ceiling
Five tiers, ranging from summary-only to full transcript access. The school sets the default tier and the maximum tier any individual parent can request. Schools can require student notification when a parent requests an upgrade.
Flags stay in the school's designated chain
Schools designate the counselor or safeguarding lead who receives crisis flags. The 24-hour urgency indicator and the lifecycle tracking are configurable. Crisis content never leaves the school's designated chain.
The AI presents as the school's tutor
Premium schools display their own logo and institutional name above every Orchen message. The school's brand sits where the Orchen brand would otherwise sit — the AI presents as the school's tutor, not as a generic AI product.
The architecture your security review will pass.
Orchen is built on Supabase Postgres with strict row-level security on every table, immutable audit logging via SECURITY DEFINER RPCs, per-school data retention via pg_cron, and a service-role isolation model that limits even Orchen team access to documented review operations.
RLS enforced at the Postgres level
Every table in the database has RLS policies enforced at the Postgres level. Role-based access is checked via SECURITY DEFINER helpers to prevent recursion. Service-role operations are isolated from end-user-facing role-based access; the two cannot accidentally cross.
Insert-only, RPC-mediated, server-verified
Every staff access of student data is logged via the log_audit_event RPC. The audit_log table is insert-only at the table level — direct inserts are blocked; all writes go through the RPC, which verifies the actor server-side. The audit trail cannot be modified or deleted.
Per-school policy, swept nightly
Each school sets a retention policy covering messages, sessions, quiz results, and snapshot keep-counts. The pg_cron-driven retention job runs nightly. Crisis flags are exempt from retention deletion; they persist until manually resolved.
Source deleted within seven days of analysis
Source student conversations are deleted within seven days of analysis. What remains is the derived insight — learning profiles, concept distributions, struggle tags. The advisor narrative is computed before deletion. The conversation itself does not persist for the long term.
Tracked, versioned, revocable
Every student account has a consent_records entry. Students without consent records enter a non-persistent Guest Mode where conversations are not saved. Consent is tracked, versioned, and revocable.
Soft-delete, anonymize, export, comply
Students (or school admins on their behalf) can delete an account at any time. The delete process soft-deletes the profile, anonymizes crisis flag records, and triggers full retention compliance. A full data export is available to the student before deletion.
Built around the statutory boundaries
The architecture is built around FERPA's parent/student visibility boundaries and COPPA's under-13 protections. Schools with under-13 students configure additional restrictions through the role-gate system. Audit logs satisfy the FERPA documentation requirements for record access.
Safeguarding record preserved, identifier removed
When a student account is deleted, their crisis flag history is anonymized rather than deleted. This preserves the safeguarding record while removing the personal identifier — a balance between right-to-be-forgotten and the school's duty of care.
A single conversation, end to end.
The path of a student-AI conversation through Orchen — from creation, through analysis, to deletion. Every step is logged, scoped, and documented.
Student opens a new chat. A session row is created in the database. Each message is stored against that session with RLS scoping to the student. The conversation is visible only to the student during this window.
Messages are saved as they happen. Topic classification updates every five student messages. Concept progress increments. Crisis detection scans every message. The conversation remains the student's private surface.
The analysis pipeline runs nightly. Learning profile updates. Concept distribution updates. Struggle and strength tags update. Weekly narratives compile. Crisis flags route to the designated counselor if detected.
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.
The student's learning profile, concept progress, and longitudinal trajectory remain. Teachers see continuing insight. Advisors see ongoing patterns. Parents see ongoing digests. The student's own view shows their continuing work — flashcards, assignments, goals — not the deleted source conversations.
The pg_cron retention job sweeps based on the school's policy. Insight may persist for years if the school configures long retention. Source data is already gone by then.
Student or school admin initiates deletion. Profile soft-deletes, crisis flags anonymize, data export is offered. The audit log of the deletion itself persists.
Ready to see it in motion?
A 30-minute walkthrough is the fastest way to verify any of the architecture above against the live product.