@wildo-ai/saas-models 1.1.4 → 1.1.5

package/dist/esm/config/entity-identity-config.shared.schemas.d.ts

@@ -12,6 +12,7 @@
  *   - entity-identity-architecture-analysis.md §4.2
  */
 import { z } from 'zod';
+import { ExternalAssuranceEnforcement } from '../external-providers/provider-authentication-assurance.shared.schemas';
 import { AuthMethod } from '../security/authentications/authentication.shared.schemas';
 import { CORE_APP_ROLES } from '../security/authorizations/roles.shared.schemas';
 import { CORE_ORG_ROLES } from '../security/authorizations/roles.shared.schemas';
@@ -37,9 +38,49 @@ export declare enum RegistrationAcquisitionChannel {
     INVITATION = "invitation",
     ADMINISTRATIVE_PROVISIONING = "administrative_provisioning"
 }
+/**
+ * @wildo_source:part:start saas.models.config.registration facet:layer:shared facet:audience:app-developer
+ *
+ * WHEN a user type asks a person for their first and last name (#1374). Declared as
+ * `userTypes.<type>.auth.registration.profileNamesCollectedAt`.
+ *
+ * - `REGISTRATION` (the default) — on the sign-up form.
+ * - `ONBOARDING` — after the person has confirmed their address and credential. The sign-up form leaves the names
+ *   out; the account is created without a profile, and the first sign-in stops at the onboarding screen, which asks
+ *   for the names before the account can be used. A person who closes the tab is asked again at their next
+ *   sign-in: whether the names are owed is worked out from the account (does it have a profile yet?), never
+ *   remembered in the session.
+ *
+ * `ONBOARDING` cannot be combined with `additionalProfileQuestions`: those answers are saved WITH the profile, and
+ * at sign-up there is no profile to save them into. The configuration is refused rather than silently discarding
+ * them — ask those questions at `REGISTRATION`, or move them to an in-app guidance survey.
+ */
+export declare enum ProfileNamesCollectionMoment {
+    /** On the sign-up form. */
+    REGISTRATION = "registration",
+    /** At the onboarding screen, after the address and credential are proven. */
+    ONBOARDING = "onboarding"
+}
+/** @wildo_source:part:end saas.models.config.registration */
 /** D-19: Email verification timing. */
 export declare enum EmailVerificationMode {
+    /**
+     * The account is created pending verification and the emailed link is the only continuation. The
+     * registration answer for a new address is the same acknowledgement an already-registered address
+     * receives, so `POST /auth/register` does not reveal which addresses have accounts (#1010).
+     */
     REQUIRED_BEFORE_ACCESS = "required_before_access",
+    /**
+     * The account is created ACTIVE and a new registrant is signed in (or sent to enrollment / onboarding)
+     * by the registration answer itself.
+     *
+     * **This mode reveals whether an address is registered, by construction.** A new address receives a
+     * session and tokens; an already-registered address can only receive the acknowledgement, because
+     * answering it with a session would sign a stranger into someone else's account. No response shaping
+     * can hide that difference, so choosing this mode accepts account enumeration through registration.
+     * Choose `REQUIRED_BEFORE_ACCESS` where that matters. (Password-less registration never honours this
+     * mode, and stays indistinguishable.)
+     */
     DEFERRED = "deferred"
 }
 /** E-10, D-15: How much orgs can override user-type auth methods. */
@@ -53,6 +94,7 @@ export declare const AuthMethodExpandedConfigSchema: z.ZodObject<{
 }, z.core.$strip>;
 export type AuthMethodExpandedConfig = z.infer<typeof AuthMethodExpandedConfigSchema>;
 export declare const MfaPolicyConfigSchema: z.ZodObject<{
+    externalAssuranceEnforcement: z.ZodOptional<z.ZodEnum<typeof ExternalAssuranceEnforcement>>;
     requireMFA: z.ZodDefault<z.ZodBoolean>;
     requireStrongMFA: z.ZodDefault<z.ZodBoolean>;
     acceptableMFAMethods: z.ZodOptional<z.ZodArray<z.ZodEnum<typeof AuthMethod>>>;
@@ -66,6 +108,7 @@ export type MfaPolicyConfig = z.infer<typeof MfaPolicyConfigSchema>;
  * Every user type must author this object explicitly. Acquisition policy is security
  * configuration, so omission must never silently become open registration.
  */
+/** @wildo_source:part:start saas.models.config.registration */
 export declare const RegistrationConfigSchema: z.ZodObject<{
     mode: z.ZodEnum<typeof RegistrationMode>;
     /**
@@ -86,8 +129,64 @@ export declare const RegistrationConfigSchema: z.ZodObject<{
     emailVerification: z.ZodDefault<z.ZodEnum<typeof EmailVerificationMode>>;
     /** R-6: Moved from flat auth field. Blocks self-registration for SSO-managed domains. */
     blockForSSODomains: z.ZodDefault<z.ZodBoolean>;
+    /**
+     * The email domains that may sign themselves up, when an application wants to restrict that (#1222).
+     *
+     * OMITTED means no restriction, which is the correct default for a public application and the only
+     * honest reading of an unauthored field — an empty ARRAY would mean "nobody may register", a state
+     * an application expresses through `registration.mode` instead.
+     *
+     * ## Distinct from `blockForSSODomains`, which answers the opposite question
+     *
+     * `blockForSSODomains` is a DENY derived from another tenant's declaration: it refuses signup for a
+     * domain somebody else has claimed and put behind their identity provider. This is an ALLOW the
+     * application states about itself: only these domains may sign up here. An internal tool restricting
+     * signup to its own company has no SSO-enforced domain to key on and could not express that at all —
+     * enterprise provisioning had such a control and public signup, the one anonymous surface, had none.
+     *
+     * Compared case-insensitively against the address's domain part, whole-string: `acme.com` does not
+     * admit `notacme.com` and does not admit `sub.acme.com`. Subdomains are a separate decision an
+     * application makes by listing them, because a wildcard that quietly admits every subdomain of a
+     * domain the application does not fully control is the failure this control exists to prevent.
+     */
+    allowedEmailDomains: z.ZodOptional<z.ZodArray<z.ZodString>>;
+    /**
+     * Extra profile questions this user type is asked AT SIGN-UP, beyond the name and email (#1371).
+     *
+     * Each is a survey question — `id`, `type`, `required`, `bindToField` — the same declaration an in-app guidance
+     * survey uses, so one question can be moved between sign-up and a later survey without rewriting it.
+     *
+     * `bindToField` names a field of the person's USER PROFILE, which is where the answer is saved. The account does
+     * not exist while the form is open, so the answers travel with the sign-up request and are saved when the
+     * profile is created.
+     *
+     * Refused when the configuration is loaded:
+     * - a question with no `bindToField` — its answer would be collected and thrown away;
+     * - a choice-type question — its answer is an option key rather than a value, so the profile would store the key;
+     * - any question when `profileNamesCollectedAt` is `ONBOARDING` — there is no profile at sign-up to save into.
+     *
+     * Optional; absent and empty mean the same thing.
+     */
+    additionalProfileQuestions: z.ZodOptional<z.ZodArray<z.ZodObject<{
+        id: z.ZodString;
+        ref: z.ZodOptional<z.ZodString>;
+        type: z.ZodEnum<typeof import("..").OnboardingSurveyQuestionType>;
+        options: z.ZodOptional<z.ZodArray<z.ZodObject<{
+            ref: z.ZodString;
+        }, z.core.$strip>>>;
+        required: z.ZodDefault<z.ZodBoolean>;
+        bindToField: z.ZodOptional<z.ZodString>;
+    }, z.core.$strip>>>;
+    /** When the person's first and last name are asked (#1374). See {@link ProfileNamesCollectionMoment}. */
+    profileNamesCollectedAt: z.ZodOptional<z.ZodEnum<typeof ProfileNamesCollectionMoment>>;
 }, z.core.$strict>;
+/** @wildo_source:part:end saas.models.config.registration */
 export type RegistrationConfig = z.infer<typeof RegistrationConfigSchema>;
+/**
+ * The ONE reading of when a user type's names are collected (#1374): the declared moment, else `REGISTRATION` —
+ * the behaviour every user type had before the moment could be declared.
+ */
+export declare function resolveProfileNamesCollectionMoment(registration: Pick<RegistrationConfig, 'profileNamesCollectedAt'> | null | undefined): ProfileNamesCollectionMoment;
 /**
  * Password policy — includes expiryDays (R-8, moved from flat auth field).
  * Defined here (not in app-configuration-shared) to avoid circular dependency.
@@ -136,6 +235,7 @@ export declare const UserTypeAuthPolicySchema: z.ZodObject<{
         enabled: z.ZodBoolean;
     }, z.core.$strip>]>>>;
     mfaPolicy: z.ZodDefault<z.ZodObject<{
+        externalAssuranceEnforcement: z.ZodOptional<z.ZodEnum<typeof ExternalAssuranceEnforcement>>;
         requireMFA: z.ZodDefault<z.ZodBoolean>;
         requireStrongMFA: z.ZodDefault<z.ZodBoolean>;
         acceptableMFAMethods: z.ZodOptional<z.ZodArray<z.ZodEnum<typeof AuthMethod>>>;
@@ -162,6 +262,56 @@ export declare const UserTypeAuthPolicySchema: z.ZodObject<{
         emailVerification: z.ZodDefault<z.ZodEnum<typeof EmailVerificationMode>>;
         /** R-6: Moved from flat auth field. Blocks self-registration for SSO-managed domains. */
         blockForSSODomains: z.ZodDefault<z.ZodBoolean>;
+        /**
+         * The email domains that may sign themselves up, when an application wants to restrict that (#1222).
+         *
+         * OMITTED means no restriction, which is the correct default for a public application and the only
+         * honest reading of an unauthored field — an empty ARRAY would mean "nobody may register", a state
+         * an application expresses through `registration.mode` instead.
+         *
+         * ## Distinct from `blockForSSODomains`, which answers the opposite question
+         *
+         * `blockForSSODomains` is a DENY derived from another tenant's declaration: it refuses signup for a
+         * domain somebody else has claimed and put behind their identity provider. This is an ALLOW the
+         * application states about itself: only these domains may sign up here. An internal tool restricting
+         * signup to its own company has no SSO-enforced domain to key on and could not express that at all —
+         * enterprise provisioning had such a control and public signup, the one anonymous surface, had none.
+         *
+         * Compared case-insensitively against the address's domain part, whole-string: `acme.com` does not
+         * admit `notacme.com` and does not admit `sub.acme.com`. Subdomains are a separate decision an
+         * application makes by listing them, because a wildcard that quietly admits every subdomain of a
+         * domain the application does not fully control is the failure this control exists to prevent.
+         */
+        allowedEmailDomains: z.ZodOptional<z.ZodArray<z.ZodString>>;
+        /**
+         * Extra profile questions this user type is asked AT SIGN-UP, beyond the name and email (#1371).
+         *
+         * Each is a survey question — `id`, `type`, `required`, `bindToField` — the same declaration an in-app guidance
+         * survey uses, so one question can be moved between sign-up and a later survey without rewriting it.
+         *
+         * `bindToField` names a field of the person's USER PROFILE, which is where the answer is saved. The account does
+         * not exist while the form is open, so the answers travel with the sign-up request and are saved when the
+         * profile is created.
+         *
+         * Refused when the configuration is loaded:
+         * - a question with no `bindToField` — its answer would be collected and thrown away;
+         * - a choice-type question — its answer is an option key rather than a value, so the profile would store the key;
+         * - any question when `profileNamesCollectedAt` is `ONBOARDING` — there is no profile at sign-up to save into.
+         *
+         * Optional; absent and empty mean the same thing.
+         */
+        additionalProfileQuestions: z.ZodOptional<z.ZodArray<z.ZodObject<{
+            id: z.ZodString;
+            ref: z.ZodOptional<z.ZodString>;
+            type: z.ZodEnum<typeof import("..").OnboardingSurveyQuestionType>;
+            options: z.ZodOptional<z.ZodArray<z.ZodObject<{
+                ref: z.ZodString;
+            }, z.core.$strip>>>;
+            required: z.ZodDefault<z.ZodBoolean>;
+            bindToField: z.ZodOptional<z.ZodString>;
+        }, z.core.$strip>>>;
+        /** When the person's first and last name are asked (#1374). See {@link ProfileNamesCollectionMoment}. */
+        profileNamesCollectedAt: z.ZodOptional<z.ZodEnum<typeof ProfileNamesCollectionMoment>>;
     }, z.core.$strict>;
     passwordPolicy: z.ZodDefault<z.ZodObject<{
         minLength: z.ZodDefault<z.ZodNumber>;
@@ -201,6 +351,7 @@ export declare const UserTypeDefinitionSchema: z.ZodObject<{
             enabled: z.ZodBoolean;
         }, z.core.$strip>]>>>;
         mfaPolicy: z.ZodDefault<z.ZodObject<{
+            externalAssuranceEnforcement: z.ZodOptional<z.ZodEnum<typeof ExternalAssuranceEnforcement>>;
             requireMFA: z.ZodDefault<z.ZodBoolean>;
             requireStrongMFA: z.ZodDefault<z.ZodBoolean>;
             acceptableMFAMethods: z.ZodOptional<z.ZodArray<z.ZodEnum<typeof AuthMethod>>>;
@@ -227,6 +378,56 @@ export declare const UserTypeDefinitionSchema: z.ZodObject<{
             emailVerification: z.ZodDefault<z.ZodEnum<typeof EmailVerificationMode>>;
             /** R-6: Moved from flat auth field. Blocks self-registration for SSO-managed domains. */
             blockForSSODomains: z.ZodDefault<z.ZodBoolean>;
+            /**
+             * The email domains that may sign themselves up, when an application wants to restrict that (#1222).
+             *
+             * OMITTED means no restriction, which is the correct default for a public application and the only
+             * honest reading of an unauthored field — an empty ARRAY would mean "nobody may register", a state
+             * an application expresses through `registration.mode` instead.
+             *
+             * ## Distinct from `blockForSSODomains`, which answers the opposite question
+             *
+             * `blockForSSODomains` is a DENY derived from another tenant's declaration: it refuses signup for a
+             * domain somebody else has claimed and put behind their identity provider. This is an ALLOW the
+             * application states about itself: only these domains may sign up here. An internal tool restricting
+             * signup to its own company has no SSO-enforced domain to key on and could not express that at all —
+             * enterprise provisioning had such a control and public signup, the one anonymous surface, had none.
+             *
+             * Compared case-insensitively against the address's domain part, whole-string: `acme.com` does not
+             * admit `notacme.com` and does not admit `sub.acme.com`. Subdomains are a separate decision an
+             * application makes by listing them, because a wildcard that quietly admits every subdomain of a
+             * domain the application does not fully control is the failure this control exists to prevent.
+             */
+            allowedEmailDomains: z.ZodOptional<z.ZodArray<z.ZodString>>;
+            /**
+             * Extra profile questions this user type is asked AT SIGN-UP, beyond the name and email (#1371).
+             *
+             * Each is a survey question — `id`, `type`, `required`, `bindToField` — the same declaration an in-app guidance
+             * survey uses, so one question can be moved between sign-up and a later survey without rewriting it.
+             *
+             * `bindToField` names a field of the person's USER PROFILE, which is where the answer is saved. The account does
+             * not exist while the form is open, so the answers travel with the sign-up request and are saved when the
+             * profile is created.
+             *
+             * Refused when the configuration is loaded:
+             * - a question with no `bindToField` — its answer would be collected and thrown away;
+             * - a choice-type question — its answer is an option key rather than a value, so the profile would store the key;
+             * - any question when `profileNamesCollectedAt` is `ONBOARDING` — there is no profile at sign-up to save into.
+             *
+             * Optional; absent and empty mean the same thing.
+             */
+            additionalProfileQuestions: z.ZodOptional<z.ZodArray<z.ZodObject<{
+                id: z.ZodString;
+                ref: z.ZodOptional<z.ZodString>;
+                type: z.ZodEnum<typeof import("..").OnboardingSurveyQuestionType>;
+                options: z.ZodOptional<z.ZodArray<z.ZodObject<{
+                    ref: z.ZodString;
+                }, z.core.$strip>>>;
+                required: z.ZodDefault<z.ZodBoolean>;
+                bindToField: z.ZodOptional<z.ZodString>;
+            }, z.core.$strip>>>;
+            /** When the person's first and last name are asked (#1374). See {@link ProfileNamesCollectionMoment}. */
+            profileNamesCollectedAt: z.ZodOptional<z.ZodEnum<typeof ProfileNamesCollectionMoment>>;
         }, z.core.$strict>;
         passwordPolicy: z.ZodDefault<z.ZodObject<{
             minLength: z.ZodDefault<z.ZodNumber>;
@@ -259,7 +460,6 @@ export declare const UserTypeDefinitionSchema: z.ZodObject<{
         oneOffSessionAllowed: z.ZodOptional<z.ZodBoolean>;
         oneOffSessionMaxDurationMinutes: z.ZodOptional<z.ZodNumber>;
     }, z.core.$strip>;
-    uniqueIdentifier: z.ZodDefault<z.ZodString>;
     defaultAppRoles: z.ZodDefault<z.ZodArray<z.ZodUnion<readonly [z.ZodEnum<typeof CORE_APP_ROLES>, z.ZodString]>>>;
     requiresOrgMembership: z.ZodOptional<z.ZodObject<{
         orgTypes: z.ZodArray<z.ZodString>;
@@ -302,7 +502,21 @@ export type FrontendServiceDefinition = z.infer<typeof FrontendServiceDefinition
  *
  * An ORGANIZATION TYPE is the shape a tenant takes: which user types its members get, which roles
  * exist inside it, whether it can come into existence through sign-up, and how hard it is for its
- * members to prove who they are. Declared as `organizationTypes` in the application configuration.
+ * members to prove who they are. Declared as `organizationTypes` in `wildo.saas.config.ts` — never in the backend
+ * configuration, because the platform reads it to type the organization it seeds for the first administrator.
+ *
+ * ## At least one type, and every organization carries one
+ *
+ * The map may not be empty, and an organization's `type` is required and must name an entry in it. A member of an
+ * organization whose type names nothing here cannot sign in: the type is where that tenant's authentication
+ * restrictions live, and "could not tell" is never read as "no restrictions".
+ *
+ * The first administrator's organization is typed by derivation, never by a separate setting: it gets the one
+ * declared type whose `userTypes` include every one of `bootstrap.firstAdmin.userTypes`, and the configuration is
+ * refused when none or several do. An organization whose stored type resolves to nothing — none stored, or one this
+ * declaration no longer carries — is typed at startup when exactly one type is declared, and the value it replaced is
+ * recorded; with several, the application refuses to start and names them. A member who reaches sign-in anyway is
+ * refused with `authentication_organization_policy_unresolved`, never let through with no restrictions.
  *
  * ## A type only self-creates if it says so
  *
@@ -315,20 +529,20 @@ export type FrontendServiceDefinition = z.infer<typeof FrontendServiceDefinition
  * registration, `AUTO` derived, or `ONBOARDING` deferred to a later step. `defaultOwnerRole` is who
  * the registrant becomes.
  *
- * ## `authOverrides` tightens, and can never loosen
+ * ## `authOverrides`: method choices and restrictive security requirements
  *
- * A tenant may restrict how its own members authenticate, on four axes and no others — enabled
- * methods, MFA policy, password policy and re-authentication freshness. Session length, lockout and
- * registration are NOT organization-overridable.
+ * Organizations may override enabled methods, MFA, password policy and step-up freshness.
+ * Session length, lockout and registration are not organization-overridable.
  *
- * Every axis is most-restrictive-wins on top of the user type, so an organization can subtract but
- * never add. Two directions worth stating because they differ: for step-up, `enabled` is an OR
- * (either side turning it on wins) while `maxAgeSeconds` is a MIN (the shorter window wins), and
- * `methods` intersects — an organization can withdraw an acceptable re-authentication method and
- * never introduce one the user type does not already allow.
+ * Enabled login methods follow the application's `auth.orgAuthMethodPolicy`: RESTRICT_ONLY intersects
+ * with the user type's methods; EXPAND_WITHIN_SET adds only methods allowed by
+ * `auth.expandableOrgMethods`; UNRESTRICTED uses the organization's enabled set. Across organizations
+ * with explicit `authMethodsEnabled` overrides, the resolved sets intersect, including in expansion
+ * mode. An organization without that override does not participate in this method-set intersection.
  *
- * When a person belongs to SEVERAL organizations the sets intersect across all of them, so belonging
- * to a permissive tenant never restores what a strict one removed.
+ * The other axes remain most-restrictive-wins: MFA requirements cannot be removed, password
+ * requirements cannot be weakened, and step-up `enabled` is OR, `maxAgeSeconds` is MIN and
+ * `methods` intersects. Expanding login methods does not expand accepted step-up methods.
  *
  * How a registration-derived organization obtains its initial display name.
  */
@@ -343,12 +557,13 @@ export declare const OrgCreationPolicySchema: z.ZodObject<{
     defaultOwnerRole: z.ZodDefault<z.ZodString>;
 }, z.core.$strip>;
 export type OrgCreationPolicy = z.infer<typeof OrgCreationPolicySchema>;
-/** D-15: Org type auth overrides — Partial, most-restrictive-wins on top of user type. */
+/** Org overrides: login methods follow the application mode; MFA, password and step-up remain restrictive. */
 export declare const OrgTypeAuthOverridesSchema: z.ZodOptional<z.ZodObject<{
     authMethodsEnabled: z.ZodOptional<z.ZodRecord<z.ZodEnum<typeof AuthMethod> & z.core.$partial, z.ZodUnion<readonly [z.ZodBoolean, z.ZodObject<{
         enabled: z.ZodBoolean;
     }, z.core.$strip>]>>>;
     mfaPolicy: z.ZodOptional<z.ZodObject<{
+        externalAssuranceEnforcement: z.ZodOptional<z.ZodOptional<z.ZodEnum<typeof ExternalAssuranceEnforcement>>>;
         requireMFA: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
         requireStrongMFA: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
         acceptableMFAMethods: z.ZodOptional<z.ZodOptional<z.ZodArray<z.ZodEnum<typeof AuthMethod>>>>;
@@ -371,10 +586,18 @@ export declare const OrgTypeAuthOverridesSchema: z.ZodOptional<z.ZodObject<{
     }, z.core.$strip>>;
 }, z.core.$strip>>;
 export type OrgTypeAuthOverrides = z.infer<typeof OrgTypeAuthOverridesSchema>;
-/** G-4: Per-org-type SCIM provisioning (moved from global directoryProvisioningEnabled). */
+/**
+ * G-4: Per-org-type SCIM provisioning (moved from global directoryProvisioningEnabled).
+ *
+ * `syncFrequencyHours` was REMOVED here (#1224): no production code read it — the gate consults only
+ * `.enabled` — so an application could set a sync cadence and nothing would schedule anything.
+ *
+ * It is NOT the per-connection field of the same name, which is live: that one is on
+ * `sso-config.shared.schemas.ts` and is surfaced in the administration view. Two fields, one name, one
+ * of them decorative, is also why this went unnoticed — a search for the name found a reader.
+ */
 export declare const OrgScimProvisioningSchema: z.ZodObject<{
     enabled: z.ZodDefault<z.ZodBoolean>;
-    syncFrequencyHours: z.ZodDefault<z.ZodNumber>;
 }, z.core.$strip>;
 export type OrgScimProvisioning = z.infer<typeof OrgScimProvisioningSchema>;
 export declare const OrganizationTypeDefinitionSchema: z.ZodObject<{
@@ -386,6 +609,7 @@ export declare const OrganizationTypeDefinitionSchema: z.ZodObject<{
             enabled: z.ZodBoolean;
         }, z.core.$strip>]>>>;
         mfaPolicy: z.ZodOptional<z.ZodObject<{
+            externalAssuranceEnforcement: z.ZodOptional<z.ZodOptional<z.ZodEnum<typeof ExternalAssuranceEnforcement>>>;
             requireMFA: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
             requireStrongMFA: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
             acceptableMFAMethods: z.ZodOptional<z.ZodOptional<z.ZodArray<z.ZodEnum<typeof AuthMethod>>>>;
@@ -409,13 +633,13 @@ export declare const OrganizationTypeDefinitionSchema: z.ZodObject<{
     }, z.core.$strip>>;
     scimProvisioning: z.ZodOptional<z.ZodObject<{
         enabled: z.ZodDefault<z.ZodBoolean>;
-        syncFrequencyHours: z.ZodDefault<z.ZodNumber>;
     }, z.core.$strip>>;
     creationPolicy: z.ZodOptional<z.ZodObject<{
         createOnUserTypeRegistration: z.ZodArray<z.ZodString>;
         orgNameSource: z.ZodEnum<typeof OrganizationNameSource>;
         defaultOwnerRole: z.ZodDefault<z.ZodString>;
     }, z.core.$strip>>;
+    ownsApplication: z.ZodOptional<z.ZodLiteral<true>>;
 }, z.core.$strip>;
 export type OrganizationTypeDefinition = z.infer<typeof OrganizationTypeDefinitionSchema>;
 /** @wildo_source:part:end saas.models.config.organization-types */
@@ -425,6 +649,7 @@ export declare const UserTypesConfigSchema: z.ZodRecord<z.ZodString, z.ZodObject
             enabled: z.ZodBoolean;
         }, z.core.$strip>]>>>;
         mfaPolicy: z.ZodDefault<z.ZodObject<{
+            externalAssuranceEnforcement: z.ZodOptional<z.ZodEnum<typeof ExternalAssuranceEnforcement>>;
             requireMFA: z.ZodDefault<z.ZodBoolean>;
             requireStrongMFA: z.ZodDefault<z.ZodBoolean>;
             acceptableMFAMethods: z.ZodOptional<z.ZodArray<z.ZodEnum<typeof AuthMethod>>>;
@@ -451,6 +676,56 @@ export declare const UserTypesConfigSchema: z.ZodRecord<z.ZodString, z.ZodObject
             emailVerification: z.ZodDefault<z.ZodEnum<typeof EmailVerificationMode>>;
             /** R-6: Moved from flat auth field. Blocks self-registration for SSO-managed domains. */
             blockForSSODomains: z.ZodDefault<z.ZodBoolean>;
+            /**
+             * The email domains that may sign themselves up, when an application wants to restrict that (#1222).
+             *
+             * OMITTED means no restriction, which is the correct default for a public application and the only
+             * honest reading of an unauthored field — an empty ARRAY would mean "nobody may register", a state
+             * an application expresses through `registration.mode` instead.
+             *
+             * ## Distinct from `blockForSSODomains`, which answers the opposite question
+             *
+             * `blockForSSODomains` is a DENY derived from another tenant's declaration: it refuses signup for a
+             * domain somebody else has claimed and put behind their identity provider. This is an ALLOW the
+             * application states about itself: only these domains may sign up here. An internal tool restricting
+             * signup to its own company has no SSO-enforced domain to key on and could not express that at all —
+             * enterprise provisioning had such a control and public signup, the one anonymous surface, had none.
+             *
+             * Compared case-insensitively against the address's domain part, whole-string: `acme.com` does not
+             * admit `notacme.com` and does not admit `sub.acme.com`. Subdomains are a separate decision an
+             * application makes by listing them, because a wildcard that quietly admits every subdomain of a
+             * domain the application does not fully control is the failure this control exists to prevent.
+             */
+            allowedEmailDomains: z.ZodOptional<z.ZodArray<z.ZodString>>;
+            /**
+             * Extra profile questions this user type is asked AT SIGN-UP, beyond the name and email (#1371).
+             *
+             * Each is a survey question — `id`, `type`, `required`, `bindToField` — the same declaration an in-app guidance
+             * survey uses, so one question can be moved between sign-up and a later survey without rewriting it.
+             *
+             * `bindToField` names a field of the person's USER PROFILE, which is where the answer is saved. The account does
+             * not exist while the form is open, so the answers travel with the sign-up request and are saved when the
+             * profile is created.
+             *
+             * Refused when the configuration is loaded:
+             * - a question with no `bindToField` — its answer would be collected and thrown away;
+             * - a choice-type question — its answer is an option key rather than a value, so the profile would store the key;
+             * - any question when `profileNamesCollectedAt` is `ONBOARDING` — there is no profile at sign-up to save into.
+             *
+             * Optional; absent and empty mean the same thing.
+             */
+            additionalProfileQuestions: z.ZodOptional<z.ZodArray<z.ZodObject<{
+                id: z.ZodString;
+                ref: z.ZodOptional<z.ZodString>;
+                type: z.ZodEnum<typeof import("..").OnboardingSurveyQuestionType>;
+                options: z.ZodOptional<z.ZodArray<z.ZodObject<{
+                    ref: z.ZodString;
+                }, z.core.$strip>>>;
+                required: z.ZodDefault<z.ZodBoolean>;
+                bindToField: z.ZodOptional<z.ZodString>;
+            }, z.core.$strip>>>;
+            /** When the person's first and last name are asked (#1374). See {@link ProfileNamesCollectionMoment}. */
+            profileNamesCollectedAt: z.ZodOptional<z.ZodEnum<typeof ProfileNamesCollectionMoment>>;
         }, z.core.$strict>;
         passwordPolicy: z.ZodDefault<z.ZodObject<{
             minLength: z.ZodDefault<z.ZodNumber>;
@@ -483,7 +758,6 @@ export declare const UserTypesConfigSchema: z.ZodRecord<z.ZodString, z.ZodObject
         oneOffSessionAllowed: z.ZodOptional<z.ZodBoolean>;
         oneOffSessionMaxDurationMinutes: z.ZodOptional<z.ZodNumber>;
     }, z.core.$strip>;
-    uniqueIdentifier: z.ZodDefault<z.ZodString>;
     defaultAppRoles: z.ZodDefault<z.ZodArray<z.ZodUnion<readonly [z.ZodEnum<typeof CORE_APP_ROLES>, z.ZodString]>>>;
     requiresOrgMembership: z.ZodOptional<z.ZodObject<{
         orgTypes: z.ZodArray<z.ZodString>;
@@ -499,6 +773,22 @@ export declare const FrontendServicesConfigSchema: z.ZodRecord<z.ZodString, z.Zo
     frontendType: z.ZodOptional<z.ZodEnum<typeof AppFrontendType>>;
 }, z.core.$strip>>;
 export type FrontendServicesConfig = z.infer<typeof FrontendServicesConfigSchema>;
+/**
+ * The application's organization types — at least ONE, always.
+ *
+ * ## Why an empty map is refused (#1032, decided 2026-09-14)
+ *
+ * Every organization carries a `type`, and that type must name an entry here. The authentication
+ * policy resolver refuses a member whose organization's type it cannot resolve, because a type is
+ * where an organization's authentication restrictions live and "could not tell" must never read as
+ * "no restrictions". An application declaring no types therefore could not have a single
+ * organization anybody can sign in through — including the one the platform seeds for its first
+ * administrator. It used to be optional, and the platform seeded that organization with no type at
+ * all, which is how every administrator came to be locked out once the resolver fail-closed.
+ *
+ * Authored in `wildo.saas.config.ts` (not the backend config) so the platform, which seeds the first
+ * organization, can read it.
+ */
 export declare const OrganizationTypesConfigSchema: z.ZodRecord<z.ZodString, z.ZodObject<{
     userTypes: z.ZodArray<z.ZodString>;
     availableOrgRoles: z.ZodDefault<z.ZodArray<z.ZodUnion<readonly [z.ZodUnion<readonly [z.ZodEnum<typeof CORE_ORG_ROLES>, z.ZodString]>, z.ZodString]>>>;
@@ -508,6 +798,7 @@ export declare const OrganizationTypesConfigSchema: z.ZodRecord<z.ZodString, z.Z
             enabled: z.ZodBoolean;
         }, z.core.$strip>]>>>;
         mfaPolicy: z.ZodOptional<z.ZodObject<{
+            externalAssuranceEnforcement: z.ZodOptional<z.ZodOptional<z.ZodEnum<typeof ExternalAssuranceEnforcement>>>;
             requireMFA: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
             requireStrongMFA: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
             acceptableMFAMethods: z.ZodOptional<z.ZodOptional<z.ZodArray<z.ZodEnum<typeof AuthMethod>>>>;
@@ -531,13 +822,13 @@ export declare const OrganizationTypesConfigSchema: z.ZodRecord<z.ZodString, z.Z
     }, z.core.$strip>>;
     scimProvisioning: z.ZodOptional<z.ZodObject<{
         enabled: z.ZodDefault<z.ZodBoolean>;
-        syncFrequencyHours: z.ZodDefault<z.ZodNumber>;
     }, z.core.$strip>>;
     creationPolicy: z.ZodOptional<z.ZodObject<{
         createOnUserTypeRegistration: z.ZodArray<z.ZodString>;
         orgNameSource: z.ZodEnum<typeof OrganizationNameSource>;
         defaultOwnerRole: z.ZodDefault<z.ZodString>;
     }, z.core.$strip>>;
+    ownsApplication: z.ZodOptional<z.ZodLiteral<true>>;
 }, z.core.$strip>>;
 export type OrganizationTypesConfig = z.infer<typeof OrganizationTypesConfigSchema>;
 export interface OrganizationTypeRegistrationCreationMatch<TDefinition extends {
@@ -556,4 +847,157 @@ export interface OrganizationTypeRegistrationCreationMatch<TDefinition extends {
 export declare function findOrganizationTypeRegistrationCreationMatches<TDefinition extends {
     readonly creationPolicy?: OrgCreationPolicy;
 }>(organizationTypes: Readonly<Record<string, TDefinition>> | undefined, registeredUserType: string): readonly OrganizationTypeRegistrationCreationMatch<TDefinition>[];
+/**
+ * Why an organization yields no authentication policy — the log-side split of
+ * `ErrorCustomMessageReference.AUTHENTICATION_ORGANIZATION_POLICY_UNRESOLVED` (#1036). Three states, three remedies.
+ */
+export declare enum OrganizationAuthPolicyUnresolvedReason {
+    /** A membership names an organization that cannot be found. Remedy: remove the membership or restore the organization. */
+    ORGANIZATION_NOT_FOUND = "organization_not_found",
+    /** The organization carries no type. The engine types such organizations at startup when one type is declared. */
+    ORGANIZATION_TYPE_MISSING = "organization_type_missing",
+    /** The organization's type names no declared organization type. Remedy: declare it again, or restart so the engine re-types it. */
+    ORGANIZATION_TYPE_UNDECLARED = "organization_type_undeclared"
+}
+/**
+ * Why an organization type could, or could not, be derived — the vocabulary both derivations below
+ * answer in.
+ *
+ * A closed vocabulary rather than `string | undefined`, because the two refusals have different
+ * remedies and a caller has to be able to name them: NONE means the declaration offers nothing that
+ * fits (declare a type), AMBIGUOUS means it offers several and the framework will not choose between
+ * them by record order (narrow the declaration).
+ */
+export declare enum OrganizationTypeDerivationOutcome {
+    /** Exactly one declared type fits; it is `organizationType`. */
+    DERIVED = "DERIVED",
+    /** No declared type fits. */
+    NONE = "NONE",
+    /** More than one declared type fits; they are `candidates`, in declaration order. */
+    AMBIGUOUS = "AMBIGUOUS"
+}
+export type OrganizationTypeDerivation = {
+    readonly outcome: OrganizationTypeDerivationOutcome.DERIVED;
+    readonly organizationType: string;
+} | {
+    readonly outcome: OrganizationTypeDerivationOutcome.NONE;
+} | {
+    readonly outcome: OrganizationTypeDerivationOutcome.AMBIGUOUS;
+    readonly candidates: readonly string[];
+};
+/**
+ * The type of the organization the platform seeds for an application's first administrator.
+ *
+ * DERIVED, never authored: it is the declared organization type whose `userTypes` include every one of
+ * `bootstrap.firstAdmin.userTypes`. An organization type's `userTypes` are what a member of it is
+ * granted, so a type that does not cover the administrator's user types would seed them into an
+ * organization that contradicts who they are. Asking the application author to restate the answer
+ * would be a second copy of a fact the declaration already holds.
+ *
+ * Refuses rather than guesses when several types fit — record order is not a decision.
+ *
+ * ## The owner marker DECIDES, when one of the fitting types carries it
+ *
+ * `ownsApplication` says which organization operates the application, and the organization the
+ * platform seeds for the first administrator IS that organization. So when a fitting type is marked,
+ * the answer is not ambiguous — it is declared, and reading anything else would seed the operator's
+ * own administrator into a customer-shaped tenant.
+ *
+ * This is not a tie-break bolted onto a refusal; without it, an application with a marker would
+ * usually be REFUSED. The natural shape of a case-1 declaration is a marked `company` for the
+ * operator beside an unmarked `workspace` for the tenants that sign themselves up, and both
+ * ordinarily grant the same user types — so both cover the first administrator and `AMBIGUOUS` would
+ * fire on every such application. `AMBIGUOUS` keeps its whole meaning for the unmarked case: several
+ * types fit and NOTHING in the declaration says which, so record order is all that is left and record
+ * order is not a decision.
+ *
+ * Several MARKED types are still ambiguous, and deliberately so. The configuration schema refuses a
+ * second marker, so this can only be reached from a declaration that arrived by another route (a
+ * stored configuration written before the rule, an unparsed runtime input) — exactly the case where
+ * choosing would be a guess dressed as a derivation.
+ */
+export declare function deriveFirstAdministratorOrganizationType(organizationTypes: Readonly<Record<string, {
+    readonly userTypes: readonly string[];
+    readonly ownsApplication?: true;
+}>> | undefined, firstAdministratorUserTypes: readonly string[]): OrganizationTypeDerivation;
+/**
+ * The role that OWNS a newly-created organization of a given type.
+ *
+ * ONE resolution for every door that founds a tenant, because a tenant founded without an owner is
+ * the stranded state `administrative-continuity-floors.md` exists to prevent, and it is reached by
+ * whichever door forgot — not by the ones that remembered.
+ *
+ * There are THREE such doors and they are in two packages, which is why this is a function rather
+ * than a convention: self-service `organizations.create`, the organization derived when a user of a
+ * declaring type registers, and the platform seeding an application's FIRST organization for its
+ * first administrator. The first two already resolved it identically and said so in a comment — *"the
+ * SAME resolution registration uses, so the two creation paths cannot disagree"* — while the third
+ * hard-coded `ORG_ADMIN` and gave every freshly created application an ownerless first tenant, which
+ * its own boot report then reported at CRITICAL forever (#436 established the invariant and fixed two
+ * of its three call sites; `invariant-call-site-enumeration.md`).
+ *
+ * `ORG_OWNER` is the answer when the type declares no `creationPolicy` or no `defaultOwnerRole` —
+ * the same default `OrgCreationPolicySchema` carries, restated here because the seeding lanes reach
+ * types that never passed through that parse (a platform-supplied declaration, a stored
+ * configuration). An application that wants a differently-named founding role declares it once, on
+ * the type, and all three doors follow.
+ */
+export declare function resolveOrganizationFoundingOwnerRole(organizationTypes: Readonly<Record<string, {
+    readonly creationPolicy?: {
+        readonly defaultOwnerRole?: string;
+    };
+}>> | undefined, organizationType: string | undefined): string;
+/**
+ * Which declared organization type OWNS the application, if any.
+ *
+ * The one reader of {@link OrganizationTypeDefinition.ownsApplication}, so every surface that needs
+ * "the owner type" asks the same question of the same declaration rather than re-typing the filter.
+ *
+ * `NONE` is an ordinary, correct answer and the default for every application: most applications are
+ * sold to many tenants and no organization operates them. Only a case-1 application — an internal
+ * tool, or a product extending a suite the operator already runs — declares one.
+ *
+ * `AMBIGUOUS` is unreachable from a configuration the schema parsed (a second marker is refused
+ * there), and is returned rather than resolved for the same reason the derivation above does it: a
+ * declaration that reached a runtime by another route must not have its contradiction silently
+ * decided. Callers fail closed on it; nothing is the owner until an operator repairs the declaration.
+ */
+export declare function resolveApplicationOwnerOrganizationType(organizationTypes: Readonly<Record<string, {
+    readonly ownsApplication?: true;
+}>> | undefined): OrganizationTypeDerivation;
+/**
+ * The type an EXISTING untyped organization receives when the application declares exactly one.
+ *
+ * The narrowest of the three derivations here: it reads only the declaration, so it answers for an
+ * organization about which nothing at all is known. With several declared types it refuses, and the
+ * caller falls through to {@link deriveOrganizationTypeFromMemberUserTypes}, which asks the
+ * organization itself.
+ */
+export declare function deriveSoleOrganizationType(organizationTypes: Readonly<Record<string, unknown>> | undefined): OrganizationTypeDerivation;
+/**
+ * The type an EXISTING untyped organization receives, read from the user types its own members hold.
+ *
+ * ## Why an existing organization is not silent about its type
+ *
+ * {@link deriveSoleOrganizationType} used to be the only answer for an existing organization, on the
+ * reasoning that one "carries no record of which user types it was meant for". Its MEMBERS carry
+ * exactly that record: an organization type's `userTypes` are what a member of it is granted, so a
+ * type that does not cover every user type the organization's members actually hold is a type this
+ * organization cannot be. When that leaves exactly one candidate, nothing is guessed — it is the same
+ * coverage test {@link deriveFirstAdministratorOrganizationType} already applies to the
+ * first-administrator organization, asked of the members instead of the declaration.
+ *
+ * ## Why an empty `memberUserTypes` is NONE rather than a match
+ *
+ * `every` over an empty set is vacuously true, so an organization with no members to read would match
+ * every declared type and, against a single-type declaration, would derive one. That would not be a
+ * derivation from the organization — it would be {@link deriveSoleOrganizationType} wearing this
+ * function's name, reached without reading anything. Absence of a signal is NONE.
+ *
+ * @param memberUserTypes The union of the user types held by the organization's members. The caller
+ *   decides which memberships count; it is the one judgement this function does not make.
+ */
+export declare function deriveOrganizationTypeFromMemberUserTypes(organizationTypes: Readonly<Record<string, {
+    readonly userTypes: readonly string[];
+}>> | undefined, memberUserTypes: readonly string[]): OrganizationTypeDerivation;
 //# sourceMappingURL=entity-identity-config.shared.schemas.d.ts.map