Heliosync SchoolOS
The digital layer of a whole school.
SchoolOS carries a school’s students, academics, examinations, finance, people, transport and communication as one connected system — and the school’s public website with them. Everything you would expect from a school ERP is inside it. The rest of it is what an ERP was never shaped to reach.
Live
Positioning
An ERP keeps records. A school is not its records.
School software is usually bought by an office and used by an office. It holds admissions, fees and marks accurately, and everyone else in the building — the teacher with a timetable, the student with homework due, the parent who wants to know whether the bus came — is outside it, reached by a printout or a phone call.
SchoolOS is built the other way round. The record is central and everyone who has a legitimate reason to touch it gets their own way in, seeing only their own surface of it. The office keeps everything it had; the rest of the institution stops being downstream of it.
An ERP can manage a school. SchoolOS is designed to connect one.
Everything you expect from a school ERP is here — admissions, attendance, examinations, fees, payroll, reports — expanded into a complete digital operating system for the institution around them.
School operations
Eleven domains, and what is actually in each one.
Screens, not adjectives. Each list below is what the software contains, named the way it is named inside it, so it can be checked against the work an office does today. Nothing is implied by omission — if it is not listed, it is not there.
Students
Where the record begins, and the only place it begins.
- All students
- Admissions
- Online registration
- Promotions & transfers
- Bulk upload
- Roll-number assignment
- ID cards
Attendance
Students and staff on the same mechanism, daily and monthly.
- Student attendance
- Attendance register
- Monthly register
- Staff attendance
- Staff register
Academics
The structure a school year is actually taught in.
- Classes
- Class sections
- Class subjects
- Subjects
- Elective subjects
- Mediums
- Streams
- Shifts
- Semesters
- Class groups
- Timetable
- Teacher timetable
- Lessons
- Lesson topics
- Homework & assignments
- Submissions
Examinations
Built on the academic structure rather than reported beside it.
- Exams
- Exam timetable
- Marks entry
- Bulk marks upload
- Results
- Grades
- Online exams
- Question bank
- Bulk questions
Finance
What is owed, what came in, what went out, and what is paid.
- Fees
- Fee types
- Fee structure
- Fee payments
- Optional fees
- Transactions
- Expenses
- Expense categories
- Payroll
- Payroll settings
People
Teachers, staff and guardians as records, not as logins.
- Teachers
- Staff
- Guardians
- Leave requests
- Leave reports
- Bulk upload
- ID cards
- Certificates
- Salary structure
Transport
A route is part of a student's record, and so is its fee.
- Vehicles
- Routes
- Pickup points
- Route–vehicle assignment
- Drivers & helpers
- Transport requests
- Transport fees
- Transport expenses
Communication
Reaching the school without leaving the system that knows it.
- Announcements
- Student diary
- Diary categories
- Notifications
Reports
Read out of the record, so there is nothing to reconcile.
- Student reports
- Examination reports
- Expense reports
Website
The public front door, managed from the same place as the office.
- Pages
- Gallery
- Sliders
- Public school site
Settings
The definitions everything else in the year reads from.
- School settings
- Session years
- Holidays
- Roles & permissions
- Custom form fields
- Certificates
Everything connected
One student, ten stages, one record.
Any vendor can sell eleven modules. The question worth asking is what happens between them. This is one student’s record from the day it is created to the day it is reported on — and it is the same record at every stop, never a copy of it, never a re-entry of it.
-
Admission
A registration arrives online through the school's own site, or is entered at the desk. Either way it creates one record, and that record is the one every screen below reads.
-
Profile
Roll number, guardian, documents, ID card. Nothing here is re-keyed later: the ID card and the certificate are printed from the same fields the admission created.
-
Class and section
Class, section, medium, stream, shift and semester, with core and elective subjects attached. This is the join that decides what the rest of the year means for this student.
-
Attendance
Marked against the class the student is actually in. The daily register and the monthly register are two readings of one set of marks, not two places to keep them.
-
Academics
Timetable, lessons, lesson topics, homework and submissions — all resolved through the class and section above, which is why a transfer changes a student's whole timetable in one move.
-
Examinations
Exam timetable, marks entry, grades and results, computed against the subjects the student is actually enrolled in rather than against a spreadsheet built alongside them.
-
Fees
The fee structure is defined per class, so assigning a class assigns the fees. Optional fees, payments and transactions land on the same student, in the same ledger.
-
Transport
A route and a pickup point become part of the record, and the transport fee joins the fees already there instead of being collected separately and reconciled later.
-
Parent communication
Announcements, the student diary and notifications reach the guardian attached at admission. The parent is not told to check a second system.
-
Reports
Student, examination and expense reports are read out of the record rather than assembled from it. Nothing was exported, so nothing can disagree.
This is the part that does not survive being assembled from separate tools. A school running admissions in one system, fees in another and marks in a spreadsheet has the same eleven capabilities and none of the connections — and the connections are where the work of the office actually goes.
For everyone in the school
Six portals over one system.
Not six products and not one screen with things hidden on it. Each role signs into its own surface, and the boundary is enforced by roles and permissions on the server rather than by which links are on the page.
Super Admin
Sits above the schools rather than inside one. Creates a school and provisions it with its own database, so one school's records are not a filtered view of another's.
School Admin
The whole institution: admissions and students, academics, examinations, finance, people, transport, the website, and the settings that define the session year everything else runs on.
Teacher
Their own timetable, their classes and sections, attendance, lessons and lesson topics, homework and its submissions, marks entry and the diary. Not the payroll, not the expenses.
Staff
The desk: admissions and registrations, fee payments and transactions, expenses, leave requests, certificates and ID cards — bounded by roles and permissions rather than by convention.
Student
Timetable, lessons, homework and submissions, attendance, exam timetable and results, fees, online exams, the diary and announcements. Their record, from their side.
Parent
Their child's attendance, homework, results, fees and diary, and the school's announcements. The same record the teacher marked, not a summary of it mailed out afterwards.
One database per school
SchoolOS is multi-school, and a second school is not a column on a shared table — it is provisioned with its own database. One school’s records cannot be reached from another school’s session even by accident, which is a property of how it is deployed rather than a promise about how it is queried.
The session year is a concept
Session years, holidays, classes and the fee structure are defined once in settings and read by every module that depends on them. Promoting a cohort at the end of the year is an operation the system has, not a migration somebody performs on it.
The digital school day
What the building does differently on the second week.
Not a change of policy — a change of where the day happens. These are existing screens, described as the routine they replace.
Admission without a form to post
Online registration runs on the school’s own public site and lands in admissions as a record, with custom form fields where the school asks for something the software did not think of.
Homework that has a submission
Homework and assignments are set against the class and its subjects, and submissions come back into the same place — so “did they hand it in” is a field rather than a memory.
Examinations that can run on screen
Online exams draw from a question bank, with bulk question upload for the papers a department already has written. Marks entry and bulk marks upload both exist, because not every exam is going to be online.
The diary, delivered
The student diary, its categories, announcements and notifications reach students and guardians through the portals they already sign into — the same record, read from their side of it.
Digital presence
The school’s website is part of the system, not a project beside it.
Most schools run their public site somewhere else entirely: a separate builder, a separate login, and usually a separate person who is the only one who can update it. The gallery goes stale, the notices are a term behind, and an admission enquiry arrives as an email that has to be typed into the office system by hand.
SchoolOS includes the public school site. Pages, gallery and sliders are managed from inside the same product that runs the office, and an online registration submitted on the public site becomes an admissions record directly. One system faces the school, and the same system faces the town.
SchoolOS roadmap
What the record could tell the school.
Heliosync is an AI company, and a system holding a whole school’s year in one shape is the right place for that work to land. None of the three below is in the product today. They are listed as intent, marked as intent, and will move into the sections above only when they are real.
Analytics across the record
Attendance, academics, examinations and fees already sit in one shape. What is not there yet is the reading of them together — the year seen as a trend rather than as eleven screens.
Automated reporting
Reports that assemble and arrive on their own schedule instead of being asked for. The reports themselves exist today; what is planned is that nobody has to remember to run them.
Insight where the decision is
Surfacing what the record already implies inside the screen where somebody is acting on it. Designed to be shown its own working, because a school will not act on a number it cannot trace.
Heliosync SchoolOS is built and deployable, and every module named on this page exists in it. There are no screenshots here because the demo is the honest version of an interface — a picture of a screen is a promise about a screen, and the diagrams above are claims about structure, which is a thing we can show. There are no figures on this page either: no schools, no users, no uptime. When there is a number worth quoting it will appear with the date it was confirmed.
Explore SchoolOS
Bring your school into SchoolOS.
The demo runs the real system on fictional students. Twenty minutes inside it will settle more than this page can — and it is the same software a school would be given, not a tour of one.