Understanding Capabilities, Skills, and Commonsets

AI platforms use different terms for the reusable instructions, tools, workflows, and configurations that make AI useful for real work.

Commonset uses a provider-neutral vocabulary so organizations can manage those assets without forcing every platform into the same model.

The most important distinction is simple:

A capability describes what your organization wants AI to be able to do. A skill is one way that capability may be implemented for a particular provider or format.

Capability

A capability is the broadest reusable AI function managed by Commonset.

It represents durable organizational intent rather than a particular provider implementation.

Examples might include:

• reviewing a contract according to company policy
• analyzing an expense report
• preparing a customer research brief
• generating code according to an engineering team's standards
• producing a standardized incident summary

The capability is the thing your organization wants to preserve, improve, govern, and make available.

That idea should survive even if the underlying AI provider changes.

Skill

A skill is a provider-specific or format-specific implementation of a capability.

A provider may define its own skill format with particular files, metadata, instructions, APIs, or publishing behavior. Commonset can manage that implementation while still treating the organizational concept behind it as a capability.

In other words:

Capability: what the organization wants AI to do.

Skill: how that capability is represented for a particular provider or format.

Not every capability has to be called a skill, and Commonset does not assume every AI platform will use that term.

Why the Distinction Matters

Without a provider-neutral concept, organizations can easily end up defining the same capability several times.

Imagine that Finance has developed a reliable process for analyzing expenses. If that process exists only as a skill inside one AI platform, moving it elsewhere may mean recreating it from scratch.

That can separate the new copy from important organizational context such as:

• ownership
• version history
• approval decisions
• provenance
• access rules
• security review
• usage information

Commonset separates the organizational capability from the systems that consume it.

The model may change. The capability should endure.

Version

A version is a concrete revision of a capability.

Versions are the unit Commonset can compare, review, approve, block through trust controls, deprecate, and distribute.

For example, Expense Analyzer v1.0 and Expense Analyzer v1.1 are two different versions of the same capability.

This distinction matters because approval should not silently transfer to future changes. In the current Commonset model, approved versions are immutable: changes belong in a new version.

Provider

A provider is a platform that can consume, store, or execute a capability.

Examples include AI providers and internal AI systems.

Commonset keeps provider-specific identifiers and metadata separate from its own capability identifiers. That prevents the identity of an organizational capability from depending on one vendor's data model.

Provider Adapter

A provider adapter is the integration layer between Commonset and a provider-specific API or format.

Adapters translate provider-specific concepts into Commonset's durable model while preserving details that do not map cleanly.

This is why two providers can support different operations without changing what the organizational capability means.

Distribution

A distribution is the act or state of making a particular capability version available to a provider, environment, team, or audience.

Distribution and approval are related, but they are not the same thing.

A version can be:

• approved but not distributed
• approved and distributed to one provider but not another
• approved in Commonset while blocked from a provider because the provider's audience or policy constraints do not match

Keeping these concepts separate lets Commonset show what the organization trusts independently from where a copy currently exists.

Collection

A collection is a logical grouping of capabilities used for organization or discovery.

Examples might include Finance, Engineering, Customer Support, or Production-ready capabilities.

A collection primarily answers: How do we organize these capabilities?

Commonset

A Commonset is the governed set of reusable capabilities available to a defined audience.

It answers a broader question:

What is the trusted set of capabilities this group can use?

Examples could include an Organization Commonset, Engineering Commonset, Finance Commonset, or Production Commonset.

The product representation of a Commonset may be expressed through collections, access rules, approval state, and policy as the model evolves. The durable idea is the governed set itself.

Organization and Team

An organization is the primary customer boundary for ownership, governance, access, policy, and administration.

A team or group is a set of people within that organization that may influence ownership, access, review, or distribution.

These boundaries matter because a capability can be trusted for one audience without automatically being available to everyone.

Ownership

Ownership identifies the person or team responsible for a capability's lifecycle and accuracy.

Ownership helps answer:

• Who maintains this?
• Who understands its intended purpose?
• Who should be involved when it changes?
• Who can decide whether it should be deprecated?

Reusable AI capabilities can become organizational assets. Assets need clear ownership.

Provenance

Provenance describes where a capability or version came from.

That can include:

• who created it
• whether it was imported
• the source provider
• an original provider identifier
• a repository or source reference
• a parent version
• a content or artifact hash

Provenance matters because trust depends on more than inspecting the current content. Organizations should be able to understand the history behind what they are using.

Review and Approval

A review is a structured evaluation of a version.

An approval is an explicit governance decision that the version meets the applicable trust requirements for the intended context.

Approval applies to a specific version. It does not mean every future revision is automatically approved.

Approval, Access, and Distribution Are Different

These concepts answer different questions.

Approval: Should the organization trust this version for the intended context?

Access: Who is allowed to discover, use, review, or manage the capability?

Distribution: Where has the approved version actually been made available?

A version could therefore be approved for organizational use, available only to Finance, and distributed to one AI provider.

The Mental Model

A useful way to think about Commonset is:

Organization → governed set → Capability → Version → Review and trust → Access → Distribution → Provider

Throughout that lifecycle, Commonset preserves context around ownership, provenance, security results, and availability.

Why This Model Exists

The vocabulary exists so an organization can answer questions that become difficult when AI capabilities are scattered across individual platforms:

• What capabilities do we have?
• Are two provider-specific implementations related to the same organizational capability?
• Who owns them?
• Where did they come from?
• Which version did we approve?
• Who can use it?
• Where is it available?
• What changes if we switch providers?

Commonset creates a layer where those answers can remain stable even as the AI ecosystem changes underneath them.

That is the core idea behind AI capability management.