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.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

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

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.
Surfaces: job
Intent sources: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3services-platform:docs/standards/baseline-configuration.md#§2services-platform:docs/standards/baseline-configuration.md#§3

Controls

31 controls apply, from the corpus control catalogue.

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

Business Rules

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

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Confirmed	A seed ledger records each applied default once for its workspace and associates it with the applying run. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 (approved) no proof recorded yet	invariant	service, database	test 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
`02`must prove Confirmed	An existing seed entry prevents reapplication even when the customer renamed, deactivated or removed the default record. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 (approved); services-platform:docs/standards/baseline-configuration.md#§3 (D-48) no proof recorded yet	invariant	service	test services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#does not recreate a default the customer deleted
`03`must prove Confirmed	A pre-existing record with a default’s natural key is adopted and ledgered without replacement or duplication. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 (approved); services-platform:docs/standards/baseline-configuration.md#§2 no proof recorded yet	invariant	service, database	test 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
`04`must prove Confirmed	Applying a database default and recording its seed entry share a transaction. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.4 (approved) no proof recorded yet	invariant	service, database	documented services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.4 Database seeds commit their rows and their ledger entry in the same transaction
`05`must prove Confirmed	Readiness requires all seeds in the participant’s current sets to be ledgered and identifies missing seeds. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.3 verifyProvisioned (approved) no proof recorded yet	validation	service	test services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#answers not ready, naming every seed, before it has provisioned
`06`must prove Confirmed	Workspace isolation prevents another workspace from reading or changing its seed ledger. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.3 RLS on tenant_id (approved) no proof recorded yet	invariant	database	test 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
`07` Confirmed	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. origin: services-platform:docs/standards/baseline-configuration.md#§1 (D-48, Andrew 2026-10-19)	policy	service	test services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#applies every default of its five seed sets the first time
`08` Confirmed	Workspace configuration defaults belong to participant seeds rather than migration inserts. origin: services-platform:docs/standards/baseline-configuration.md#§2 (D-48)	policy	service	documented services-platform:docs/standards/baseline-configuration.md#§2 How it is declared

Scenarios

Id	Given	When	Then	Provenance
`01`	The customer removed a seeded Fax phone type.	Provisioning is repeated.	The ledger prevents Fax from being recreated.	test services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#does not recreate an address type the customer deleted
`02`	A customer-created committee position uses a starter’s natural key.	Committees applies its baseline.	The existing position is preserved and recorded as adopted.	test 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

Planning

Apply defaults without undoing customer choices ​

Purpose ​

How It Works ​

Relationships ​