Governance Above the Model Layer

AI governance is becoming a systems problem

Enterprise AI governance is often organized around models and model providers: which services are approved, what data may be sent to them, which users may access them, and which controls a provider exposes.

Those controls remain necessary. They are no longer sufficient.

Organizations are increasingly creating reusable AI capabilities: instructions, skills, tools, workflows, and other artifacts that encode how work should be performed. These capabilities are durable in a way that individual model sessions are not. They are revised, shared, reviewed, copied, deployed, and reused across teams. A capability may begin in one provider and later run through another. It may outlive the model for which it was first created.

That changes the control problem.

The organization is no longer governing only access to AI. It is also governing reusable organizational behavior expressed through AI.

A durable governance layer therefore needs to manage the lifecycle of the capability itself: identity, ownership, versions, provenance, review, approval, policy, access, distribution, and usage. The model remains an execution layer. Governance sits above it.

The central architectural shift is simple: govern the capability as an enterprise asset, and treat the model as one of the environments in which that asset executes.

The model is not the organizational control boundary

Provider-native controls are valuable because they operate close to execution. A provider can enforce identity, permissions, logging, data-handling rules, administrative policy, and deployment mechanics within its own environment.

The limitation is scope.

A multi-provider organization may use Claude for one workflow, ChatGPT for another, Gemini for a third, and internal applications backed by several model APIs. The same underlying capability can move through those environments over time. Each provider sees its own representation, identifiers, deployment state, and local controls.

The organization needs a different view: one that follows the capability across those representations.

Consider a contract-review capability used by Legal. The organizational object may have a stable owner, a current approved version, a review history, an allowed audience, and a policy requiring human review for high-risk contracts. Claude may receive one provider-specific representation of that capability while an internal application receives another. If the organization later changes models, the governance history should not reset simply because the execution target changed.

This distinction produces two complementary control planes:

• Provider controls govern execution inside a specific environment.
• Organizational controls govern the capability lifecycle across environments.

Trying to force the second problem entirely into the first creates fragmentation. Each provider becomes a partial source of truth, and the organization must reconstruct lifecycle state from several systems.

A governance layer above the model prevents that fragmentation without replacing the controls providers already supply.

Start by defining the governed object

Governance becomes much easier once the organization is explicit about what it is governing.

A reusable AI capability should have a stable organizational identity that is separate from any provider-specific identifier. That identity represents the capability over time, while versions represent immutable revisions of its contents and configuration.

This gives the organization three distinct concepts:

• Capability: the durable organizational asset, such as Contract Review.
• Version: an immutable revision, such as v2.3.1.
• Distribution: a record of where a particular version has been made available, such as Claude, an internal application, or another provider.

These concepts should not be collapsed into one mutable object.

If a capability is edited in place after approval, the meaning of approval becomes ambiguous. If provider deployment state is treated as organizational approval, a failed sync can look like a governance failure. If a provider identifier becomes the primary identity, moving the capability to another environment can break its history.

Separating identity, version, and distribution creates a cleaner model:

The capability persists. Versions are reviewed. Distributions deliver versions to execution environments.

That model is simple enough for users to understand and precise enough for security, audit, and automation.

Inventory is the first governance control

Organizations cannot govern a capability estate they cannot see.

Reusable AI behavior often begins informally. An employee develops a strong set of instructions. A developer packages a workflow. A team creates a reusable skill in a provider. Another team independently builds something similar. Over time, the organization accumulates useful but poorly cataloged operational logic.

An authoritative inventory should answer a small set of concrete questions through data rather than investigation:

• Which reusable capabilities exist.
• Who owns each capability.
• Which version is current and which version is approved.
• Which capabilities are experimental, reviewed, approved, blocked, or deprecated.
• Where each approved version has been distributed.
• Which teams can discover or use it.
• Whether duplicate or unmanaged variants exist.
• Whether the capability is still active or has become stale.

This does not require treating every prompt as a governed enterprise asset. The important boundary is reuse.

A one-off prompt can remain personal experimentation. A capability that is shared, embedded in a workflow, relied on by a team, or distributed through an organizational channel has crossed into a different category. It now carries operational consequences and deserves an organizational record.

That record is more than documentation. It is the anchor for every later control: ownership, review, policy, distribution, deprecation, and audit.

Inventory is therefore not a reporting feature. It is the first governance primitive.

Immutable versions turn governance into something precise

Versioning is where governance stops being a general intention and becomes an enforceable lifecycle.

Suppose Contract Review v2.3.1 has passed Legal and Security review. A creator then changes the instructions to improve clause extraction. If the capability is simply a mutable document with an Approved label, the system can no longer distinguish the reviewed artifact from the new draft.

Immutable versions solve that problem.

The approved revision remains v2.3.1. The new work becomes v2.4.0 or another draft revision. Review applies to the new version independently. Users can continue relying on the previously approved version until the replacement is ready.

This enables several important behaviors:

• Review attaches to an identifiable artifact. A reviewer knows exactly what was evaluated.
• Approval survives continued iteration. New drafts do not silently invalidate the stable version.
• Diffs become meaningful. A reviewer can focus on what changed between two immutable revisions.
• Distribution becomes traceable. Each target environment can reference the exact version it received.
• Rollback becomes deterministic. The organization can select a known earlier version rather than reconstructing history.
• Incident analysis becomes possible. Usage or behavior can be tied back to the version that was active at the time.

A useful governance system should make version transitions explicit instead of treating them as incidental editing history.

This also creates a natural operating rhythm: creators iterate freely in drafts, reviewers evaluate a specific candidate, approval promotes a specific version, and distribution moves that version into the environments where it is allowed to run.

Provenance establishes where trust came from

Content alone is not enough to establish trust.

Two capabilities can contain identical instructions and still deserve different treatment because their origins differ. One may have been authored by a known internal owner. Another may have been imported from an employee account. A third may have been generated by an LLM, transformed into a provider-specific format, and then edited manually. A fourth may have come from an external repository.

Provenance records that history.

At minimum, useful lineage should preserve:

• Origin: internal creation, import, repository, provider, generated output, or another source.
• Creator or importing identity.
• Parent or predecessor version.
• Transformations applied between source and distributed form.
• Provider-specific representation when one exists.
• Review and approval events.
• Distribution events and target environments.

This lineage becomes operationally important when behavior changes.

If a capability produces an unexpected result after deployment, the organization should be able to trace the active distribution back to its immutable version, identify the source of that version, see what changed from the prior approved version, and understand how the provider-specific representation was produced.

Without provenance, investigation becomes archaeology. Teams reconstruct history from chat messages, repositories, provider consoles, and individual memory.

With provenance, trust has a chain of custody.

Governance state and distribution state must remain separate

One of the easiest mistakes in AI capability management is to treat “published” as a single universal state.

Organizational approval and provider distribution are different events.

A capability version can be approved but not yet distributed. It can be approved for Legal but not Finance. It can be allowed in an internal environment while blocked from a provider that does not meet a data-handling requirement. A provider-specific transformation can fail validation even though the source version remains trusted. A target system can be temporarily unavailable without changing the governance state of the capability itself.

A more accurate model tracks these dimensions separately.

For example:

• Lifecycle state: Draft → In review → Approved → Deprecated.
• Policy state: Allowed, conditionally allowed, or blocked for a particular context.
• Distribution state: Not distributed, pending, in sync, failed, or removed for each target.

This lets the system express a precise statement such as:

Contract Review v2.3.1 is approved for the Legal team, allowed for use with the approved provider set, and currently in sync with Claude and the internal contract application.

That statement is significantly more useful than a generic Published badge because it separates organizational trust from operational delivery.

It also improves automation. A failed distribution can trigger an operational retry without reopening governance review. A newly blocking policy can prevent future distribution without erasing the historical fact that the version was once approved.

Policy should encode organizational intent

Governance scales when recurring decisions become explicit rules rather than repeated conversations.

Some policies are straightforward:

• Every organizational capability must have an accountable owner.
• Only immutable approved versions may be distributed to production environments.
• Capabilities using specified tools or sensitive data classes require additional review.
• Deprecated versions cannot receive new distributions.
• Certain teams may use only an approved subset of providers.
• A provider-specific transformation must pass validation before it is marked in sync.

Other policies will depend on business context, risk, geography, data classification, audience, or workflow.

The architectural requirement is consistency. The organization should define the policy once at the organizational layer and then apply it wherever the capability moves.

Provider-native controls still matter. They are often the best place to enforce an execution-time restriction. But the durable statement of organizational intent should not have to be recreated separately in every provider console.

A strong policy system also produces explainable outcomes.

“Blocked” should not be a dead end. The system should record which rule applied, the context in which it applied, and what condition would allow the capability to proceed. That gives creators actionable feedback and gives security an auditable decision trail.

Policy becomes most useful when it removes repetitive judgment from routine cases and focuses human attention on exceptions.

Access control should cover the capability lifecycle

Authentication establishes identity. Governance determines what that identity may do.

For reusable AI capabilities, authorization needs to cover more than execution. Different roles may be allowed to discover, create, edit, review, approve, distribute, deprecate, or administer a capability.

These permissions can depend on organization membership, team, role, environment, trust state, sensitivity, and policy. They also apply to machine identities such as provider integrations, deployment jobs, APIs, and agents.

A practical model follows least privilege across the lifecycle:

• Creators can iterate without automatically gaining approval rights.
• Reviewers can evaluate candidate versions without necessarily controlling distribution.
• Distribution services can publish an approved version without gaining broad administrative access.
• Users can discover and execute capabilities appropriate to their teams without seeing administrative controls.
• Platform operators can maintain infrastructure without routine access to customer capability content.

Separating these responsibilities reduces the blast radius of both mistakes and compromised credentials.

It also makes governance easier to explain. An access decision can be tied to a role and a lifecycle action rather than hidden inside a broad administrator permission.

Trust should be visible in the product

A governance system should make consequential state legible to the people making decisions.

A user selecting a capability should not need to reconstruct trust from a repository, a ticket, and an administrator’s message. A reviewer should not have to search several systems to understand what changed. An administrator should be able to see why a capability cannot be distributed.

Useful visible trust signals include:

• Owner.
• Current version.
• Approval state.
• Review history.
• Applicable policy outcomes.
• Provenance.
• Allowed audience.
• Distribution state by environment.
• Deprecation or blocking state.

The purpose is not to expose every internal control detail on every screen. The purpose is to surface the state relevant to the decision being made.

For a business user, that may be as simple as Approved by Legal · v2.3.1 · available in Claude.

For a reviewer, the same capability may expose the diff from v2.3.0, provenance, policy checks, and the requested distribution targets.

For security, it may expose the full lifecycle record and any exceptions.

Trust becomes more useful when the interface communicates why an artifact is trusted, not merely that a system has labeled it trusted.

Governance should create a fast path, not a queue

Governance fails when every change receives the same level of ceremony.

A healthy system distinguishes experimentation from organizational publication and low-risk changes from high-risk changes. It automates decisions where the rules are clear and escalates only the cases that require judgment.

That operating model can look like this:

1. A creator iterates freely on a draft capability.
2. The creator proposes a specific immutable version for organizational use.
3. Automated checks evaluate ownership, required metadata, policy, and provider constraints.
4. Human review focuses on the substantive changes and any exceptions the automated checks surfaced.
5. Approval applies to that exact version and context.
6. Distribution services publish the approved version only to allowed targets.
7. Usage and lifecycle signals feed back into later review, maintenance, and deprecation decisions.

This is governance without gridlock because the system does not treat governance as an external checkpoint. Governance is built into the lifecycle.

The safe path becomes the easiest path: creators know what is required, reviewers see only what matters, users can identify trusted artifacts, and administrators can establish policy without manually adjudicating every routine action.

Provider adapters translate governance without owning it

A provider-neutral control layer does not imply that providers are interchangeable.

They are not.

Providers expose different capability formats, identifiers, metadata, deployment APIs, permission models, and constraints. Those differences matter and should remain visible.

The stable architectural pattern is to keep the organizational model neutral while using provider adapters to translate between the durable capability and each target environment.

The organizational layer owns facts such as:

• Capability identity.
• Ownership.
• Immutable versions.
• Provenance.
• Review and approval state.
• Policy outcomes.
• Intended access.
• Distribution records.

The adapter owns provider-specific concerns such as:

• Native identifiers.
• Format conversion.
• Provider-specific fields and extensions.
• API mechanics.
• Validation constraints.
• Sync state.

This boundary preserves portability without pretending provider differences do not exist.

It also protects the governance model from provider churn. A new model or platform requires a new adapter and set of constraints, not a redefinition of ownership, approval, provenance, or version history.

Observability closes the lifecycle

Approval is not the end of governance.

Once capabilities become operational assets, organizations need enough telemetry to understand whether those assets remain useful, controlled, and maintained.

Useful signals include adoption by team, execution or invocation volume, active provider distributions, version uptake, stale distributions, deprecated-version usage, failed syncs, and capabilities that have not been used for a meaningful period.

These signals improve both operations and governance.

A heavily used capability may deserve stronger ownership, testing, and change controls. A capability with no usage may be a candidate for deprecation. Continued use of an obsolete version can reveal a distribution gap. A sudden drop after a new release can justify rollback or review.

The goal is not exhaustive surveillance. Capability analytics can be useful without collecting every user interaction or centralizing unnecessary content. Data minimization should remain part of the design.

The important point is feedback: governance should operate on the real lifecycle of the capability, not only on the moment it was approved.

The governance system must govern itself

A control plane that centralizes capability metadata, policy, provenance, access decisions, and distribution records becomes part of the organization’s trust boundary.

That creates obligations for the governance system itself.

Tenant boundaries should be explicit. Human and machine access should follow least privilege. Administrative changes should be auditable. Customer capability intellectual property should remain the customer’s. Support and platform operations should avoid standing access to raw customer content where possible. Storage architecture should preserve stronger isolation options for customers that require them.

These controls are not separate from the product thesis.

A system cannot credibly make trust visible for customer capabilities while making its own operator access opaque.

Trust is a product behavior before it is a compliance claim.

A durable control plane above the model layer

The practical result is an architecture with a stable organizational layer above a changing execution layer.

At the organizational layer, a reusable capability has a stable identity, accountable owner, immutable versions, provenance, review history, approval state, policy outcomes, access intent, distribution records, and operational signals.

At the provider layer, adapters translate approved versions into the formats and APIs each environment supports, preserve provider-specific constraints, and report distribution state back to the organizational record.

At the execution layer, provider and application controls enforce the restrictions that must operate close to the model and data.

Each layer has a different responsibility. None needs to replace the others.

This division of responsibility is what makes governance durable.

Models will continue to change. Provider-specific skill formats will evolve. Teams will adopt new tools. Internal applications will appear and disappear. None of those changes should erase the organization’s understanding of the reusable capability itself.

The enduring asset is the capability and its lifecycle.

The control plane exists to make that lifecycle owned, versioned, traceable, explainable, portable, and trusted wherever the capability runs.

---

Commonset is building the control plane for reusable AI capabilities — one place for organizations to create, review, govern, distribute, discover, and understand the capabilities their people and AI systems rely on.