01must proveConfirmed | Provisioning, progress reads, retries and initialization require staff authority; customer administrators cannot perform them even for their own workspace. | permission | api | test |
02must proveConfirmed | Provisioning requires a chosen readable slug of 1–64 lowercase characters with alphanumeric ends and no adjacent dots, generated-identifier shape, reserved value, existing value or retired workspace identifier; a new customer uses the same slug validation. ✓ A production identifier and a distinct sandbox identifier pass validation.✗ A generated-identifier shape fails with the invalid-identifier code. | validation | api, service, database | test |
03must proveConfirmed | Replaying a submission returns its original workspace and job, while a distinct submission using an occupied workspace identifier fails. | invariant | service, database | test |
04must proveConfirmed | Workspace activation follows provisioning and readiness confirmation from every enabled participant and records the activation time. | lifecycle | service | test |
05must proveConfirmed | Failed provisioning preserves completed work and marks the workspace failed; retries are permitted only from that state and resume unfinished work. | lifecycle | service | test |
06must proveConfirmed | A provisioning request creating a customer with a first administrator sends one customer-wide Administrator invitation and records it to prevent a second invitation on retry. | lifecycle | service | test |
07must proveConfirmed | Provisioning sends the requester an outcome e-mail and publishes an operations alert with the job link without repeating delivered notices; notice failure does not turn the provisioning job into a failure. | policy | service | test |
08must proveConfirmed | Sender setup validates domain or address strategies before creating a workspace; a supplied address must match a supplied domain, domain values must be hostnames, and an omitted domain can use a hostname-shaped workspace identifier. | validation | api, service | test |
09Confirmed | Pending sender verification does not block activation; the shared Rhythm sender remains available until the customer publishes the required records. | policy | service | test |
10Confirmed | Provisioning inherits the customer’s commercial account unless the request explicitly selects a different account or no account. | calculation | service | observed |
11must proveConfirmed | Reconciliation moves a still-provisioning workspace behind a settled failed job to provisioning failure and records its outcome notice without repeating a delivered notice. | lifecycle | service | test |
12must proveConfirmed | Initialization rejects missing workspaces, unknown participants and workspaces whose deletion is pending or underway. | validation | service | test |
13must proveConfirmed | Initial loading requires implementation status, records the initiating person and reason, and blocks ordinary customer work during the import. | lifecycle | service | test |
14must proveConfirmed | Reset requires a loading workspace, an exact identifier confirmation, reset support from every required participant and no running reset; it preserves configuration and returns the workspace to loading. | validation | service | test |
15must proveConfirmed | Activation requires authority separate from import execution and restores ordinary availability while leaving business status unchanged. | permission | api, service | test |