Understanding Capabilities, Skills, and Commonsets

Organizations are beginning to accumulate reusable AI work faster than they are developing a coherent way to manage it. Some of that work lives in Claude as Skills. Some lives in ChatGPT, internal agents, repositories, project instructions, tools, workflows, or provider-specific configurations. The vocabulary is inconsistent because the underlying platforms are inconsistent, and there is no reason to expect that to change soon. What matters is that many of these artifacts are starting to encode real organizational knowledge: how a team reviews a contract, investigates an incident, prepares research, evaluates a security finding, writes production code, or carries out some other repeatable process. Once that happens, treating each artifact primarily as an object belonging to the platform that hosts it becomes increasingly awkward. The organization cares less about the provider's name for the artifact than it does about the durable thing the artifact represents, the history behind it, who owns it, which revision was approved, where it came from, who can use it, and where it has been made available.

Commonset starts from that distinction. A capability is the durable function the organization wants AI to be able to perform. A skill is one possible implementation of that capability for a particular provider or format. The difference sounds semantic until you start trying to govern these things across more than one system. Suppose a legal team spends weeks refining a contract review process, incorporating company policy, testing difficult cases, assigning an owner, and eventually approving a particular revision for use. Today, that work might be packaged as a Claude Skill. Tomorrow, the same organization may want an implementation for a different provider, an internal agent, or a repository-backed workflow. If the Claude artifact itself is treated as the organizational identity, the team has to recreate the surrounding context every time the implementation moves. If Contract Review is instead treated as the enduring capability, the provider-specific artifact becomes one representation of something the organization already knows how to identify and govern.

This is why Commonset does not try to solve the problem by inventing one universal artifact format. The provider differences are real. One system may define a skill as a directory of instructions and supporting files. Another may expose a tool, project, agent, workflow, or configuration object that serves a similar organizational purpose while behaving very differently at the technical boundary. Flattening those differences would make the model simpler on paper and less useful in practice. Commonset instead keeps a stable organizational identity above the implementations while preserving provider-specific details where they actually matter. That allows two artifacts to be understood as related to the same underlying capability without pretending they are structurally identical or operationally interchangeable. It also means that ownership, provenance, review history, access rules, and lifecycle do not have to become properties of whichever provider happens to be hosting the current copy.

That separation becomes especially important once you realize that copying instructions is not the same thing as preserving a capability. Imagine that Finance has built an expense analysis workflow that has been used for six months. The team knows who owns it, where it came from, which revision was reviewed, which security findings were resolved, and which people are allowed to use it. Now copy the instructions into another AI platform. You have transferred some of the content, but you have not necessarily transferred the thing the organization was governing. Which revision was copied? Did anything change during translation? Does the earlier review still apply? Is the new artifact still related to the approved version, or is it merely similar? Who owns the new copy? Which one is authoritative? Are the same people supposed to have access? These questions are easy to ignore when a few individuals are experimenting with AI tools. They become much harder once reusable AI work starts moving among teams, repositories, providers, and internal systems.

The capability therefore needs more than an identity. It also needs a history. Commonset treats a version as a concrete revision of a capability that can be compared, reviewed, approved, blocked, deprecated, and distributed independently. This is one of the places where apparently small modeling choices have significant governance consequences. Saying that "Contract Review is approved" is not precise enough if Contract Review has changed twelve times. What is actually approved is a particular revision under a particular set of assumptions. If Contract Review v2.3 has completed review and someone changes the instructions to produce v2.4, the approval on v2.3 should not silently follow the change. The organization should be able to inspect what changed and decide whether the existing evidence is still sufficient. In Commonset, approved versions are immutable and changes create a new version. That gives approval something stable to refer to and prevents trust from becoming a label that persists while the underlying artifact quietly changes.

The same need for precision is why Commonset separates approval, access, and distribution rather than collapsing them into one state. Approval answers whether a particular version has met the organization's trust requirements for the intended context. Access answers who is allowed to discover, use, review, or manage it. Distribution answers where that version has actually been made available. These states interact, but they are not interchangeable. A Finance capability may be approved for organizational use while remaining accessible only to Finance. It may be distributed to one provider but not another. A newer revision may be under review while the previous approved revision remains available in production. None of these situations is unusual. They are the ordinary consequences of managing something that has a lifecycle. A system that reduces them to an approved=true flag loses exactly the distinctions that become important when an organization needs to explain why something is available, who made that decision, and what would have to change before a different version could be used.

Provenance is part of that explanation. Looking at the current contents of an artifact can tell you what it contains, but it cannot tell you the full history of what you are evaluating. A capability might have been created internally, imported from GitHub, copied from an external repository, discovered inside a provider account, or derived from an earlier version the organization already reviewed. It may carry a source identifier, repository reference, parent version, content hash, or other evidence that helps establish where it came from and how it relates to what came before. Those facts do not prove that a capability is safe, and Commonset should not pretend they do. They do, however, affect the meaning of the evidence around it. Two skills with identical visible instructions can have very different histories if one came from an internally maintained repository and the other arrived from an unknown external source. Provenance gives the organization a way to make that history explicit instead of treating every artifact as if it appeared fully formed in its current state.

Ownership has a similarly practical role. Reusable AI capabilities often become organizational assets before anyone formally decides to treat them as such. A developer builds something useful, several people begin using it, another team copies it, and six months later the artifact is involved in a recurring engineering, security, finance, or customer workflow. At that point, asking who maintains it is no longer administrative housekeeping. Someone needs to understand the intended behavior, evaluate changes, respond when assumptions become outdated, and decide whether the capability should be revised, replaced, or retired. Commonset keeps ownership with the capability because responsibility should not disappear when the implementation moves between systems. The organizational identity, history, and accountability around the work should be able to survive changes in provider just as the capability itself does.

This is also why providers belong at the boundary rather than at the center of the model. Claude, OpenAI, internal systems, and whatever comes next will continue to expose different APIs, file formats, permissions, publishing mechanisms, identifiers, and execution environments. Commonset should understand those differences, not erase them. A provider adapter can translate between Commonset's durable model and a provider's particular implementation while preserving the details that do not map neatly. That lets the organizational identity remain stable without pretending the provider is irrelevant. We describe this as model-agnostic rather than model-independent for exactly that reason. The provider still matters operationally. It simply should not own the enduring identity of the thing the organization has decided to manage.

A Commonset is the next layer in that model. An inventory can tell an organization what artifacts exist, but existence is not the same thing as usability. A company may have dozens or hundreds of skills, agents, workflows, and other capabilities scattered across teams and systems, including experimental work, old versions, restricted artifacts, unreviewed imports, and capabilities that are no longer intended for use. That inventory is useful, but it does not answer the question an employee actually has when trying to get work done: which of these should I use? A Commonset represents the governed set of capabilities available to a defined audience. An Engineering Commonset might contain the capabilities Engineering is currently allowed to discover and use. Finance may have another. Some artifacts can exist in the broader organizational inventory without belonging to either usable set because they are still under review, restricted, deprecated, or simply irrelevant to that audience. Inventory tells you what exists. A Commonset tells you what belongs in the trusted, usable set for a particular group.

Consider a capability called Security Review. The organization uses it to evaluate reusable AI skills before they are adopted internally. Security Review has an identity that persists as the implementation changes, an owner who is responsible for maintaining it, and provenance that describes where it came from. v2.1 has completed review and is approved, which means the evidence supporting that decision applies to v2.1, not automatically to everything called Security Review in the future. A developer then creates v2.2 with additional analysis logic. Commonset can preserve the relationship between the revisions while still recognizing that the new behavior may require another review. Security Engineering can have access to v2.2 while evaluating it, the wider organization can continue using v2.1, and distribution records can show which providers currently have the approved revision installed. No individual provider needs to understand Commonset's entire governance model for any of this to work. Each provider can continue representing and executing the artifact in its own way while Commonset preserves the organizational context above it.

That context is ultimately the point. An organization should be able to answer what capabilities it has, which provider-specific artifacts represent the same underlying function, who owns them, where they came from, what changed between versions, which revision was actually reviewed, which revision is currently approved, who can use it, where it is available, and what happens to all of that context if the provider changes. These are the questions we mean when we talk about AI capability management. The important shift is to stop treating reusable AI work as a collection of isolated artifacts owned by whichever platform currently hosts them. Once those artifacts begin to encode how an organization actually operates, they need an identity, history, ownership model, trust model, and lifecycle of their own. Commonset is being built to provide that layer.