# Signup and registration

**Flow key:** `signup-registration`

## Outcome

A new eligible person creates exactly one usable account, proves required contact points, and reaches the intended first authenticated state.

## Actors

- Prospective user
- Identity service
- Email/SMS provider
- Optional organization or invitation owner

## Preconditions and entry points

- Registration is enabled.
- The synthetic email/phone is controllable.
- No existing account uses the chosen canonical identity.
- Terms, age, region, invitation, and organization policies are known or marked unknown.

## Required test data

Use synthetic, isolated, resettable data. Never use real credentials, payment instruments, private customer records, or production notifications.

| Data | Canonical valid seed | Critical variations |
|---|---|---|
| User identity | `carbon.signup+001@example.test`, username `carbon_signup_001` | existing, unverified, mixed-case, Unicode, emoticon/emoji, reserved, normalization-equivalent |
| Credential | A product-valid synthetic password | minimum/maximum, passphrase, password-manager generated, compromised/weak if policy applies |
| Profile | Name `CARBON Signup 001`, locale `en-US` | optional omitted, long, RTL, emoji, unsupported locale |
| Consent | Current terms/privacy versions accepted | declined, stale version, missing age/region consent |
| Environment | Fresh browser and synthetic tenant | existing session, blocked cookies, slow network, duplicate tab |

## Canonical steps

Treat this as the ordinary successful path inferred from common product behavior. Adapt it to observed labels, business rules, APIs, and implementation evidence; do not invent a requirement.

| Step | User or system action | Expected evidence |
|---:|---|---|
| 1 | Open the canonical registration entry point. | The page identifies the product, account type, requirements, and sign-in alternative. |
| 2 | Enter valid identity, credential, profile, and required consent data. | Inline help and validation are accurate without losing entered data. |
| 3 | Submit once. | One pending or active identity is created; progress prevents accidental duplicate submission. |
| 4 | Complete required email/SMS verification or invitation binding. | The proof is bound to this account and action, expires, and works once. |
| 5 | Land in the authenticated first-run destination. | Session, account, tenant, defaults, audit, and onboarding state agree. |
| 6 | Sign out and sign in with the registered identity. | The new identity can authenticate under the same case/normalization rules. |

## Alternate paths

- Invite-only signup
- Social/SSO signup
- Email-first then profile completion
- Organization creation during signup
- Deferred verification with restricted access

## Failure and recovery paths

- Identity already exists or is normalization-equivalent
- Verification delivery is delayed or link expires
- Timeout occurs after account commit
- Two tabs submit the same signup
- Provisioning succeeds only partially

## Completion oracle

- The stated outcome is true in visible UI and authoritative persisted state.
- Exactly one intended business result and no unintended side effect occurred.
- Identity, tenant, authorization, money/data, lifecycle, notifications, integrations, analytics, and audit agree where applicable.
- Refresh, retry, back/forward, and a second authorized read do not reveal a contradictory result.
- Any partial, delayed, canceled, failed, or unknown outcome is labeled truthfully and has a safe recovery path.

## Evidence to capture

- Entry context, actor, tenant, role, feature flags, locale, time zone, and initial identifiers/state.
- Step-level screenshots or DOM state plus request/response, correlation, job, event, and stable business IDs where available.
- Before/after authoritative records, versions, totals, permissions, lifecycle states, and downstream side effects.
- Notifications, audit events, integration deliveries, retries, deduplication, latency, and recovery evidence.
- Untested branches, unsafe-to-run cases, product decisions, and evidence tier.

## Product decisions to resolve

- Exact eligibility, required data, authorization, and validation rules.
- Which steps are synchronous, asynchronous, optional, skippable, reversible, or irreversible.
- Idempotency, concurrency, timeout, retry, cancellation, and compensation semantics.
- Retention, privacy, notification, audit, performance, accessibility, and localization commitments.

## Related CARBON items

- [username](../../items/controls/username.md)
- [email address](../../items/controls/email-address.md)
- [password](../../items/controls/password.md)
- [registration and invitation](../../items/identity/registration-and-invitation.md)
- [session lifecycle](../../items/identity/session-lifecycle.md)

[Back to Identity and access flows](index.md)
