Rhythm 2.0 Specifications

Appearance

CAP-PFM-TNL-009Maintain the baseline of existing workspaces

Markdown

CAP-PFM-TNL-009

Maintain the baseline of existing workspaces

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationPartially observed

Planning

Feature
FEAT-PFM-TNL-03
Exercised by
FAS-PFM-TNL-03-01, FAS-PFM-TNL-03-02, FAS-PFM-TNL-03-03
Key concepts
CON-PFM-TNL-003
Actors
ACT-PFM-004, ACT-PFM-012
Journeys
JNY-PFM-TNL-005
Depends on
CAP-PFM-TNL-008
Related
CAP-PFM-TNL-007, CAP-PFM-TNL-002
Open questions
OQ-PFM-TNL-002
Proved by
ATS-PFM-TNL-009

Implementation

Executable suites
TST-PFM-TNL-023, TST-PFM-TNL-031, TST-PFM-TNL-080

KindCapabilityProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision2

Read atservices-platform ad3f6a65services-crm a8d1364f

Maintain the baseline of existing workspaces ​

Purpose ​

Reconciliation supplies missing default configuration to older workspaces while preserving ledgered customer choices.

How It Works ​

An application can add a new default without requiring customers to recreate their workspaces. CRM’s deployment reconciliation selects its eligible lifecycle states and visits their participants. It applies the current seed sets through the same ledgers used in provisioning. Older uncustomized workspaces then have the current seeded configuration. A renamed or deleted ledgered default is still skipped. Errors are collected by workspace while the remaining workspaces are processed. The deployment fails after reporting those errors. Staff initialization provides a separate one-participant operation. Its allowed states differ from deployment reconciliation, and remote initialization uses provisioning without forwarding selected sets. Platform itself still lacks a deployment reconciliation pass for local defaults.

Relationships ​

  • Apply defaults without undoing customer choices: Its result establishes the state or declared resources needed by this operation.
  • Account for each application’s lifecycle responsibilities: Its declarations identify the application resources involved.
  • Open a workspace after its applications are ready: Its readiness and activation finish workspace construction.

The Formal Contract

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

Outcomes
Deployment reconciliation adds missing CRM defaults without repeating existing seeds.Staff can initialize a participant on demand.Workspace failures are collected while reconciliation continues elsewhere.
Surfaces
apijob
Intent sources
services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.5services-platform:docs/standards/baseline-configuration.md#§3services-platform:docs/standards/baseline-configuration.md#§4

Controls

27 controls apply, from the corpus control catalogue.

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

Permissions

KeyChecked atScope
hq.tenants.provisionapiglobal

Business Rules

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

IdRuleKindEnforced atProvenance
01must prove
Proposed
Staff can initialize a participant for an existing workspace, applying unledgered defaults and selecting sets where the local implementation supports that selection.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.5 (approved)
proved by ATS-PFM-TNL-009-01
policyapi, servicetest
services-platform:modules/tenants/tests/integration/services/provisioning/initialize-tenant.integration.spec.js#runs the participant for the tenant and says what it did
02must prove
Proposed
Staff initialization accepts active or provisioning-failed workspaces and rejects other lifecycle states, unknown participants and disabled participants.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.5 (approved); services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.6 Provisioning and initialization refuse
proved by ATS-PFM-TNL-009-02
validationservicetest
services-platform:modules/tenants/tests/integration/services/provisioning/initialize-tenant.integration.spec.js#refuses a tenant whose deletion is pending
03must prove
Confirmed
CRM deployment reconciles defaults for active, loading and provisioning-failed workspaces regardless of business status.
origin: services-platform:docs/standards/baseline-configuration.md#§3 (D-48, Andrew 2026-10-19)
proved by ATS-PFM-TNL-009-03, TST-PFM-TNL-031
policyservicetest
services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/baseline-reconciliation.spec.js#runs the reconciliation on every update, which is every deployment
04must prove
Confirmed
An uncustomized older CRM workspace receives the seeded types and ledger entries of a workspace provisioned with the current baseline.
origin: services-platform:docs/standards/baseline-configuration.md#§4 (D-48)
proved by ATS-PFM-TNL-009-04, TST-PFM-TNL-023
invariantservicetest
services-crm:modules/tenant-lifecycle/tests/integration/services/lifecycle/baseline-reconciliation.integration.spec.js#leaves an old tenant with exactly the types a tenant provisioned today holds
05must prove
Confirmed
Reconciliation records a workspace’s failure, continues with others and then fails deployment with the collected errors.
origin: services-platform:docs/standards/baseline-configuration.md#§3 Failure is visible (D-48)
proved by ATS-PFM-TNL-009-05, TST-PFM-TNL-031
policyservicetest
services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/baseline-reconciliation.spec.js#fails the deployment when any tenant failed, naming the tenant and its message
06must prove
Confirmed
Platform currently applies its own defaults through provisioning or staff initialization, without a deployment reconciliation pass.
origin: services-platform:docs/standards/baseline-configuration.md#§5 (D-48)
no proof recorded yet
policyservicedocumented
services-platform:docs/standards/baseline-configuration.md#§5 Where each macroservice stands
07must prove
Proposed
Existing-workspace provisioning retains the workspace’s status and applies missing work, rejecting workspaces outside active live or implementation mode.
proved by ATS-PFM-TNL-009-07, TST-PFM-TNL-080
policyservicetest
services-platform:modules/tenants/tests/integration/services/provisioning/provision-existing-tenant.integration.spec.js#leaves the tenant active at the status it had
08must prove
Proposed
Remote initialization calls provisioning without passing the requested seed-set selection.
proved by ATS-PFM-TNL-009-08
policyserviceobserved
services-platform:modules/tenants/services/provisioning/initialize-tenant.ts:runInitialize

Scenarios

IdGivenWhenThenProvenance
01CRM declares another follow-up task default.The release reconciles eligible workspaces.Each workspace lacking its seed receives it, and repeating reconciliation adds no second copy.test
services-crm:modules/tenant-lifecycle/tests/integration/services/lifecycle/baseline-reconciliation.integration.spec.js#gives a tenant that predates the seeds the five task types, follow-up among them

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