Reviewing and Approving Capabilities

Review is where Commonset turns a reusable AI capability from something that exists into something the organization can deliberately trust.

The review is attached to a specific version so the decision has a clear object: this exact content, at this point in time.

What Approval Means

Approval means that a version meets the applicable organizational trust requirements for its intended context.

Approval does not automatically mean:

• everyone in the organization can use it
• every provider can receive it
• a future version is also approved
• an automated security scan found no risk
• the capability should remain approved forever

Those questions are handled by access, provider distribution policy, versioning, and lifecycle controls.

1. Start With the Version

Before reviewing, confirm which version is under consideration.

A capability can have several versions with different review and security states. Review the version identifier, owner, creator, release notes, and provenance before making a decision.

If a previous version exists, understand what changed rather than evaluating the new version in isolation.

2. Read the Change Summary

Commonset can summarize meaningful changes between versions.

Depending on the capability, changes may include:

• instructions added, removed, or modified
• supporting files changed
• scripts or executable resources introduced
• tool or access declarations changed
• provider metadata changed
• security findings introduced or resolved

Start with the human-readable summary, then use the technical diff when you need file-level evidence.

3. Review Security and Trust Results

Security analysis is an important input to review, not a substitute for it.

A version can have a trust/security result such as Clean, Warning, Blocked, Pending, or Error.

Clean

Automated checks did not identify a current blocking condition.

Warning

The version can require additional reviewer attention. Depending on policy, approval may be allowed only when the reviewer documents why the remaining risk is acceptable.

Blocked

A blocking trust or policy condition prevents approval or provider publication until it is resolved.

Pending or Error

The expected trust evidence is incomplete or could not be produced. Treat the reason as part of the review rather than assuming the capability is safe.

4. Inspect New Findings Closely

When a new version introduces a security finding, focus on what changed.

Useful reviewer questions include:

• Did the version add executable behavior?
• Did it introduce network, file, credential, or tool access?
• Did the capability's scope expand?
• Does the finding affect the intended audience or provider?
• Is the proposed mitigation sufficient?
• Is the risk temporary, structural, or provider-specific?

Resolved findings are also useful because they show whether an update actually addressed an earlier concern.

5. Check Provenance and Ownership

Trust is easier to reason about when the version has a clear source.

Review provenance such as:

• creator
• import source
• provider record
• parent version
• source reference
• content hash

Then confirm that the capability has an accountable owner who understands its purpose and maintenance expectations.

Unknown ownership or unclear provenance does not automatically make a capability malicious, but it should lower confidence until the gap is resolved.

6. Use AI Explanations as Advisory Evidence

When an appropriate LLM integration is configured, Commonset may offer an AI-generated explanation of how a version changes behavior, scope, or reviewer concerns.

Treat this as an aid to comprehension.

It does not replace:

• the deterministic file diff
• security analysis
• policy checks
• human judgment
• the final review decision

An AI summary can be wrong or incomplete. Reviewers remain responsible for the decision.

7. Respect Separation of Duties

Organizations may require a different person to approve a version than the person who created it.

When separation of duties is enabled, self-approval is blocked even if the creator otherwise has reviewer permissions.

This is especially useful for production, security-sensitive, or broadly distributed capabilities.

8. Approve or Request Changes

A review round ends with a deliberate decision.

Approve

Use approval when the version meets the applicable trust requirements and any required risk acceptance has been documented.

Request Changes

Use this when the version needs modification, clarification, additional evidence, or risk reduction before it can be approved.

Keep comments specific. Explain what must change and why so the next review has a clear baseline.

Review Decisions Are Governance Evidence

Commonset preserves review decisions as immutable governance evidence.

The reviewer, decision, comment, and time should remain attributable after the review closes.

If circumstances change later, make a new lifecycle or governance decision rather than rewriting the historical record.

Approval Is Version-Specific

A major Commonset rule is:

Approved content does not change in place.

Approved versions are immutable. If the instructions, metadata, or files need to change, create a new version.

This prevents a capability from changing after reviewers have approved it without triggering a new governance event.

Approval Is Not Access

An approved version can still be restricted to a subset of users.

For example, Legal may approve a Contract Review capability while access remains limited to Legal and Procurement.

Reviewers should understand the intended audience, but access grants are a separate control.

Approval Is Not Provider Publication

A provider can have distribution constraints that Commonset approval alone cannot satisfy.

Provider publication may still be blocked when:

• the provider audience is broader than Commonset access
• the connection does not support publishing
• provider-specific validation fails
• the provider connection is unavailable
• organizational policy requires an additional condition

This separation is intentional. Commonset approval establishes organizational trust; provider publication is a separate distribution action.

Reviewer Checklist

Before approving a version, confirm:

1. I know exactly which version I am reviewing.
2. I understand the intended purpose and owner.
3. I reviewed the meaningful changes from the previous version.
4. I reviewed new security findings and capability-scope changes.
5. Provenance is reasonable for the intended use.
6. Any warning-level risk acceptance is documented.
7. I understand the intended Commonset audience.
8. I am not treating an AI-generated summary as authoritative evidence.
9. The decision applies to this version, not future changes.
10. Provider publication will still go through its own checks.

The goal is not maximum process. The goal is a review record that another person can understand later and answer: Why did we trust this version?