The part you never see
on a demo, and feel every day after.
Most education suites are a holding company: several acquired products, a shared logo, and a nightly file transfer between them. Omni Forge is the other thing — one platform that presents ten faces. This page is the honest architecture brief.
Omni Forge ID
One identity for the whole suite. A teacher is provisioned once and has exactly the right access in every application — the SIS, the walkthrough tool, the audit instrument, the tutoring portal. When they leave the district, one action closes all of it.
- Single sign‑on with per‑district branding on the sign‑in page.
- Passwordless email codes — short‑lived, single‑use, hashed at rest, attempt‑capped and rate‑limited per address.
- Identical response whether or not an address has an account, so the sign‑in page cannot be used to enumerate staff.
- One role model honoured by every application instead of re‑implemented in each.
What this removes
Five admin panels to onboard one teacher. Five to off‑board them. A permissions matrix that drifted apart the moment the second product was purchased. A password reset queue that is really an identity problem wearing a helpdesk costume.
Multi‑tenancy, enforced three times over.
One deployment serves many districts. Inside each district, any number of schools. Isolation is not a filter somebody remembered to add to a query — it is enforced independently at three layers, so a mistake at one is caught by the next.
Query layer
The district identifier is injected into every database query automatically from the request context. A developer does not have to remember it, which means a developer cannot forget it.
Database views
Raw data access is scoped by database views bound to the current district, so even a direct query cannot reach across the tenant boundary.
Route guards
Every API route requires an explicit role and permission check before it runs. Access is granted deliberately, never inherited by accident.
settings, branding
inside a district
homeroom, program
many roles
Event‑sourced changes
Meaningful changes are recorded as events, so history is reconstructable and nothing is silently overwritten.
Shared record model
A student, a school, a staff member and a course mean the same thing in every application.
Live projections
Read models kept current for dashboards, so reporting does not have to scan the whole history.
Scheduled workers
Nightly projections, truancy evaluation, dashboard snapshots, asset book values and offsite backups.
Health & monitoring
Service health endpoints and a monitor process, because “is it up” should not require a phone call.
A record, not a copy of a record.
The reason exports exist is that two systems each believe they own the truth. In the Omni Forge suite there is one place a student record lives, and every application reads and writes it directly.
Meridian — governed AI, not bolted‑on AI.
Meridian is a platform service sitting beside the data core, which is why it can reason across attendance, instruction, intervention and outcome at once. Atrium is its district‑facing surface. But the reasoning is the easy half — the half that determines whether a district can actually adopt it is the governance around it.
Bolted‑on AI vs. platform AI
Bolted on: an assistant living inside the gradebook can tell you about grades. Ask it why a cohort’s grades moved and it has nothing to work with.
On the platform: the same question can reach attendance, the coaching walkthroughs in those classrooms, the tutoring hours delivered, and the review findings for that building — because all four are on the other side of the same wall.
Every question runs the same eight stages.
Reported as they happen, not animated on a timer. The stages below are the ones Meridian actually emits.
Classify
Work out what is being asked before anything is read.
Policy preflight
Check what this person may ask at all, given their role and the district’s rules.
Retrieve — as you
Read the connected systems using the asker’s own permissions. Nothing is fetched that they could not fetch themselves.
Reclassify
Re‑assess against what actually came back, because the evidence can change the question’s sensitivity.
Post‑retrieval policy
Apply policy to the evidence itself — a permitted question can still return material that must be withheld.
Route to a cleared model
Pick a model cleared for this data class: Public, Internal, Confidential or Restricted.
Answer
Compose the response from the retrieved evidence.
Validate against sources
Check the answer back against the material it was built from before anyone sees it.
Four data classes
Public, Internal, Confidential, Restricted. Every capability slot is filled by a model cleared for that class, with a declared fallback. A district can see and change which model sits in which slot.
Decisions that may never be automated
A district can mark categories of decision as human‑only. Meridian surfaces those as proposals with a named approver and will not act on them, regardless of confidence.
An inspectable console
Which model fills each slot and what it is cleared for, which systems are connected and at what access level, what may never be automated, and a record of what has actually been asked — restricted to district leadership.
answer
quietly skipped
permitted to see
price per answer
The district data warehouse
Everything the suite records lands in one warehouse, scoped to the district that owns it, queryable in plain English.
Joined by default
Attendance, instruction, tutoring, reviews and outcomes already in one place, already related.
Ask in English
Type the question the way you would say it aloud. The answer comes from live records.
Regenerating reports
Board packets and program evaluations rebuild themselves instead of being reassembled.
Strictly scoped
Every query is bounded by the asking district. There is no path to another district’s data.
A real API, documented and scoped.
Districts are not islands. The suite exposes a district‑scoped REST API so your team can integrate with the state reporting tool, the finance system, the badge printer, or whatever else the building actually runs on.
- Bearer‑token authentication with keys issued by district admins.
- Two scopes — read‑only or full access — chosen per key.
- Hashed at rest. The raw key is displayed once, on creation, and never again.
- Per‑key rate limiting so one integration cannot degrade the district’s day.
- OpenAPI 3.1 spec with a browsable Swagger UI inside the district dashboard.
X‑RateLimit‑Limit: 120
Scope: read
Tenant: resolved from key → district
Bring your hardest architecture question.
Tenancy, data ownership, integration, off‑boarding, exit strategy. We would rather answer it now than have it surface in year two.