Customer

What It Models

The customer represents the organization that Rhythm licenses and bills. Its record holds the organization’s identity and classification, contact address, and commercial and accounting references. The Customers service owns these fields; the workspace count is calculated for HQ reads.

Identity and Attributes

The creator chooses a permanent customer identifier. Normalization trims and lowercases it. Its length is one to sixty-four characters; letters, digits, dots, hyphens and underscores are permitted, with alphanumeric ends and no adjacent dots. Reserved names and generated-identifier shapes are rejected. Migrated customers use the normalized earlier identifier.

The attribute rows distinguish stored fields, computed answers and supporting records.

Relationships

Workspaces store their customer reference, and that reference prevents customer deletion while any workspace remains. Memberships and custom definitions store the customer reference. Staff memberships belong to Rhythm’s customer; standing-access reconciliation supplies eligible administrators with grants into other customers.

Invariants

The structured invariant rows identify each protection, its enforcement layer and its evidence. Read their qualifications with the statement rather than treating a service check as a database constraint.

How It Is Stored and Shared

Workspaces, console memberships and custom access definitions refer to the customer while retaining their own service ownership. Workspace provisioning can create the first customer in its transaction and inherit its commercial reference. Licensing uses that reference to locate contracts. Customer access is restricted to the caller’s reachable organization, with inaccessible records returned as absent.

Open Design Questions

The structured invariants define identity, validation, locking and deletion. Custom fields are disabled by the product classification and the absence of an enabling registration. Customer deletion also removes standing staff grants. The ordinary creation path reconciles those grants; the HQ creation path omits that call, leaving a recorded defect.

The planning safeguards for deletion are stronger than the implementation: membership and definition checks, typed-name confirmation, a reason and security history remain outstanding. Commercial-reference authority and replacement/patch version handling also need resolution before implementation preparation.