Workforce Package Structure

Compound Leverage maintains reusable internal workforce definitions to support consistent Managed Team delivery. These packages are internal implementation assets, not customer-facing software products.

Logical components

A workforce package may contain role definitions, task instructions, reusable skills, approved tools, output templates, quality checks, routing rules, and escalation criteria. The specific file format and execution runtime may vary.

Customer-specific work

The THINK Strategist applies appropriate capabilities to an authorized request, coordinates execution, and reviews the finished artifact. Customer context and access are governed separately from reusable internal workforce definitions.

Change management

Updates to internal packages should be versioned, tested, reviewed, and released under Compound Leverage controls. Customers receive work products and agreed services, not an obligation to maintain the underlying packages.

See Release and Versioning.

Logical package model

Component	What it defines	Version or configuration boundary
AI Team	Work domain and team composition	Canonical internal source
Digital Employee	Specialized job, inputs, outputs, responsibilities	Reusable role definition
Skill	Repeatable method and checks	Reusable skill definition
Workflow	Sequence, handoffs, and approval gates	Team workflow
Evaluation	Quality and release checks	Shared or team-specific evaluation
Capability contract	Runtime-independent capability required for work	Stable capability ID and compatibility
Package manifest	Contents, supported runtimes, and compatibility	Release artifact
Customer configuration	Approved providers, customer context, environment bindings	Separate customer/deployment version

The internal source is canonical. Runtime or marketplace packages are release artifacts, and MCP services are capability providers, not alternative sources of truth.

Source-to-release process

Canonical internal source
         |
         v
    Package manifest
         |
         v
       Staging
         |
         v
      Evaluation
         |
         v
     Human approval
         |
         v
Marketplace / production
(where implemented)

This path is specified in platform-spec/README.md and platform-spec/release-versioning.md. It describes an internal technical release contract; it is not the customer’s assignment lifecycle and does not establish that every marketplace or production target is operational.

Runtime portability

The contract allows runtime-specific packaging for environments such as ChatGPT, Claude, Codex, Microsoft Copilot, or approved customer-controlled infrastructure. A package’s stated compatibility must be validated for the target environment. Runtime-specific packaging must not replace the canonical workforce definition.

Separation of reusable and customer-specific data

Reusable definition	Customer-specific configuration
Digital Employee job and skill	Approved customer context and sources
Capability IDs	Provider binding and credentials
Evaluation criteria	Engagement acceptance requirements
Package release	Customer environment and deployment configuration

Implementation references

Repository path	Purpose
`platform-spec/ai-team-package.schema.json`	Package manifest contract
`platform-spec/capability-contract.schema.json`	Capability interface contract
`platform-spec/mcp-boundary.md`	Provider and authorization boundary
`platform-spec/release-versioning.md`	Versioning and release lifecycle
`THINK-Commercial/Harness/schemas/customer-manifest.schema.json`	Customer manifest contract

Release and Versioning · Digital Workforce Roles · Context and Capability Resolution · MCP and Integrations