ADR-0109: Organization Founding Is Its Own Process¶
- Status: accepted (2026-08-09 — his red pen passed: "I read ADR 109. Looks good to me")
- Date: 2026-08-09
- Deciders: Nicolas Burri ("I'd go with […] 'own deliberate act' but I think I would go one step further and make it a process on its own. That is, have a specific workflow that only a global [operator] can see to setup a new organization. When starting a new project, only ask the user to select a mandator/organization first, if the user actually belongs to multiple orgs for which he has the rights to create a new project." Undo path: "Yes, narrow delete.")
- Relates to: ADR-0097 (the provisioning surface both processes drive), ADR-0002/0010 (the mandator model — the boundary this protects), ADR-0108 (membership — a newborn organization's first beat), feedback register 2026-07-28 finding #12 (the tenant boundary is never defaulted), register 2026-08-06 #28 (this decision), ADR-0026 / RISK-002 (why the boundary is the top quality goal).
- Amended by: ADR-0122 §4 (§5's "MANAGE_SCOPES keeps … project-scope create" is no longer true — CREATE_PROJECT is its own permission, checked at the target organization's anchor)
Context¶
The setup wizard's new project form asks "which organization?" and its dropdown offers every existing tenant plus an inline "— new organization —" sentinel that reveals a name field. Founding a tenant — a whole isolation boundary with its own membership, audit trail and lifecycle — is therefore one dropdown slip away from a routine act. And the slip is permanent: no in-product removal of a mandator exists at all (grep-verified 2026-08-09 — ADR-0097 built four creation acts and one settings update, nothing that deletes). An accidental organization today is a support case ending in SQL surgery.
This surface has already been hardened once, by the same instinct: finding #12 removed the preselected default because the tenant boundary "could be set by form initialization and committed by a user who never looked at it." This ADR is step two — the boundary must not be creatable as the side effect of a routine act either.
Founding an organization and starting a project are different business processes: one is "a new customer / a new legal boundary exists," the other is routine work inside an existing boundary. The opinionated-system principle (docs/ai/conventions.md) says the tool's structure mirrors the real process rather than merging both into one form.
Decision¶
- Founding an organization is a separate workflow. Its entry is visible only to holders of
MANAGE_SCOPESat GLOBAL (the operator — ADR-0097's authority, unchanged). The workflow founds the tenant knowingly — the person names it in a step that is about founding, nothing else — and then flows onward into the organization's natural first beats (its first project via the project process; its first member via the ADR-0108 membership invite) rather than dead-ending. - The project process can no longer create a tenant. Its organization field lists existing organizations only; the inline "— new organization —" sentinel is removed.
- The organization is asked for only when there is a real choice, and stated always.
- More than one eligible organization → the selector appears, no default (finding #12 holds).
- Exactly one → no question; the boundary is stated as a prominent fact before anything is committed ("This project will belong to: Acme Corp"). The #12 rule — never committed by a user who never looked at it — is honored by prominence, not by a pointless question.
- Zero → the ADR-0097 hand-off shape ("hand to an administrator"), never a silent skip.
- Eligibility is defined against reach — the organizations in which the caller may create
a project. Today
MANAGE_SCOPESis GLOBAL-only, so the condition collapses to "more than one organization exists" and the auto-skip fires mainly on single-organization installs; the wording is chosen so the delegated-org-admin future (ADR-0108 backlog §C2) lands without redefinition. - A narrow, governed undo for the founding mistake.
DELETEof an organization, gated per §5, refused unless the organization is provably empty — no projects, no members, noAmendment (2026-09-09, register row 79): "empty" means nobody ever worked here, not "nothing was ever recorded": the organization's own administrative residue — its anchor-scope trail (destroyed with the org, the V106 §1 ruling one anchor up), terminal memberships and terminal pre-assignments — no longer forecloses the undo of a founding mistake. Anything a person's live standing touches (open/claimed invitations, members, assignments, projects, every record-plane row) still blocks, each asserted. Enforced by V134's definer destroyer; the refusal now names its blockers on the surface. content or configuration rows of any kind (the exhaustive column-and-table inventory is the implementation's derived checklist, per the schema-extension audit discipline). Audited GLOBAL-anchored as
MANDATOR_DELETED, so the trail tells the honest founding-mistake story as aMANDATOR_CREATED/MANDATOR_DELETEDpair. Anything that ever held content stays permanent. - The authority splits with the processes — now, not later (Nicolas, 2026-08-09: "I'd split
the permission now while we are working on it anyway"). One new GLOBAL permission,
MANAGE_MANDATORS("Found and dissolve organizations"), gates the founding workflow's two acts — mandator create and the §4 empty-mandator delete.MANAGE_SCOPESkeeps everything else (project-scope create, type activation, role activation, key-rule seeding, scope settings) and its name. The migration grantsMANAGE_MANDATORSto every role currently holdingMANAGE_SCOPES, so the split is behavior-preserving on day one; its value is that an operator can now withhold founding from a role — and the §C2 delegated-org-admin future receives a project-setup authority that never implied tenant creation. - The history, honestly: a
CREATE_MANDATORpermission existed once — declared in V004 as ADR-0012 vocabulary before any write surface existed, never consumed by anything, retired in V073 as a dead letter when ADR-0097 chose one permission over reviving it. That judgment was right then: there was no second process to protect. This is not that dead letter returning — it is a permission born the correct way around, after its surface and its persona. The name deliberately differs (MANAGE_MANDATORS, the house MANAGE_ verb, covering found and* dissolve) so the V073 story stays unambiguous in the trail.
Non-decisions, made explicit¶
- No other scope becomes deletable. A project delete is NOT decided here — projects hold content almost immediately and their lifecycle is a different question.
- The seed's SQL path is unchanged (bootstrap runs before any authenticated user exists — ADR-0097 §4; the D-5 seed-vs-wizard oracle keeps guarding parity).
Consequences¶
- The wizard restructures into two entries — "set up a new project" (routine) and "found a new organization" (operator) — with the conditional/stated organization step per §3.
- One new provisioning endpoint (the §4 delete) + audit action
MANDATOR_DELETED; the emptiness check ships with its derived dead-end check (the setup-status pattern names a founded-but- memberless-and-projectless organization instead of letting it sit invisible). - One migration: the
MANAGE_MANDATORSpermission row (ADR-0012 closed-set pattern) + grants to every role holdingMANAGE_SCOPES; the mandator-create endpoint's gate moves to it; the wizard's permission-reflected panels reflect per-process authority; the D-5 seed-vs-wizard oracle and the role editor's picker pick the new row up from the table as usual. - The user manual's project-setup topic and the ops/administration guide (#26) gain the two- process story; validation journey station(s) touching project birth follow the new shape.
- Implementation is queued after register #27 (credential self-service): the wizard tree is held by the #22 organization-terminology slice until it lands, and #27 was queued first.