Rhythm 2.0 Specifications

Appearance

DOM-PFM-TNL-002Provisioning

Markdown

DOM-PFM-TNL-002

Provisioning

Markdown
  • DocumentDraft
  • ImplementationObserved

Planning

Specified by
CON-PFM-TNL-002

Design

Owned by
SVC-PFM-TNL-tenants

KindDomain objectProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision1

Read atservices-platform ad3f6a65services-crm a8d1364fservices-commerce c8b66a98services-committees 36129c24services-membership 5994c270services-submissions 64236c19services-websites 5fc6823cservices-marketing d071a159

Provisioning ​

What It Models ​

Provisioning records a construction attempt across application participants. It preserves progress, failure and retry lineage so staff can recover a build without discarding completed resources.

Identity and Attributes ​

Each attempt has its generated job identity, submission identity and workspace reference; retry allocates a linked attempt. Workspace identity carried by the attempt; initial submission commits them together. Existing customer or the customer created with the first workspace. Caller-supplied identity used to recover the recorded submission. Requested live or implementation standing, defaulting to implementation and applied at activation. Records whether this submission creates the customer and can invite its first administrator. The paired name and email address for the new customer’s administrator invitation. Static dependency order followed by readiness and activation; publication compares live participant order. Recorded task results and attempts, with completed steps copied to linked retry. Sequenced durable execution events for progress inspection. Pending, running, succeeded or failed; this kind does not expose engine cancellation. A safe operational explanation of the failure and missing requirements. The prior failed attempt linked by this retry. Shared claim and delivery result for the requester’s attempt-outcome message. Association sender configuration recorded at submission and prepared by its participant.

Relationships ​

The attempt points to the workspace it constructs. The plan identifies participating implementations without owning their business records. The attempt names a customer, which workspace administration owns and the request may create.

Invariants ​

The structured invariants distinguish service and database enforcement from documented obligations. The listed enforcement points bound what the workflow can rely on.

How It Is Stored and Shared ​

Platform’s lifecycle service owns this design object. The physical declarations identify its stored records, while shared jobs provide durable execution and inspection.

Open Design Questions ​

A retry changes lifecycle before creating its attempt. Post-activation failures can also leave an active workspace with a failed job outcome; both need deliberate recovery behavior.

Relationships

ToCardinalityOwnershipCrosses a serviceOn archive or delete
DOM-PFM-TNL-001many-to-oneThe attempt points to the workspace it constructs.no
DOM-PFM-TNL-003many-to-manyThe plan identifies participating implementations without owning their business records.yes
DOM-PFM-SEC-001many-to-oneThe attempt names a customer, which workspace administration owns and the request may create.no

Invariants

InvariantProtectsEnforced atProvenance
INV-DOM-PFM-TNL-002-01
Initial construction commits new customer when requested, workspace, sender setting and attempt together.
service, databaseobserved
services-platform:modules/tenants/services/provisioning/submit-tenant-provisioning.ts:submitTenantProvisioning
INV-DOM-PFM-TNL-002-02
A recorded submission identity resolves to its original workspace and attempt.
service, databaseobserved
services-platform:modules/tenants/services/provisioning/submit-tenant-provisioning.ts:submitTenantProvisioning (findTenantProvisioningJobBySubmission)
INV-DOM-PFM-TNL-002-03
The database permits only one pending or running attempt per workspace.
databaseobserved
services-platform:db/migrations/0037_tenant_provisioning_job.sql:tenant_provisioning_jobs_open_uidx
INV-DOM-PFM-TNL-002-04
Step publication refuses a live participant order different from the catalog plan.
serviceobserved
services-platform:modules/tenants/services/provisioning/provision-tenant-operations.ts:tenantProvisioningOperations
INV-DOM-PFM-TNL-002-05
The build workflow checks each planned participant before activation.
serviceobserved
services-platform:modules/tenants/services/provisioning/provision-tenant-operations.ts:verifyParticipant
INV-DOM-PFM-TNL-002-06
Failure retains constructed resources and changes only a workspace still provisioning; activation already committed is preserved.
serviceobserved
services-platform:modules/tenants/services/provisioning/provision-tenant-failure.ts:applyTenantProvisioningFailure
INV-DOM-PFM-TNL-002-07
Requester outcome delivery uses a per-attempt claim and does not determine the build outcome.
service, databasedocumented
services-platform:docs/hq/rhythm-hq-plan.md#§D11 Provisioning notifications

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