A map of what {brand:company}’s products will call instead of building it themselves, and how far each part is built.
Nothing of Atrium’s own is built yet. Each module is discussed and mocked up before any of it is built. Click a module to see its parts;
a badge names the app or release it comes from. Hover the status badge on an unfinished module to see what it still needs.
Shipped Partly built On roadmap Newly scoped
What changed — every build reconciled into this map, newest first
The build order, and why (master plan §4)
Every module passes the same gate: discussed, planned, mocked up, reviewed, and only then built. Billing’s place follows the decision to have it from the start. The rest differs from the spec in two places. It’s all set out in reji/plans/2026-11-06-M00-atrium-master-plan.md.
A person: one login, every product
Click any stage to see how far it is built, the modules behind it and what it leads to. Each stage's % comes live from the module map below.
Main flow
Can’t get in, and back
Back to work
Removed by the organisation
Another product, or a document
Built ≥80%
In progress 60–79%
Planned 30–59%
Not built <30%
This is the journey the spec describes, not what’s built: every stage reads 0% until its module lands in Atrium. Much of it runs in Campus today, in Campus’s own code.
What happens here
Modules
Connects to
An app: from being registered to every call it makes
Click any stage to see what happens there, the modules behind it and what it leads to. Each stage’s % comes live from the module map below.
Every call
Getting an app on
A new key
Back to the next call
What it leans on
Built ≥80%
In progress 60–79%
Planned 30–59%
Not built <30%
People never see this side. Products reach it from their servers, over api.tutelora.com, locked to their credentials and addresses.
What the operator does here
Modules
How often
Connects to
The foundation: step 0, plan AF
The sequence: built in this order, each after its discussion
When triggered: each waits for a named need
Inherited from TuteCore 2.1.1: what every module stands on
How it all connects: one app, nine modules, every product
One app, every product
One codebase, one deployment, one database. Each capability is a module inside it, not a separate service.
A product integrates once: one base URL, one set of credentials, and scopes that decide which modules it may use.
Outside clients are the exception: a GWCL system may use vouchers and links but keep its own login, and sends under its own name.
Who uses it: apps first, then people
Atrium holds broad roles only. Detailed roles, such as class teacher of JHS 2, stay in each product. Roles are rows, never names in code; only the levels are hard-coded.
Not in Atrium: left out on purpose, or later by plan
Noted, not changed: faults found in TuteCore, and what Campus does better