Running a School on PDP Shikshya: The Operations Suite and Architecture

A school AI tutor is the demo. The thing a school actually has to operate — every day, across hundreds of students, parents, and teachers — is everything around it: who is present, who has homework due, which teacher is in which room, what the parents can see, and which calendar the holidays are on. PDP Shikshya, built by pdpspectra, ships that full operations layer alongside its AI pedagogy. This post is for the people who have to run the school — and the engineers who have to run the platform. (New here? Start with the product overview.)

Six roles, cleanly separated#

Everything in the platform flows from its access model. PDP Shikshya is multi-tenant: each school is an isolated tenant, and all of its data — users, curriculum, telemetry, billing — is walled off from every other school. Inside a tenant, six roles each see a purpose-built experience:

• super_admin — the platform operator. Creates and suspends schools, provisions school admins, watches platform-wide usage and cost, and sets the AI provider key.
• tenant_admin — runs one school: all users, departments, grades, sections, periods, subjects, branding, and feature toggles.
• department_admin — manages the teachers and students within a single department.
• teacher — their department’s class: telemetry, curriculum, homework, attendance, and routine.
• student — their own dashboard, the Socratic tutor, games, and courses.
• parent — a wellbeing view of their linked children, digests, and report cards.

This separation is not cosmetic. It is what lets one deployment serve many schools safely, and what makes the parent-versus-teacher visibility split (below) enforceable rather than aspirational.

The daily operations suite#

Each of these is a working module rendering live data, not a placeholder.

Attendance. Pick a date and class, mark each student present, late, or absent. Late and absent students — and their parents — are notified automatically. Students and parents see the running record and percentage. Attendance is the kind of thing that sounds trivial and is the backbone of a school’s day; here it is wired into notifications and the parent view from the start.

Class routine. A weekly grid planner built on reusable bell-schedule period templates. The class teacher or admin fills each cell with a subject and teacher — and the system detects teacher double-booking and flags it before it becomes a Monday-morning problem. Every teacher also gets a “My teaching” view of exactly the periods and sections they take.

Homework and assignments. Set homework with a due date and an optional library attachment; students submit text or a file; teachers grade with a mark and comment. An AI time estimate helps a teacher size the work realistically, a class rep can propose homework for teacher approval, and accepted homework auto-creates a slot in the student’s study diary. Separately, teachers can assign quizzes or puzzles at a chosen difficulty — AI-generated or hand-written — to an individual, a group, a grade, or the whole school, and track completion.

Analytics and report cards. Engagement, quiz and puzzle performance by subject, weekly activity, assignment and homework completion, attendance, top students, “needs attention” flags, and a CSV export — scoped to a teacher’s department, with a school-wide overview for admins. Printable report cards round it out.

Timeline, chat, library, and calendar. A school feed with media and audience targeting (and approval workflows for student and parent posts); direct and group messaging in which student-to-student chats are monitored by department teachers; a shared library of vetted materials including the real grade 9–10 textbooks; and a calendar covered next.

Built for Nepal: the Bikram Sambat calendar#

A platform built for Nepali schools cannot treat the Nepali calendar as an afterthought, and PDP Shikshya does not. The calendar runs in Bikram Sambat (BS) by default or Gregorian (AD), with the school admin choosing which is the default. Events — exams, holidays, meetings, activities — can be entered with BS dates and viewed in List, Month, or Year layouts, school-wide or per grade.

This is the sort of localization that separates a product designed for a market from one merely translated into it. The bilingual English/नेपाली interface is the visible half; the BS-native calendar is the half that proves the product understands how the schools it serves actually keep time.

The parent-versus-teacher visibility split#

One of the most deliberate design decisions in the platform is what a parent can and cannot see — and it is enforced by the role model described above.

A teacher sees the granular picture: per-attempt Proof-of-Thought telemetry, points of struggle, escalations, the exact questions a student asked. A parent sees a deliberately coarser wellbeing snapshot: which subjects their child explored, how many sessions and active days, an overall engagement level. The detailed academic telemetry is teacher-only by design.

The reasoning is sound. Parents asked for visibility, but raw per-attempt data about a child’s every struggle is the teacher’s professional instrument, not a surveillance feed for the home. Parents get a genuine AI “This week” digest of their child — generated without sending any child PII to the model — plus performance, teacher feedback, attendance, a printable report card, and control over their child’s Digital Sunset limits. It answers “lack of parental visibility” without turning the platform into a monitoring tool pointed at minors.

The architecture, briefly#

For the engineers, the stack is deliberately pragmatic — chosen so a school can run it without a platform team, and so a privacy promise can actually be kept.

Layer	Technology	Why it was chosen
Backend	Python · FastAPI	async, with native server-sent-event streaming for the live tutor
Reasoning	A swappable large language model client	zero-retention / no-training terms; the vendor sits behind one module and can be replaced
Retrieval	Local TF-IDF over the school corpus	the curriculum wall — nothing about queries or corpus leaves the box
Privacy	Local edge anonymization	strips PII before any text reaches the model
Data	SQLModel + SQLite	simple to run, trivially upgradeable to Postgres
Auth / tenancy	JWT + bcrypt, multi-tenant RBAC	each school an isolated tenant; six roles
Frontend	React + Vite + Tailwind + shadcn/ui	bilingual, role-gated dashboards, streaming chat, in-browser code runner

Two choices deserve a note. The retrieval layer is local TF-IDF, not a hosted vector database — a deliberate trade that keeps the curriculum corpus and every query inside the school’s own deployment. And the LLM sits behind a single swappable client module, so the platform is not married to one AI vendor and can move to whichever offers the zero-retention terms a school requires. The data layer starts on SQLite for a frictionless pilot and lifts to Postgres when a deployment grows. We unpack the privacy implications of these choices in the student-data privacy post.

The takeaway#

Under PDP Shikshya’s Socratic tutor is a complete school-management system: attendance that notifies parents, a routine planner that catches double-bookings, homework and assignment workflows with AI sizing, department-scoped analytics, a Bikram-Sambat-native calendar, and a parent view that is informative without being invasive — all enforced by a clean six-role, multi-tenant access model on a pragmatic FastAPI stack a school can actually run. It is the operations spine that turns a clever tutor into a platform a school can adopt. See it at pdpshikshya.com, or read the overview and pedagogy posts for the rest of the picture.