openSchool

osbe.dev · shared academic services

One trusted academic core for every learning app.

openSchool is the public identity for osbe: the API and SDK layer that lets SDC, KDS, OSFE, Emerjax, and future tools share one safe source for students, course sections, groups, and learning activity.

View the vision Command catalogue ↗ Brand API ↗

Why osbe exists

Applications should not each keep their own version of school.

When every app imports its own roster and account records, cutover becomes risky. OSBE keeps the shared academic facts in one place while each app keeps the workflow that makes it useful.

1

One academic model

Institutions, terms, courses, sections, people, registrations, and groups have one canonical home.

2

App-specific experience

SDC can focus on projects and reflection. KDS can focus on course delivery. OSFE can become the human-facing OSBE interface.

3

Adoption without data loss

Cutovers can compare old and new sources, preserve credentials and preferences, and only switch routes when evidence says they match.

What OSBE is becoming

A small slide deck for the shape of the system.

Use the tabs to step through the intent. This is a public-facing overview, not an ERD or a data dictionary.

01 · Identity

openSchool is the visible name. osbe is the backend service.

The mark is built around transformation, growth, and inquiry: a shared layer that helps student records become useful without making each application reinvent them.

02 · Shared core

Connected apps call the same academic truth.

Each app gets an API key with only the commands it needs. User sessions carry human context. The service checks both before returning data.

  • application identity
  • user/session context
  • command allowlists

03 · Safe migration

Adoption happens in proof-backed slices.

OSBE can be fed known-good roster data, then compared against SDC and KDS before routes change. Credentials, go-by names, and local preferences are preserved from the applications that already know them.

04 · Trust boundary

Available does not mean certified.

Commands move from API-available to runtime-certified only after evidence shows authentication, authorization, response shape, error behavior, release id, and no unexpected writes.

05 · Future shape

OSFE becomes the human interface.

The web front end should call OSBE from a server-side boundary, not with privileged keys in browser JavaScript. People use OSFE; applications use the OSBE API.

API and SDK layer

Small surface, strong boundary.

Every app uses an admitted key.

SDC, KDS, Emerjax, OSFE, and local operator tools should each have their own key. OSBE stores only token hashes and checks a command allowlist before execution.

  • Application token: proves which system is calling.
  • User session: proves the person/context for scoped data.
  • Runtime certification: proves a command has passed evidence for a release.