Managing Access

Trust and access are related, but they are not the same control.

A capability can be approved and still be intentionally limited to a specific team or user. Likewise, a creator may be allowed to use a trusted draft privately without that draft becoming approved for the organization.

Commonset keeps those decisions separate so access can be precise and explainable.

Approval vs. Access

Use this distinction throughout the product:

Approval: Does this exact version meet the applicable trust requirements?

Access: Who is allowed to interact with the capability, and how?

Approval should never be treated as an automatic organization-wide grant.

Capability Permissions

Commonset's capability access model includes four permissions:

Discover

Allows a user to know the capability exists and find it through the Commonset registry or supported discovery surfaces.

Use

Allows a user to consume an available trusted version of the capability.

Review

Allows a user to inspect governance versions and participate in review workflows where applicable.

Manage

Allows a user to create or update versions and manage the capability's lifecycle within the permissions of their organization.

These permissions represent different levels of responsibility. A user who can discover a capability does not automatically gain the ability to use or change it.

Grant Subjects

Access grants can target different kinds of organizational subjects:

• the organization
• a group or team
• an individual user

This makes it possible to express patterns such as:

• everyone may discover a capability, but only Finance may use it
• a security group may review a capability without owning it
• one developer may manage a capability while a broader engineering group may use it

Commonset validates that user and group grants remain within the same organization as the capability.

Runtime Availability Is a Separate State

A version also has an effective availability scope.

Working scopes include:

Unavailable

The version cannot currently be used as a runtime version.

Creator only

The version remains available to its creator or owner while broader governance continues, when policy and trust checks allow it.

This is useful for experimentation without making the version organizationally approved.

Explicit team

The version is available to a defined team or group audience.

Organization

The version is available across the organization subject to the applicable capability permissions.

The important rule is:

Availability describes who can receive a trusted runtime version. It does not rewrite the review history.

Creator-Only Availability

Creator-only availability is a deliberate governance pattern.

A creator can sometimes continue testing a draft after automated trust checks pass while the version is still Draft or In Review.

That helps reduce incentives to keep useful work outside the registry simply to avoid a review queue.

The UI should make the limitation clear:

• creator-only does not mean approved
• creator-only does not mean the team can use it
• creator-only does not allow provider publication that requires organizational approval

If a trust condition later blocks the version, creator availability can also be removed.

Access and Ownership

Ownership identifies who is responsible for a capability's lifecycle and accuracy.

Ownership is not a substitute for access grants.

An owner may have management responsibility, while other users receive use or review permissions according to organizational policy.

This distinction becomes more important when capabilities outlive their original creator or move between teams.

Access and Provider Distribution

Commonset controls access inside the Commonset governance model. Providers have their own audience models.

Those models do not always match.

A provider may expose a skill at:

• workspace scope
• project scope
• organization scope
• user or group scope

The exact options depend on the provider surface.

This creates an important publication question:

If Commonset says only this team may use the capability, does the provider make the published copy available to a broader audience?

Commonset treats that mismatch as a distribution-policy concern rather than pretending the provider has controls it does not expose.

Broader Provider Audiences

Some provider surfaces can be broader than Commonset grants.

For example, a workspace-scoped provider skill may become visible across the connected workspace even when the Commonset capability is intended for a smaller group.

When a provider cannot enforce the Commonset audience directly, your policy should choose one of three approaches:

1. Do not publish to that provider surface.
2. Broaden Commonset access intentionally before publication.
3. Use an explicitly approved, time-limited distribution exception when your organization permits one.

Exceptions should be attributable and explain why the broader provider audience is acceptable.

Recommended Access Patterns

Organization-wide approved utility

Use organization-level discovery and use for capabilities that are intentionally safe and useful across the company.

Team-owned specialist capability

Grant team-level use, narrower management rights, and review rights to the appropriate governance group.

Sensitive capability

Keep discovery and use narrow, require independent review, and publish only to provider surfaces whose audience is compatible.

Early experiment

Allow creator-only availability after trust checks, then request review before team or organizational use.

Access Changes Over Time

A capability's audience can change even when the approved version does not.

For example:

• Finance may initially be the only group allowed to use a capability.
• After adoption and review, access may expand to Procurement.
• Later, the capability may be deprecated and new access may be discouraged.

Because access is separate from immutable version content, Commonset can change who is allowed to use a trusted version without rewriting that version.

Questions to Ask Before Granting Access

Before broadening access, ask:

• Does this audience need to discover the capability, use it, review it, or manage it?
• Is the version currently approved or otherwise intentionally available to this audience?
• Does the capability handle sensitive data or tools?
• Does the provider distribution audience match the Commonset audience?
• Is the owner still accountable for the capability?
• Would a narrower group grant meet the need?

The goal is least privilege without unnecessary friction: make the intended audience visible and make broader access deliberate.