TrackStudents: Systems Architecture — Printable Slide Deck
Technical overview for school IT and administration
Systems Architecture
How information moves through TrackStudents: interfaces, backend services, data paths, privacy boundaries, security levels, infrastructure usage, and integrations — current state, plainly described.
A traceable path from the person to the record.
What you get
- —One high-level system map
- —A data path per school-facing role
- —Backend services in plain language
- —Network and device view for IT
Overlays on every path
- —Infrastructure usage: LOW / MEDIUM / BURST
- —Security level: MANDATORY / CRITICAL / MINIMAL
- —Privacy marker where education records travel
- —Integration status: current, handoff, or future
What this is not
- —Not a compliance certification
- —Not a marketing overview — that is the How It Works deck
- —Not a roadmap commitment; future items are labeled
- —Not a substitute for your district's own review
The whole system, top to bottom.
Two different things called “tokens”.
Session tokens (used)
Short-lived credentials issued at sign-in that prove who a user is on each request. They are a security mechanism. They are not billed per use and they are not AI.
AI model tokens (not used)
Paid units consumed when an application sends text to a language model. Code inspection of the current application found no AI model calls in classroom workflows.
AI model token usage: NONE
Usage scales with classroom activity — teachers generate the largest share of routine data.
Four ways into the same protected system.
Each access point reaches the same backend, but what it can see and do is decided by role and assignment — enforced server-side and in the database, not by hiding buttons.
Teacher
Signs in, works inside assigned classes. Creates most classroom documentation.
Admin
School-level dashboard, aggregated patterns, reports and exports for their school scope.
Support Staff
Assignment-based access to specific classrooms — aides, learning support, ESL, authorized support personnel.
Student Kiosk
A class-specific touchscreen for sign-out only. No login, no grades, no notes, no history.
Teacher → classroom action → permanent record.
What a teacher creates
- —Daily grades and grading events
- —Positive documentation and notes
- —Redirections and incidents
- —Hall pass events and corrections
What the system records
- —Who created or changed the record
- —When it happened, in the student timeline
- —The class and workspace it belongs to
- —Corrections kept as history, not silent overwrites
Why this is the busiest path
Teachers generate the largest volume of routine classroom data — many small reads and writes across the school day. Usage is MEDIUM and steady, with short BURST periods when reports or CSV exports are produced.
A deliberately narrow door.
What the kiosk shows
- —The roster for that one class
- —Who is currently out and for how long
- —Available destinations and occupancy limits
- —Minimum identifying detail on shared screens
What the kiosk never exposes
- —Grades and grading history
- —Teacher notes and incident details
- —Administrative or school-wide information
- —Private student histories or full classroom records
The kiosk uses the same backend as the rest of the application, but through a limited interface with its own restricted operations — it is not a staff login.
Access follows the assignment.
Typical roles
- —Instructional aides
- —Learning support staff
- —ESL support staff
- —Guidance or support personnel when authorized
How scope is set
- —Assigned to specific classes by school staff
- —Class assignment carries a defined staff role
- —Removing the assignment removes the access
- —No automatic school-wide visibility
Least privilege by default
Support staff are not administrators. They see the classrooms they support and nothing beyond them. The boundary is enforced by database policy, so it holds regardless of which screen or link is used.
School-level visibility, school-level scope.
What admins review
- —Missing or incomplete grading
- —Positive documentation and redirections
- —Incident patterns over time
- —Student and classroom timelines
Aggregation and filtering
- —By class, teacher, student, or date range
- —Pass and out-of-class history
- —Documentation consistency across classrooms
- —Report generation for meetings and records
Scope boundary
Administrative access is limited to the school workspace the account belongs to. Broad visibility is the point of the role — which is exactly why it is treated as CRITICAL and reviewed for legitimate educational purpose.
What each backend piece actually does.
Authentication
Identifies the user and starts a secure session over HTTPS.
Role & permission system
Decides whether the person is an Admin, Teacher, or Support Staff member — or is using the restricted kiosk workflow.
Supabase Postgres database
Stores authorized classroom information: students, classes, grades, notes, redirections, incidents, positive documentation, pass events, timelines.
Row-level security
Database-level rules on who may read or write each row. Security is enforced in the database, not only by hiding interface buttons.
Server functions
Controlled backend operations: validation, privileged actions, and a scheduled job — work that should not depend on browser logic.
Timeline / audit records
Historical classroom events, corrections, and documentation activity kept as history.
File storage
Buckets for uploaded supporting documents and generated files, with access rules applied.
Transactional email
Used only for the account and staff messages the application actually sends.
Stripe
MINIMALSubscription, billing and entitlement information. Student classroom records are not sent to Stripe.
Skool
MINIMALTraining, community and help navigation. Skool is not the TrackStudents student-record database.
Google Search Console
MINIMALPublic website indexing and search visibility. Student classroom information does not belong on this path.
Three categories of traffic.
Classroom record paths
STUDENT RECORDEducation records are created, read, corrected, or aggregated.
- —Teacher dashboard writes
- —Support staff classroom views
- —Admin aggregation and filtering
- —Kiosk pass events
- —Student and classroom timelines
Output paths
CURRENT HANDOFFRecords leave the application as files the school controls.
- —Printed / PDF student reports
- —CSV data exports
- —Workspace archive for backup
- —Manual handoff into a gradebook or SIS
Operational paths
CURRENT DIRECTKeep the service running. No classroom records travel here.
- —Sign-in and session checks
- —Stripe subscription and entitlement
- —Transactional email
- —Skool training and help links
- —Public site indexing (Search Console)
Every current path on one page.
AI model token usage is NONE across every current path — the application makes no AI model calls in classroom workflows.
A browser and a network connection.
Normal operation does not require
- —Desktop software installation
- —A district-hosted database
- —A local application server
- —Device management agents specific to TrackStudents
What IT should confirm
- —Modern browser available on staff and kiosk devices
- —Outbound HTTPS to the required domains is permitted
- —Sign-in works on managed devices and profiles
- —Downloads are allowed to district-approved locations
Domains a school network may need to allow.
Notes for filtering
- —All traffic is outbound HTTPS from the browser
- —Kiosk tablets need the same application access, nothing more
- —Blocking Skool removes help links only
Ask before allowlisting
- —Confirm the exact host names with TrackStudents before locking a policy
- —Re-review if any future SIS or SSO integration is enabled
What exists today — and what does not.
Current direct connection
CURRENT DIRECTTrackStudents communicates directly with this service today.
- —Supabase — authentication, database, storage
- —Stripe — subscription and billing
- —Transactional email delivery
- —Skool — training and help links
- —Search Console — public site indexing
Current outbound handoff
CURRENT HANDOFFFiles leave TrackStudents and a person moves them. There is no live API connection.
- —PDF / printed reports
- —CSV exports
- —Workspace archive
- —Manual Schoology workflow
- —Manual PowerSchool workflow
Future integration target
FUTURE TARGETNot built and not operational. Load and privacy impact are TBD.
- —Google SSO
- —Microsoft SSO
- —Schoology API
- —PowerSchool API
- —District SIS synchronization
- —LMS APIs and district reporting feeds
Exports are files, not APIs. No student information is transmitted to Schoology, PowerSchool, or any SIS by TrackStudents today.
The short version for a review meeting.
Architecture
- —Browser-based application over HTTPS — no local install
- —Supabase Postgres with row-level security as the record store
- —Server functions handle validated and privileged operations
- —Timeline and audit records preserve classroom history
- —File storage for uploaded and generated documents
Boundaries
- —Four school-facing access points: Admin, Teacher, Support Staff, Kiosk
- —Kiosk is restricted to pass events only
- —Stripe, Skool and Search Console receive no classroom records
- —Exports are the point where records leave the system
- —No AI model calls in classroom workflows
Follow the education record through its life.
STUDENT RECORDInformation that may be an education record
- —Student name and class membership
- —Grades, notes, incidents, redirections, positive documentation
- —Pass records and student timelines
- —Reports and exported files
How to read this slide
TrackStudents is not FERPA certified, PPRA certified, or government certified — no such certification exists for software. This overlay shows where FERPA-related obligations intersect with the architecture, using the framing published by the U.S. Department of Education's Student Privacy Policy Office (studentprivacy.ed.gov). Districts remain the steward of their own education records.
Where privacy is decided in the architecture.
Checkpoints
- —Authentication — only authorized users enter protected areas
- —Role assignment — access matches role and legitimate educational purpose
- —Classroom / workspace boundary — users see only their scope
- —Database + row-level security — policies enforce the boundary
- —Teacher and support staff views — appropriate records only
- —Admin interface — school-wide access limited to authorized staff
- —Student kiosk — minimum necessary display
- —Timeline / audit — historical records stay controlled
- —Reports and exports — the major disclosure boundary
- —Storage — access, retention and deletion rules
- —Future SIS / LMS exchange — district review before activation
Questions your district should ask us.
PPRA — a design consideration
Normal TrackStudents workflows are classroom documentation by staff, not student surveys. PPRA becomes relevant if the product later collects student responses through surveys, questionnaires, evaluations, forms, or assessments touching protected personal topics.
If such functionality is ever introduced, it should be flagged for school and district review before use.
Review checklist
- —Can school devices reach every required TrackStudents endpoint?
- —Does authentication work on managed devices and profiles?
- —Are role boundaries behaving correctly for each staff type?
- —Does the kiosk work reliably on school tablets?
- —Can authorized users generate and download reports?
- —Are downloads landing in district-approved locations?
- —Are student records isolated from billing, training and public services?
- —Which domains require network allowlisting?
- —Which services receive student information — and which explicitly do not?
- —What future integration would require a new district review?
Security rating by data path.
Baseline controls the system requires: HTTPS, authentication, sessions, role validation, row-level security, workspace isolation, backup and retention.
Paths that create, view, aggregate or export student information: teacher and admin dashboards, support staff access, kiosk, timelines, PDF and CSV exports.
Little or no exposure to classroom records: Stripe, Skool, Search Console, public website. Minimal exposure — not minimal security.