Account for each application’s lifecycle responsibilities

Purpose

Participant declarations make each application’s workspace resources reachable by lifecycle planning.

How It Works

Each application groups its workspace resources into participants. A declaration names ownership, dependencies, defaults and supported operations. Platform can read declarations before creating a workspace. Dependencies guide construction and reverse removal order. Application completeness checks compare declared tables with the database. Missing or duplicate declarations fail those checks. Platform keeps remote participant declarations of its own and enables them for orchestration. Disabled remote applications are omitted from both description calls and plans. External resource registration provides stable ownership records for retry. The application contracts differ in input validation, so CRM’s refusal tests do not establish identical safeguards everywhere.

Relationships

Open a workspace after its applications are ready: Its readiness and activation finish workspace construction.
Apply defaults without undoing customer choices: Its seed ledgers preserve customer choices during lifecycle replay.
Recover an incorrect initial import: Its reset classification distinguishes imported records from retained setup.
Remove declared workspace resources and verify the result: Its batches and inventory determine the removal result.
Supply application data for workspace exports: The capabilities share the workspace’s recorded lifecycle decision.

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: Applications expose a shared lifecycle protocol with optional operations declared explicitly.Completeness checks account for workspace-keyed tables exactly once.Platform’s enabled declarations control when an application participates.
Surfaces: jobapi
Intent sources: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.1services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.2services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.4 Completeness check

Controls

30 controls apply, from the corpus control catalogue.

TC-AVL-001 TC-AVL-004 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-DAT-004 TC-DAT-005 TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-LOG-001 TC-LOG-004 TC-LOG-005 TC-MON-001 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Business Rules

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

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	Each application’s lifecycle function can describe its participants before a workspace exists; its other operations act on a named workspace and participant. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.1 Registration (approved 2026-10-09) proved by `ATS-PFM-TNL-007-01`	policy	service	test services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js#answers describe without reaching a tenant, so Platform can ask before a tenant exists
`02`must prove Proposed	CRM validates the operation, participant, write-run identity and batch bounds before participant execution. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.1 (approved) proved by `ATS-PFM-TNL-007-02`	validation	service	test services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js#refuses a participant CRM does not register
`03`must prove Proposed	Participant dependencies determine provisioning order and reversed deletion order, keeping the workspace record first to build and last to remove. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.2 Ordering (approved) proved by `ATS-PFM-TNL-007-03`	calculation	service	test services-crm:modules/tenant-lifecycle/tests/unit/participants/deletion-order.spec.js#leaves the tenant row until last, in a stage of its own
`04`must prove Proposed	Completeness checks require one participant per workspace-keyed table and verify that declared tables exist. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.4 Completeness check (approved) proved by `ATS-PFM-TNL-007-04`	invariant	service	test services-platform:modules/tenants/tests/integration/db/tenant-declaration-completeness.integration.spec.js#declares every tenant-keyed table the database holds
`05`must prove Proposed	Platform’s enabled declarations determine which applications enter a plan; an application with no enabled participants is neither described nor invoked. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.1 Accounting part 1 (approved 2026-10-15) proved by `ATS-PFM-TNL-007-05`, `TST-PFM-TNL-098`	policy	service	test services-platform:modules/tenants/tests/unit/services/lifecycle/remote-participants.spec.js#never asks Accounting to describe itself while Platform enables none of its participants
`06`must prove Proposed	CRM advertises participant reset support, and Platform checks remote reset declarations before emptying its selected participants. origin: services-platform:docs/data-jobs/tenant-reset.md#§3.1 Declaring support proved by `ATS-PFM-TNL-007-06`, `ATS-PFM-TNL-007-08`	validation	service	test services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js#names reset among the operations of every participant it describes, which is how Platform knows it may reset the tenant
`07`must prove Proposed	Repeated registration of an external resource adopts the existing register row instead of duplicating it. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.4 External success, then failure to record it (approved) proved by `ATS-PFM-TNL-007-07`, `TST-PFM-TNL-075`	invariant	service, database	test services-platform:modules/tenants/tests/integration/services/persistence/tenant-resources.integration.spec.js#answers the row that was already there rather than refusing the uniqueness rule
`08`must prove Proposed	Participant purges exclude shared infrastructure; customer deletion is a separate, explicitly requested action for the final workspace. origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.4 (approved) no proof recorded yet	policy	service	documented services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.4 shared (declared, never purged)
`09` Proposed	Platform’s registry includes each local participant once, excludes remote implementations and validates the declarations it publishes.	invariant	service	test services-platform:modules/tenants/tests/unit/services/lifecycle/participants.spec.js#passes the contract’s own validator for every participant, local and remote

Scenarios

Id	Given	When	Then	Provenance
`01`	Commerce gains an undeclared workspace-keyed table.	Its completeness check compares declarations and schema.	The undeclared table makes that check fail.	test services-commerce:modules/tenant-lifecycle/tests/integration/db/declaration-completeness.integration.spec.js#leaves no tenant-keyed table undeclared
`02`	Platform disables all Accounting participants.	It builds the provisioning plan.	Accounting contributes no planned participant.	test services-platform:modules/tenants/tests/unit/services/lifecycle/remote-participants.spec.js#leaves the provisioning plan exactly as it was without Accounting’s declaration once it is switched off (the negative control)

Planning

Implementation

Account for each application’s lifecycle responsibilities ​

Purpose ​

How It Works ​

Relationships ​