Pillar 08
Lifecycle
Every cooperative, project, and resource has a lifecycle: creation, active operation, hibernation, and dissolution. State transitions are governance-controlled, fully auditable, and designed to protect member data and rights at every stage.
Design philosophy
Most platforms assume resources are either active or deleted. Cooperatives operate differently. A project may pause for a season and resume. A working group may complete its mandate and archive its work. A member may take an extended leave and return. The platform models these transitions explicitly rather than forcing a binary active/deleted state.
Entity types with lifecycles
- Member — a person participating in the cooperative
- Project — a bounded initiative with a defined scope
- Working group — an ongoing collective with a standing mandate
- Resource — a physical or digital asset managed by the cooperative
- Cooperative shard — the shard itself, as an entity
States
Provisioning
The entity is being set up. For a member, this is the onboarding period. For a project, this is the proposal and setup phase. Access is limited to the coordinator and provisioning workflows.
Active
Normal operation. Full access according to the authorization policy. Workflows are running. Data is being written. Members are participating.
Hibernating
The entity is paused but not dissolved. Data is retained in read-only state. Running workflows are checkpointed and suspended. Members associated with the entity retain their credentials. The entity can be reactivated by a governance vote without data loss.
Hibernation is commonly used for seasonal projects, member sabbaticals, and working groups that have completed a phase and are awaiting the next one.
Archiving
The entity's active operation has concluded. All data is moved to the archive storage tier (lower-cost, read-only). The entity can still be queried for historical purposes but cannot be reactivated. This is appropriate for completed projects whose records should be preserved but whose workflows should not resume.
Dissolving
A time-limited state during which the entity's resources are redistributed before final deletion. For a member dissolution, this involves: transferring ownership of their resources, completing open workflows, settling any treasury obligations, and issuing the member's data export.
For a cooperative shard dissolution, this involves: member notification, data export delivery to all members, treasury distribution, and deprovisioning of infrastructure in a documented sequence.
Dissolved
The entity no longer exists on the platform. Records of its existence are retained in the audit log for the statutory retention period, then permanently deleted.
Transition governance
Not all lifecycle transitions are equal. Some require only a coordinator action; others require a full collective vote:
- Active → Hibernating: coordinator action, notifies members
- Hibernating → Active: coordinator action
- Active → Archiving: governance vote (simple majority)
- Active → Dissolving: governance vote (supermajority, typically 2/3)
- Member: Provisional → Active: coordinator action
- Member: Active → Suspended: council action, subject to appeal
- Shard: any dissolution: supermajority vote with mandatory 30-day notice period
Data at dissolution
Member data is never silently deleted. At dissolution:
- Each member receives a full data export before dissolution completes
- Shared resources are transferred to named recipients or the collective archive
- Governance records are archived for the statutory period
- Treasury balances are distributed according to the dissolution plan approved by members