01
System of Record
One institutional truth.
Students, staff, fees, attendance, assessments and documents live on one model, so a question has one answer rather than one answer per tool.
Category and definition
What is SquareCampus?
SquareCampus is a School Operating System and institutional decision layer for schools, educational trusts and multi-campus groups in India. It includes the operational systems of record institutions expect, but its primary purpose is to connect recurring school cycles to ownership, exception handling, auditability and leadership decisions.
The distinction that matters
A system of record stores what happened. A decision layer shows what requires attention, why it matters, who owns it, and what happens next.
SquareCampus helps school leadership know what requires attention today, who owns it, and what happens next.
How it is organised
Four layers, each with an operational outcome.
SquareCampus is not described by how many modules it contains. It is described by what each layer changes about the way the institution runs.
02
System of Workflow
Work moves with an owner.
Admissions, collections, results, approvals and parent concerns run as workflows with stages, owners and deadlines — not as tasks held in someone's memory.
03
System of Governance
Every exception is accountable.
Policy, approval chains, role boundaries and audit history are institutional configuration, so exceptions escalate to a named desk and leave a trail.
04
System of Intelligence
Leadership sees what requires attention.
AEGIS reads the governed operational context and returns permission-scoped, source-grounded answers about what changed, why it matters and who owns the response.
Dashboard versus decision layer
A bar chart shows a condition. A decision layer explains what to do about it.
This is the difference between reporting that describes the institution and an operating layer that moves it.
A dashboard tells you
- Attendance decreased
- Fees remain pending
- Reports are overdue
A decision layer tells you
- Which campus crossed the threshold
- When the deviation started
- Which workflow is blocked
- Who owns the response
- What evidence supports the conclusion
- What leadership should review next
AEGIS
AEGIS is the governed intelligence layer inside SquareCampus. It produces permission-scoped, source-grounded and auditable operational answers from institutional context.
- Read-only — AEGIS answers questions, it does not act on the institution's behalf
- RBAC-scoped — a person only ever sees what their role already permits
- Source-grounded — every answer points back to the records it came from
- Auditable — questions and answers are recorded like any other institutional action
- Human-controlled — decisions remain with the people accountable for them
What the words mean here
School OS, governance, exception ownership, accountability.
These terms are used across the site with specific meanings. This is what each one commits SquareCampus to.
- School Operating System (School OS)
- The connected backbone an institution runs on. It holds the records a school expects, and it also carries the workflows, ownership, approvals, exceptions and audit history that turn those records into accountable day-to-day operations. The distinction from an ERP is factual: every cycle has stages, an owner and a deadline; every exception is routed to a named desk; every override is recorded with a reason.
- Governance
- Policy, approval chains, role boundaries and audit history held as institutional configuration rather than as habits. A concession limit, a refund approval or a campus-level deviation from trust policy is defined once, enforced on every record, and visible to the people accountable for it.
- Exception ownership
- When a record leaves its expected state (collections behind plan, attendance under a threshold, an approval overdue) the deviation becomes an exception with a named owner, a position and a due date, rather than a line in a report that someone may notice.
- Accountability
- Every approval, override and closure is attributed to a role and a person, recorded with the reason, and kept on an append-only timeline. Leadership can see not only what happened but who decided it and on what basis.
- Institutional visibility
- Leadership sees the current position of the institution from the records the campuses run on, without a department preparing a report first: what requires attention, why it matters, who owns it and what happens next.
- Multi-campus governance
- More than supporting several campuses. Trust, school and campus are one hierarchy; policy is set once and executed locally; scope is a property of the role; exceptions and board views cross campuses without consolidation.
Multi-campus governance versus supporting multiple campuses
| Dimension | Supports multiple campuses | Multi-campus governance |
|---|---|---|
| Structure | Each campus is a separate instance or a branch code on the same records | Trust, school and campus are one hierarchy in the institutional model |
| Policy | Head office circulates a policy; each campus configures its own version | Policy is set once at the trust level and inherited; local variation is recorded as an exception with a reason |
| Access | Campus users are separated by login | Scope is a property of the role: a principal sees one campus, a trust officer sees across campuses, on every screen, report and AEGIS answer |
| Exceptions | Each campus escalates by phone or email | Collections behind plan, attendance drift and stalled approvals surface as owned exceptions, whichever campus they belong to |
| Reporting | Campus reports are consolidated before the board meeting | Board views come from the records the campuses run on, with nothing to reconcile first |
Direct answers
The questions people ask before they know what to call it.
Is SquareCampus an ERP?
SquareCampus includes the core record and workflow capabilities commonly expected from institutional ERP software. However, it is designed and positioned as a School Operating System: a connected operating backbone where school cycles, ownership, exceptions, governance and leadership visibility share one institutional model.
What is a School Operating System?
A School Operating System is the connected operating backbone an institution runs on. It holds the records a school expects, but it also carries the workflows, ownership, approvals, exceptions and audit history that turn those records into accountable day-to-day operations.
What is an institutional decision layer?
A system of record stores what happened. A decision layer shows what requires attention, why it matters, who owns it, and what happens next. SquareCampus is built to do both, so leadership does not have to assemble context before acting.
Who is SquareCampus built for?
Indian schools, educational trusts, church-run school groups and multi-campus institutions, and higher-education institutions as a governed layer over the systems they already run. It suits institutions that care about operational control, accountable ownership and leadership visibility — whether they run one campus or many. It is not designed for an institution that needs only basic attendance, fees and report cards at the lowest possible price.
Is AEGIS a chatbot?
No. AEGIS is the governed intelligence layer inside SquareCampus. It produces permission-scoped, source-grounded and auditable operational answers from institutional context. It is read-only, constrained by the asker's existing role permissions, and does not take autonomous decisions.
Can SquareCampus replace our existing school ERP?
Institutions commonly move to SquareCampus from a school ERP, a set of disconnected tools, or a mix of both. Migration scope, sequencing and how long the existing system runs alongside are agreed during discovery rather than assumed.
What does SquareCampus mean by governance, exception ownership and accountability?
Governance is policy, approval chains, role boundaries and audit history held as institutional configuration. Exception ownership means a deviation from the expected state becomes a routed item with a named owner, a position and a due date. Accountability means every approval, override and closure is attributed to a person and a role, recorded with the reason, on an append-only timeline.
How does multi-campus governance differ from supporting multiple campuses?
Supporting multiple campuses means the software can hold several campuses' records. Multi-campus governance means trust, school and campus are one hierarchy: policy is set once and executed locally with deviations recorded as exceptions, access scope is a property of the role, and exceptions and board views cross campuses from the same records without consolidation.
Next step
The fastest way to understand a School OS is to point it at a real bottleneck.
Bring one cycle that consistently costs your institution time — collections, results, attendance follow-up or parent escalations — and we will map what a governed version of it looks like.