Rhythm 2.0 Specifications

Appearance

CAP-PFM-SEC-001Establish and administer a customer

Markdown

CAP-PFM-SEC-001

Establish and administer a customer

Markdown
  • DocumentDraft
  • Product intentConfirmed
  • ImplementationObserved

Planning

Feature
FEAT-PFM-SEC-01
Key concepts
CON-PFM-SEC-001
Actors
ACT-PFM-004, ACT-PFM-005, ACT-PFM-001
Journeys
JNY-PFM-SEC-001
Related
CAP-PFM-SEC-002, CAP-PFM-SEC-003, CAP-PFM-SEC-017
Proved by
ATS-PFM-SEC-001
Executed by
TST-PFM-SEC-041, TST-PFM-SEC-042, TST-PFM-SEC-043, TST-PFM-SEC-044, TST-PFM-SEC-191

KindCapabilityProduct areaPlatformModuleSecurity, Customers and WorkspacesRevision1

Read atservices-platform ad3f6a65react-console baf6dae3

Establish and Administer a Customer ​

Purpose ​

Customer administration establishes the paying organization behind association workspaces. Rhythm staff own onboarding and removal, while authorized customer administrators maintain their own customer’s details.

How It Works ​

A Rhythm Administrator begins in Customers within Rhythm HQ. The administrator supplies the organization’s readable reference and classification, then reviews the returned record. The customer can exist before any workspace is added. Staff find it through the HQ list and open its details to inspect the workspaces beneath it. The HQ form supports the customer fields assigned to that administrative surface. Customer-level access provides a separate route for maintaining authorized details within the customer boundary. A replacement is checked against the supplied version, and intervening edits require the caller to reload or reconcile the newer record. Locks and workspace dependencies can prevent an otherwise authorized change or removal. Deleting an eligible customer also removes its standing staff-access records within the same transaction. The product should add the remaining deletion safeguards and resolve the different standing-access behavior of the two creation paths.

Relationships ​

  • Workspace provisioning needs an owning customer and can request its creation alongside the workspace.
  • Standing staff access connects Rhythm Administrators to customer work and participates in customer deletion.
  • Commercial links provide the default account relationship used during workspace preparation.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
A permanent readable reference identifies the paying organization behind its workspaces.Customer administration stays within the caller’s authorized customer boundary.Deletion respects the implemented workspace dependency and record safeguards.
Surfaces
consoleapi
Intent sources
services-platform:docs/hq/rhythm-hq-plan.md#K8services-platform:docs/hq/rhythm-hq-plan.md#D8services-platform:docs/tenants/tenant-identity.md#The rules (Andrew, 2026-10-17)

Controls

31 controls apply, from the corpus control catalogue.

TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-CRY-001 TC-CRY-002 TC-CRY-003 TC-CRY-004 TC-DAT-001 TC-DAT-003 TC-DAT-004 TC-IAM-003 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-MON-001 TC-PI-001 TC-PI-003 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

KeyChecked atScope
hq.customers.createapiglobal
hq.customers.readapiglobal
hq.customers.updateapiglobal
hq.customers.deleteapiglobal
platform.customers.readapirecord
platform.customers.updateapirecord

Business Rules

13 rules, 12 to be proved before approval. A rule's product intent is derived from its origin: 13 confirmed by a product decision, the rest inheriting this capability's confirmed.

IdRuleKindEnforced atProvenance
01must prove
Confirmed
Customer creation and deletion require Rhythm staff authority; customer-level administrative grants do not authorize either action.
origin: services-platform:docs/hq/rhythm-hq-plan.md#D1
no proof recorded yet
permissionapitest
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a customer-scoped caller the system route that creates a customer
02must prove
Confirmed
A supplied customer identifier is trimmed and lowercased, contains 1 to 64 permitted characters, starts and ends alphanumerically, has no consecutive dots, and is refused if reserved, generated-identifier-shaped or already assigned.
✓ A capitalized domain-shaped reference is normalized to lowercase.✗ Creation without a chosen identifier is refused.
origin: services-platform:docs/tenants/tenant-identity.md#The rules (Andrew, 2026-10-17)
no proof recorded yet
validationapi, service, databaseobserved
services-platform:modules/customers/services/persistence/customers.ts:requireCustomerId
03must prove
Confirmed
Every customer has exactly one classification from customer, trial, demo and training.
origin: services-platform:docs/hq/rhythm-hq-plan.md#D13
no proof recorded yet
validationapi, databasetest
services-platform:modules/customers/tests/integration/db/customers.table.integration.spec.js#refuses a type outside the closed list by customers_type_check
04must prove
Confirmed
Customer e-mail is normalized to lowercase, a blank value becomes absent, and an invalid address is refused before it is stored.
no proof recorded yet
validationservice, databasetest
services-platform:modules/customers/tests/integration/services/persistence/customers.integration.spec.js#refuses an invalid address on create as ObjectInvalid naming the field
05must prove
Confirmed
Customer administrators receive only their own customer in lists, and an unauthorized customer read returns the same not-found result as an absent record.
origin: services-platform:docs/hq/rhythm-hq-plan.md#D3
no proof recorded yet
permissionapi, servicetest
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#answers a customer-scoped caller 404 for another customer's record, so the route cannot be walked
06must prove
Confirmed
Customer replacement uses the version supplied by the caller and refuses a stale version without overwriting the current record.
origin: services-platform:docs/standards/record-write-contracts.md#D-05
no proof recorded yet
validationapi, servicetest
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a stale version as 409
07must prove
Confirmed
The product should clear omitted editable values during replacement; the available assertions do not prove that the current commercial field is cleared.
no proof recorded yet
policyserviceunknown
FND-PFM-SEC-032
08must prove
Confirmed
The persistence service refuses updates to an update-locked customer and deletion of a delete-locked customer.
no proof recorded yet
invariantservicetest
services-platform:modules/customers/tests/integration/services/persistence/customers.integration.spec.js#refuses a record locked against updates as IllegalOperation
09
Confirmed
Rhythm HQ presents customers in name order with workspace counts, name or identifier search, a default page size of 25 and a maximum of 100.
origin: services-platform:docs/hq/rhythm-hq-plan.md#D7
policyapi, servicetest
services-platform:modules/customers/tests/e2e/hq-customers.e2e.spec.js#answers a page of records, each with its tenant count, and no cursor when it is the last
10must prove
Confirmed
The HQ edit accepts the name, classification and two accounting-system references, preserving omitted fields, accepting explicit clearing of nullable fields and rejecting fields outside that edit.
origin: services-platform:docs/hq/rhythm-hq-plan.md#D13
no proof recorded yet
validationapitest
services-platform:modules/customers/tests/e2e/hq-customers.e2e.spec.js#refuses a body naming a field the HQ screen does not edit as 400
11must prove
Confirmed
An existing workspace reference prevents deletion of its customer.
origin: services-platform:docs/hq/rhythm-hq-plan.md#D8
no proof recorded yet
invariantdatabasetest
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#refuses a customer that still has tenants as 409
12must prove
Confirmed
Customer deletion removes the Rhythm Administrators’ standing grants for that customer within the deletion transaction.
origin: services-platform:docs/hq/rhythm-hq-plan.md#K1b
no proof recorded yet
lifecycleservicetest
services-platform:modules/security/tests/integration/services/staff-access/rhythm-administrator-standing-access.integration.spec.js#deletes the customer
13must prove
Confirmed
The product should also prevent deletion while console users or custom security definitions remain, require the customer name and a reason, and record the decision in security history.
origin: services-platform:docs/hq/rhythm-hq-plan.md#D8
no proof recorded yet
policyserviceunknown
FND-PFM-SEC-003

Scenarios

IdGivenWhenThenProvenance
01Staff are establishing the paying organization for a management company.An authorized Rhythm Administrator creates a customer with a readable reference and customer classification.HQ returns the new customer with no workspaces; its creation test does not establish the missing standing-access hook.test
services-platform:modules/customers/tests/e2e/hq-customers.e2e.spec.js#creates a customer for a staff member holding hq.customers.create, answering the record
02An existing workspace belongs to the customer.Authorized staff attempt to remove that customer.The dependency blocks removal and a subsequent read still returns the customer.test
services-platform:modules/customers/tests/e2e/customers.e2e.spec.js#leaves a customer that still has tenants readable

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software