Skip to content

CAP-MBR-STR-020Provision, migrate and remove membership setup

Markdown

CAP-MBR-STR-020

Provision, migrate and remove membership setup

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationPartially observed

KindCapabilityProduct areaMembershipModuleOrganizational Structure, Membership Configuration and TermsRevision1

Read atservices-membership 5994c270react-console baf6dae3

The Formal Contract

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

Outcomes
Provisioning supplies standard relationship purposes without overwriting customer work.Module data can participate in controlled loading, export and removal.
Surfaces
job

Controls

47 controls apply, from the corpus control catalogue.

TC-AVL-002 TC-AVL-003 TC-AVL-004 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-CHG-001 TC-CHG-002 TC-CHG-003 TC-CHG-004 TC-CRY-001 TC-CRY-002 TC-CRY-003 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-DAT-004 TC-DAT-005 TC-DAT-007 TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-IAM-006 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-MON-001 TC-MON-002 TC-MON-004 TC-PI-001 TC-PI-002 TC-PI-004 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-SEC-001 TC-SEC-004 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004

Permissions

KeyChecked atScope
membership.structure.manageapitenant
membership.programs.manageapitenant
membership.configuration.manageapitenant

Business Rules

10 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.

IdRuleKindEnforced atProvenance
01must prove
Proposed
Provisioning applies four standard relationship kinds through the seed ledger once, leaving later customer changes untouched on repeat provisioning.
lifecycleservicetest
services-membership:modules/structure/tests/integration/services/lifecycle/structure-participant.integration.spec.ts#the structure participant in the database › seeds the four relationship types at provisioning
02must prove
Proposed
Purge first requires Platform’s deleting state, then removes workspace structure records in batches with versions last and leaves other workspaces intact.
lifecycleservice, databasetest
services-membership:modules/structure/tests/integration/services/lifecycle/structure-participant.integration.spec.ts#the structure participant in the database › refuses to purge a tenant Platform is not deleting, before any row is removed
03must prove
Proposed
Reset requires a removable workspace state and removes unit data and versions while preserving unit and relationship kinds.
lifecycleservice, databasetest
services-membership:modules/structure/tests/integration/services/lifecycle/structure-participant.integration.spec.ts#the structure participant in the database › resets the tree of a tenant being reset and keeps its unit and relationship types
04
Proposed
Development setup converges on five unit kinds, eight fixed-identity units and well-known membership configuration without deleting customer additions.
policyserviceobserved
05must prove
Proposed
Bulk structure loads match units by supported keys and load parents first, defer rebuilding until completion and reconcile history, ancestry, depths and placement kinds.
policyservicedocumented
services-membership:docs/migrations/structure/README.md#Routes, permissions, metadata, data operations, lifecycle, well-known objects
06must prove
Proposed
Bulk program, type and package operations follow dependency order and reuse ordinary configuration validation, classifying failed items for rejection.
policyserviceobserved
07must prove
Proposed
Bulk operations do not cover program unit requirements, reasons or change policy sets.
policyserviceobserved
08
Proposed
Exports stream structure, owned information, classifications and versions while omitting derived tree pairs; configuration datasets describe programs, types, packages, policies and reasons.
policyserviceobserved
09must prove
Proposed
Structure purge leaves seed-ledger entries applied, so subsequent provisioning does not restore those relationship kinds.
lifecycleservicedocumented
10must prove
Proposed
Structure loading keeps existing unit kinds, rejects unavailable kinds or parents, suppresses change events and rejects a completed rebuild reaching depth 32.
policyserviceobserved

Scenarios

IdGivenWhenThenProvenance
01Platform prepares a new customer workspace.The structure participant applies its provisioning contribution.The standard legal, operating, beneficiary and recipient relationship kinds are available.test
services-membership:modules/structure/tests/integration/services/lifecycle/structure-participant.integration.spec.ts#the structure participant in the database › seeds the four relationship types at provisioning

Edge Cases

IdGivenWhenThenProvenance
02Platform still considers the workspace active.Removal work invokes the structure purge.The state check rejects removal before any record is deleted.test
services-membership:modules/structure/tests/integration/services/lifecycle/structure-participant.integration.spec.ts#the structure participant in the database › refuses to purge a tenant Platform is not deleting, before any row is removed

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.