CursusOS / Platform

Four layers, one spine.

The reason the modules behave as one product is that they are not modules.
They are views onto a single record, governed by a single permission model, sitting on a single foundation.

Surfaces

One sign-in, one address. The public website, the staff app, the parent and student app, and scoped portals for governors, inspectors and hirers. One door, different buildings.

Permissions

Role times scope times restricted clearance times purpose. Four layers, not one. Read is a separate action from export, and every temporary grant carries an expiry date.

Domain

Admissions, students, staff and HR, curriculum, attendance, pastoral, inclusion, timetabling, operations, finance, marketing, parents, careers and governance. Fourteen areas, one schema.

Foundation

Group, then school, then person. Google Workspace for identity, Drive for documents, and one relational core underneath every department.

Cross-cutting by design

Some things refuse to belong to one department.

Safeguarding, inclusion, the skills framework, QR identity and notifications are not modules.
They run through everything, which is exactly why they cannot be bought separately and bolted on.

Safeguarding

A concern raised in a lesson, on a bus, at an event or by a parent enters the same protected record with the same clearance rules, whichever door it came through.

Inclusion

Provision, plans and adjustments follow the child into the register, the report, the seating plan and the examination arrangements without anybody copying them across.

Skills framework

Eighteen strands are evidenced from lessons, activities, house events and life outside school, which is what turns a personal development claim into an inspection exhibit.

QR identity

One credential issued at enrolment does transport, canteen, events, library and security, so the same person is the same person at every scanner.

Notifications

Two hundred trigger points, each with its audience, channel and consent state, delivered through one queue rather than seven.

One connected system

Every department, every dependency.

Each point is a workflow or a data entity.
Each line is a dependency the platform maintains, so a change in one department reaches every other one that depends on it.

The connected model

Departments and cross-cutting systems on one schema

304

Data entities, each with its fields, relationships and owner

200

Automation and notification points across the platform

Roles, each mapped across all four permission layers

What the connections do

A dependency is only worth having if it saves somebody an afternoon.

Lesson cover, solved before briefing

An absence is recorded, or a leave request is approved. Nobody presses anything else.

07:04, unattended

Trigger

Absence recorded

A leave approval or a reported illness writes the staff absence. That is the only human action in the chain.

Step one

Timetable read

Every period the absent teacher was due to teach, with its class, room, set and phase.

Step two

Cover found

Staff genuinely free in those periods, weighed by subject, phase and how much cover each has already carried.

Step three

Sheet written

The cover sheet is generated from the absent teacher's own lesson plan, not from a blank template.

Outcome

Everyone told

Cover teacher, head of department and affected classes notified, in their own channel and language.

What it replacesA forty-five minute daily puzzle, done by a human before briefing

The automation layer The permission model

See it running on real data.

A working demonstration on a live database, walked through by the people who built it. Forty minutes, no slide deck.

Book a demo Back to overview

Platform

Recruit and enrol

Run the school day

Teach and assess

Engage the community

Govern and evidence