Release and Versioning
This page describes internal workforce and platform releases, not a deployment requirement for Managed Team customers.
Internal lifecycle
Source → Configure → Test → Review → Release → Monitor
Compound Leverage versions its internal workforce definitions, tools, and workflows. Changes should be validated for intended behavior, appropriate access, quality controls, and compatibility before release.
Customer work remains separate
Customers request work through meetings, email, or the optional Customer Portal. A THINK Strategist manages assignments and quality. Customers review and approve deliverables as applicable. Internal software release milestones do not replace customer artifact review or approval.
Change controls
Document the scope of changes, test evidence, reviewer decisions, rollback considerations, and affected workflows. Protect customer data and access boundaries during upgrades.
See Security and Governance Model.
Release gates
The platform contract defines Internal source → Package manifest → Staging → Evaluation → Human approval → Marketplace / Production.
| Gate | Evidence to review | Decision |
|---|---|---|
| Internal source | Canonical team, role, skill, and workflow changes | What changed? |
| Package manifest | Declared contents, runtime support, and compatibility | Is the package valid? |
| Staging | Target configuration and permitted integrations | Can the package run in the intended environment? |
| Evaluation | Relevant tests, quality checks, and access-boundary checks | Does it satisfy release criteria? |
| Human approval | Reviewer decision and unresolved exceptions | Is promotion authorized? |
| Release | Deployment or publication evidence where implemented | Was the approved version promoted? |
The documented lifecycle does not independently establish a live marketplace or commercial runtime.
Versioned objects
| Object | Independently versioned under the specification? |
|---|---|
| AI Team, package, Digital Employee, skill | Yes |
| Workflow and evaluation | Yes |
| Capability contract and CL MCP compatibility | Yes |
| Customer configuration | Yes, separately from the reusable package |
Semantic versioning
| Change | Version increment | Example |
|---|---|---|
| Incompatible contract or behavior | MAJOR | 1.4.2 → 2.0.0 |
| Backward-compatible capability or behavior addition | MINOR | 1.4.2 → 1.5.0 |
| Backward-compatible correction without contract change | PATCH | 1.4.2 → 1.4.3 |
Examples illustrate the rule; they are not actual released versions.
Release versus customer approval
| Internal technical release | Customer work approval |
|---|---|
| Approves a reusable workforce package or runtime change | Approves a specific deliverable or consequential action |
| Uses staging, evaluations, and release controls | Uses assignment acceptance criteria and designated human reviewers |
| May affect multiple engagements | Applies to the customer’s authorized work |
| Does not authorize production changes in a customer’s environment | Customer deployment requires separately approved scope |
Compatibility and rollback considerations
Before promoting a release, review affected role/skill contracts, capability mappings, supported runtimes, customer configurations, test evidence, and a recovery approach where applicable. The specification requires compatibility validation in staging before production promotion.
Source and related documentation
Internal source: platform-spec/release-versioning.md and platform-spec/README.md.
Workforce Package Structure · Work Execution Layer · Security and Governance · GitHub Actions documentation