Application shell prototype
Table of Contents
- 1. Summary
- 2. Detail
- 3. See also
| Item | Where |
|---|---|
| Prototype | the prototype |
| Gemini review | the review |
| Group | Tenancy prototypes |
1. Summary
Every journey in the catalogue reaches its screen by the person "choosing" it, and no document owned how. This is the answer, as one design rather than a comparison: a menu across the header, the cards it opens, and the person's own journeys under their name and photo.
What the shell shows is decided by who signed in. A super administrator works in the system tenant's context, a tenant administrator in a tenant's, and a party user in a party's — the contexts the server already scopes everything by. So the mode is read from the sign-in and is never chosen, and there is no mode switch to get wrong.
It is throwaway. It is not production code, it reads no service, and every value on it is mock data.
Open the shell.
2. Detail
2.1. The verdict
Accepted on 2026-10-01: the menu, the cards and the avatar, with the mode read from the sign-in. This is the shell the Profile journeys hang from, and the implementation is scheduled from it.
2.1.1. Revised on 2026-10-04
The first screens built from this shell spoke the implementation's language: the landing page counted journeys and drew one card for each, and a system administrator reading a tenant was asked to enter it and leave it. The Home screen prototype replaces the landing page and the cards. Home shows the state of the work, the areas hold screens and buttons named for what a person does, Tenants is one list with Add tenant and Remove tenant on it, and a tenant opens in place with its session held behind the screen.
What stands from this prototype: the menu across the header, the mode read from the sign-in, and the person's own screens under their name. Where this page says journey below, it names how a screen was designed, not what a person sees.
2.2. What was rejected, and why
The page went through four review rounds. Each rejection is the reason the design is what it is, so they belong in the record even though the shapes themselves are not drawn any more.
| Shape | Why it went |
|---|---|
| An account menu holding every journey | At twenty journeys it holds neither the administrator's work nor the groups, and its trigger tried to answer a question about the account rather than about the product. |
| One axis of journey groups across the header | A journey group is a topic ("Profile", "Credentials"); an area of activity is above it ("Reference Data", "Trading"). A trading system has the areas, and the Qt client's first level already said so. |
| A sidebar beside the area's cards | It listed the same journeys the cards already list, one beside the other. The cards are the navigation; a second copy of them is a cost with no reader. |
| "Administration" as an area | A name that means everything we could not place. The scopes are Me, People and Tenant, and they account for all twenty journeys with nothing left over. |
| Bootstrap as an area | The first run journey belongs to a plain installation, where there is no account to sign in with and so no shell to draw a menu in. An area nobody can be in while it is open is a door, not a destination. |
| A mode the person chooses | The mode is the context the server already scopes everything by — the system tenant, the tenant, the party the session acts for. Reading it from the sign-in is the only version that cannot disagree with the data. |
2.3. The mode comes from the sign-in
| Sign in as | Mode | The context |
|---|---|---|
| Super administrator | System administration | The system tenant: the deployment's tenants, the registry they share |
| Tenant administrator | Tenant administration | A tenant: its parties, its role catalogue, its settings — not its data |
| Privileged party user | Application | A tenant and a party, including the people who work in it |
| Regular party user | Application | A tenant and a party |
The four are the platform's own axes, not a new taxonomy. The system tenant has a fixed id and holds the deployment's registry and the shared reference data; a tenant row is stored under it; and the session already carries the party it acts for. A mode is the answer to "which context am I in", and the server answers it before the browser draws anything.
2.4. The menu holds areas, and the cards hold journeys
The menu is one row of areas — the trading floor's own shape, which the Qt menu bar already had right. It changes with the mode:
| Mode | The menu |
|---|---|
| System administration | Accounts, Tenants |
| Tenant administration | Parties, Access, Tenant |
| Application | Reference Data, Market Data, Trading, Analytics, Compute, Reporting, People |
An area the catalogue has not reached stays in the menu and says so in as many words. An area that belongs to somebody else does not: a regular party user is not shown the door to the people of their party, and no mode offers an administrator journey to the person who may not run it.
2.4.1. The bootstrap journey is not an area
First run was drawn under a Bootstrap area, and that was wrong. It belongs to a plain installation: an empty database with no account in it. Nobody can be signed in while it is the screen, so it is not a place the shell can be in and not a door the shell can offer. It is the way out of the state the shell cannot be entered from, and that makes it a door rather than a destination.
The system administrator's work is what the first run leaves behind: a deployment with an account, and no tenant until one is made. So the Tenants area is the whole of the system administration menu, and it holds the tenant journeys the catalogue has: reading the roster, creating a tenant, and retiring or resetting one. Tune the tenant is not among them — the tenant administrator maintains their own tenant's details, from inside it.
2.4.2. The deployment's own accounts are an area
The Qt menu bar kept the deployment's own accounts on a first-class screen, under its User Accounts area, and the audit of the super administrator's journeys found that the web had lost that door: with the Tenants area as the whole of the menu, the services the installation runs on are reachable only by opening the system tenant from the roster. The area gains Accounts, and the "the Tenants area is the whole of the system administration menu" decision above is revisited with it. Nothing new is read: the accounts read is the session's own tenant, and the session's tenant for a system administrator is the system tenant. The story Complete the super administrator UX journeys carries the change.
2.4.3. The roster is its own journey
See the tenants was not in the catalogue when this menu was first drawn, and that was a gap rather than a decision. The list existed only as step 1 of Retire or reset a tenant, which meant the only way to find out what tenants a deployment holds was to open a destructive journey. The regime that has the roster has it as a read-only screen of its own, and the catalogue's own idiom agrees: See who has access is the same shape for the people of a party.
So the roster is the first card in Tenants, and Retire or reset a tenant picks its tenant from it. It is a change to the catalogue and not only to the menu, and the journey document records why.
This is the one place the extraction's grouping was not the menu's grouping, and the correction is recorded here rather than in the catalogue: the catalogue's Setup group and its Tenancy group both hold journeys the Tenants area offers, because a group is what a designer looks a journey up under and an area is where a person goes to find it.
The cards are one per catalogue topic, and they are where a journey is chosen. One area's cards, or every area's, depending on whether the person picked an area from the menu or is on the landing page.
2.5. The person's own journeys are not an area
Every system puts "things about me" under the avatar, and nobody gives them a menu. The header carries the person's name and photo, and it opens their own journeys, gathered by topic: profile, credentials, and in a party their access and where they work. The super administrator keeps their profile and gets no party journeys, because there is no party to choose.
2.6. The three states
| State | What it shows |
|---|---|
home |
The landing page: every area the person has, each with its cards. |
journey |
One journey running under its mode, with the cards it came from. |
fullscreen |
A journey that stands something up. It owns the screen, so no menu and no cards are drawn. |
2.7. What is real and what is not
The areas, the journeys, the modes, the routes and which journeys have been built are the catalogue's own. Six of the eleven areas are empty because the extraction has been run for one component, and the prototype renders that rather than inventing screens to fill them.
Everything else is mock. The people, the tenants and the parties are invented, the photos are the repository's own stock faces, and nothing reads a service.
2.8. Where the code lives
doc/prototypes/tenancy/navigation/. Three files of code plus the two photos, plain
HTML, CSS and JavaScript, no framework and no build step. The site build copies
the directory through ores-deploy-web-app, beside the other prototypes.
2.9. What it does not settle
How a person learns that a journey exists but cannot be run. Nothing here states what a deployment switches on or off, because no document says a journey has a switch.
The mode is read from the sign-in, and the contract that delivers it — the server stating the mode with the session, and the menu taking its authority from the permission codes the session holds — is Session modes and capabilities.
How the account a person signs in with comes to be the privileged one. The mode is read from the sign-in, which is only honest if a super administrator's account is distinguishable from a person who happens to hold the role — and today nothing distinguishes them, or says when they held it. That is its own problem, with its own process, and it is captured at Privileged access needs a recorded break-glass process.
Where a party user with no areas of their own lands once the party's data is real: today six of their seven areas are empty and their avatar is where the work is.
3. See also
- Prototypes — the index of every prototype, and where to open each one.
- Profile screen prototype — the screen the avatar opens.
- Journey screen — the vocabulary this design rests on.
- Profile journeys — the group whose journeys name the account menu first.