Setup

The setup wizard under /onboarding configures an installation in seven steps. This page describes what each step does, what the wizard writes, and what cannot be changed later.

Before sign-in, NomOS loads the current login configuration. On failure or after five seconds, it uses an available cached configuration or the default provider; explicit emergency sign-in remains available.

The seven steps

Whatever a step sets, it writes to the installation immediately. You can stop at any point and continue later. The wizard reads its state from the installation, not from a session. A step that another route has already completed shows as completed.

1. Signing in as administrator: On /setup you sign in with the local administrator account. This path works even without a configured identity provider and creates a short-lived session.
2. Organization: the name names the tenant and the root room. Both are renamed together, or neither.
3. Workspace: you propose the room hierarchy and edit it. You can rename rooms, pick the kind, and add or remove sub-rooms. Rooms are created only when you create them. Rules inherit downward from each room.
4. Models: you decide whether your material must stay in the country. This decides which data classes a model can serve. You enter the model ID, provider, and API key; each connection is tested once before it is accepted. A monthly limit for the root room is inherited by every room below it.
5. Sign-in (identity provider): the wizard only checks whether your OIDC issuer is reachable and saves nothing. You set up and activate sign-in under Settings → «Identity & SSO». Activation only works after a real test login has proven that you are still an administrator afterwards.
6. Invite people: the wizard creates an account and asks the sign-in service to email a time-limited setup link. Assign room permissions separately afterwards.
7. Scaffold: the platform proposes entries about your organization. For this, it researches through the model gateway, meaning from the model’s training data and without a live lookup. Proposals can be stale or empty. If the step conflicts with your answer on data location, the wizard refuses it and states the reason.

What cannot be changed later

Two decisions are final. The hierarchy is confirmed once before rooms are created; after that, a room’s parent room cannot be changed. A room’s slug is permanent, even after archiving. You can add rooms at any time, but you can’t move them to a different parent.

What the wizard writes

The organization name, rooms, model entries, budget, and invited accounts are configuration: the wizard writes them directly. It does not write the identity provider sign-in. Step 5 only checks whether your OIDC issuer is reachable.

The scaffold in step 7 is different: every proposal lands only as a draft. It becomes knowledge only when a named person accepts it in the import review. Every accepted entry carries its origin (researched during setup, unverified). This way, a researched entry never reads as a decision the organization took.