--- id: CAP-PFM-TNL-008 title: Apply defaults without undoing customer choices feature: FEAT-PFM-TNL-03 product_area: platform module: tenant-lifecycle revision: 2 status: draft product_intent: confirmed implementation_evidence: observed supersedes: [] source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69 services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b services-committees: 36129c24daeaadcdb339218c38cdeaff9861359d services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893 intent_sources: - 'services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3' - 'services-platform:docs/standards/baseline-configuration.md#§2' - 'services-platform:docs/standards/baseline-configuration.md#§3' purpose: >- Workspace defaults are applied through seed ledgers that preserve later customer changes. outcomes: - Applied defaults have one workspace ledger entry. - Matching customer-created records are adopted rather than replaced. - 'Renamed, inactive and deleted seeded records retain the customer’s decision.' concepts: - CON-PFM-TNL-003 actors: - ACT-PFM-012 surfaces: - job preconditions: [] postconditions: [] permissions: [] rules: - id: BR-CAP-PFM-TNL-008-01 proved_by: [ATS-PFM-TNL-008-01] statement: >- A seed ledger records each applied default once for its workspace and associates it with the applying run. kind: invariant enforced_at: - service - database must_prove: true provenance: test source: >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-seed-applications.integration.spec.js#applies every seed of the set and records each against the run that wrote it origin: 'services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 (approved)' - id: BR-CAP-PFM-TNL-008-02 proved_by: [ATS-PFM-TNL-008-02, ATS-PFM-TNL-008-08] statement: >- An existing seed entry prevents reapplication even when the customer renamed, deactivated or removed the default record. kind: invariant enforced_at: - service must_prove: true provenance: test source: >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#does not recreate a default the customer deleted origin: >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 (approved); services-platform:docs/standards/baseline-configuration.md#§3 (D-48) - id: BR-CAP-PFM-TNL-008-03 proved_by: [ATS-PFM-TNL-008-03] statement: >- A pre-existing record with a default’s natural key is adopted and ledgered without replacement or duplication. kind: invariant enforced_at: - service - database must_prove: true provenance: test source: >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#adopts a role the customer made first with a seed’s id, rather than duplicating it origin: >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 (approved); services-platform:docs/standards/baseline-configuration.md#§2 - id: BR-CAP-PFM-TNL-008-04 proved_by: [] statement: >- Applying a database default and recording its seed entry share a transaction. kind: invariant enforced_at: - service - database must_prove: true provenance: documented source: >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.4 Database seeds commit their rows and their ledger entry in the same transaction origin: 'services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.4 (approved)' - id: BR-CAP-PFM-TNL-008-05 proved_by: [ATS-PFM-TNL-008-04] statement: >- Readiness requires all seeds in the participant’s current sets to be ledgered and identifies missing seeds. kind: validation enforced_at: - service must_prove: true provenance: test source: >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#answers not ready, naming every seed, before it has provisioned origin: >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.3 verifyProvisioned (approved) - id: BR-CAP-PFM-TNL-008-06 proved_by: [ATS-PFM-TNL-008-05, TST-PFM-TNL-076] statement: >- Workspace isolation prevents another workspace from reading or changing its seed ledger. kind: invariant enforced_at: - database must_prove: true provenance: test source: >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-seed-applications.integration.spec.js#keeps one tenant’s ledger out of another tenant’s reach origin: >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 RLS on tenant_id (approved) - id: BR-CAP-PFM-TNL-008-07 proved_by: [] statement: >- The baseline contains CRM’s two contact roles, address and phone types, three affiliation types and mappings, five task types, seven activity types and three duplicate rules; Commerce’s two audiences and five placements; Committees’ six types and eight positions; Membership’s four relationship types; and Platform’s requested first-administrator invitation. kind: policy enforced_at: - service must_prove: false provenance: test source: >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#applies every default of its five seed sets the first time origin: >- services-platform:docs/standards/baseline-configuration.md#§1 (D-48, Andrew 2026-10-19) - id: BR-CAP-PFM-TNL-008-08 proved_by: [] statement: >- Workspace configuration defaults belong to participant seeds rather than migration inserts. kind: policy enforced_at: - service must_prove: false provenance: documented source: >- services-platform:docs/standards/baseline-configuration.md#§2 How it is declared origin: 'services-platform:docs/standards/baseline-configuration.md#§2 (D-48)' scenarios: - id: SC-CAP-PFM-TNL-008-01 given: The customer removed a seeded Fax phone type. when: Provisioning is repeated. then: The ledger prevents Fax from being recreated. provenance: test source: >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#does not recreate an address type the customer deleted - id: SC-CAP-PFM-TNL-008-02 given: A customer-created committee position uses a starter’s natural key. when: Committees applies its baseline. then: The existing position is preserved and recorded as adopted. provenance: test source: >- services-committees:modules/tenant-lifecycle/tests/integration/services/starter-types.integration.spec.ts#adopts the position the customer made under a starter’s id instead of overwriting it edge_cases: [] constraints: [] depends_on: - CAP-PFM-TNL-007 related: - CAP-PFM-TNL-002 - CAP-PFM-TNL-009 - CAP-PFM-TNL-012 journeys: - JNY-PFM-TNL-005 open_questions: [] evidence: - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 - >- Inspected source: services-platform:docs/standards/baseline-configuration.md#§2 - >- Inspected source: services-platform:docs/standards/baseline-configuration.md#§3 - >- Inspected source: services-platform:modules/tenants/tests/integration/services/persistence/tenant-seed-applications.integration.spec.js#applies every seed of the set and records each against the run that wrote it - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 (approved) - >- Inspected source: services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#does not recreate a default the customer deleted - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 (approved); services-platform:docs/standards/baseline-configuration.md#§3 (D-48) - >- Inspected source: services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#adopts a role the customer made first with a seed’s id, rather than duplicating it - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 (approved); services-platform:docs/standards/baseline-configuration.md#§2 - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.4 Database seeds commit their rows and their ledger entry in the same transaction - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.4 (approved) - >- Inspected source: services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#answers not ready, naming every seed, before it has provisioned - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.3 verifyProvisioned (approved) - >- Inspected source: services-platform:modules/tenants/tests/integration/services/persistence/tenant-seed-applications.integration.spec.js#keeps one tenant’s ledger out of another tenant’s reach - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 RLS on tenant_id (approved) - >- Inspected source: services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#applies every default of its five seed sets the first time - >- Inspected source: services-platform:docs/standards/baseline-configuration.md#§1 (D-48, Andrew 2026-10-19) - >- Inspected source: services-platform:docs/standards/baseline-configuration.md#§2 How it is declared - >- Inspected source: services-platform:docs/standards/baseline-configuration.md#§2 (D-48) - >- Inspected source: services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#does not recreate an address type the customer deleted - >- Inspected source: services-committees:modules/tenant-lifecycle/tests/integration/services/starter-types.integration.spec.ts#adopts the position the customer made under a starter’s id instead of overwriting it controls: [TC-AVL-001, TC-AZ-001, TC-AZ-002, TC-AZ-003, TC-AZ-004, TC-CHG-001, TC-CHG-002, TC-CHG-003, TC-CHG-004, TC-CHG-005, TC-CHG-006, TC-CHG-007, TC-DAT-001, TC-DAT-003, TC-DAT-004, TC-IAM-001, TC-IAM-002, TC-IAM-004, TC-IAM-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] exercised_by: [FAS-PFM-TNL-03-01, FAS-PFM-TNL-03-02, FAS-PFM-TNL-03-03, FAS-PFM-TNL-03-04] suites: [TST-PFM-TNL-076] --- # Apply defaults without undoing customer choices ## Purpose Workspace defaults are applied through seed ledgers that preserve later customer changes. ## How It Works Each participant declares the starter configuration it supplies. Its seed ledger records which defaults a workspace has already received. A missing entry allows the participant to apply or adopt the default. An existing entry causes the seed to be skipped. Customer edits do not reset that entry. A deliberately deleted default therefore remains deleted on later provisioning or reconciliation. Database seeds and their ledger records commit together. Readiness checks the current seed sets against that ledger and reports missing entries. The baseline varies by application and includes categories, types, roles and the requested first-administrator invitation. ## Relationships - Account for each application’s lifecycle responsibilities: Its result establishes the state or declared resources needed by this operation. - Open a workspace after its applications are ready: Its readiness and activation finish workspace construction. - Maintain the baseline of existing workspaces: Its reconciliation supplies later defaults to existing workspaces. - Recover an incorrect initial import: Its reset classification distinguishes imported records from retained setup.