Atrium · System map

Tutelora Atrium · System map
Atrium: shared platform services A map of what Tutelora’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. Contents The build order, and why (master plan §4) A person: one login, every product An app: from being registered to every call it makes 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 Who uses it: apps first, then people Not in Atrium: left out on purpose, or later by plan Noted, not changed: faults found in TuteCore, and what Campus does better 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. 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. 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

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.

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.

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