Last verified: 28 September 2026

Onboarding flow disclosure

Sovern's participant onboarding model — auto-projected from canonical registries. Substrate ships only the closed state machine, signup vectors, consent categories, and signed-bundle ceremony shapes; no flow content is hardcoded.

Generated from lib/registry/onboarding-states-registry.ts, lib/registry/entry-vectors-registry.ts, lib/registry/consent-categories-registry.ts, lib/registry/terms-acceptance-bundle-kinds-registry.ts

The §FF participant lifecycle

Sovern's onboarding is participant-keyed (not org-keyed): the 7-state lifecycle below applies to every participant who ever signs up, regardless of which organization or space they later join. Personal-space provisioning (per §A4 Q.sub7) precedes any org-membership decision.

Onboarding states (7)

State 1 — Pre-auth

key: pre-auth
Anonymous visitor; no participant identity yet (cookie-banner consent in localStorage only).
terminal: no

State 2 — Authenticated

key: authenticated
Credentials verified (email or federation SSO); participant row exists; no terms acceptance yet.
terminal: no

State 3 — Terms accepted

key: terms-accepted
Participant has signed the operator's terms-of-service; signed evidence bundle persisted (FF.sub5).
terminal: no

State 4 — Personal space provisioned

key: personal-space-provisioned
Personal space row exists in `spaces` with `space_type='participant'` + `owner_participant_id` (per §A4 + Q.sub7).
terminal: no

State 5 — Primary context chosen

key: primary-context-chosen
Participant has selected an org / space context (self-serve org-creation, invite acceptance, or admin-provisioned membership).
terminal: no

State 6 — First productive action

key: first-productive-action
Participant has performed at least one substantive action in their primary context (configurable per expression / baseline).
terminal: no

State 7 — Complete

key: complete
Onboarding fully concluded; subsequent surface decisions are normal product UX, not onboarding.
terminal: yes

Entry vectors (5)

Closed signup vectors per FF.sub6 deployment-mode-aware signup. Each vector carries an allowed-deployment-modes allowlist (saas / on-demand / on-prem / air-gapped / jv-bespoke); attempting to use a vector outside its allowlist is rejected at the substrate layer.

self-serve — Self-serve signup

Anonymous visitor signs up via `/signup` page. Available in `saas` and `on-demand` modes; absent in `air-gapped` (FF.sub6).

invite — Invite-token acceptance

Participant accepts an invite token (`/invite?token=...`); arrives at exactly one space per FF.sub4 (`org_invitations.space_id`).

federation-sso — Federation SSO

Participant authenticates via federation cluster (V protocol); does NOT re-onboard if existing identity per FF.sub8 (`participant.terms-accepted.v1` event replicated).

admin-provision — Admin-provisioned

Operator (substrate-operator or org admin) provisions a participant account; first-time-login completes onboarding from state `authenticated` skipping `pre-auth`.

on-prem-first-run — On-prem first-run wizard

Initial substrate-operator setup on a fresh on-prem deployment (`/system/first-run` per FF.sub7); writes `substrate_readiness_state` row.

Consent categories (4)

The closed 4-category cookie-consent surface per FF.sub9 — mirrors the §LL.sub1 telemetry buckets exactly. Server-side persistence is wired by the FF-iii consent service (no third-party CMP).

necessary — Necessary

Strictly necessary cookies and storage required for the application to function (auth tokens, session state, CSRF tokens). Cannot be disabled.
required: yes

functional — Functional

Preference and personalization storage (theme, locale, last-visited section). May be disabled with degraded UX.
required: no

analytics — Analytics

Anonymized usage telemetry (route navigation, error rates) per §LL `analytics` consent bucket. May be disabled with no functional impact.
required: no

marketing — Marketing

Acquisition and conversion tracking per §LL `marketing` consent bucket. Off by default; participant must explicitly opt in.
required: no

Terms-acceptance bundle

The §FF.sub5 signed evidence bundle is the only mechanism by which participants accept the operator's terms-of-service. The bundle kind below is verified by the §GG verifyComplianceEvidence()primitive on every read.

participant-terms-acceptance

Manifest fields: participant_id, terms_version, accepted_at, ip_anonymized, user_agent_anonymized. Anti-PII: raw IP and raw User-Agent are NEVER persisted (per §LL.sub7).

This page is generated by a server component and is auto-validated against the four registries by guard:trust-onboarding-page-matches-registry (BLOCKING). A future amendment can never silently drift from the substrate surface.