Understanding Trust Status

A capability can be safe but unapproved. Approved but unavailable to you. Available to its creator but not the organization. Deprecated but still present for history. Approved locally but blocked from a provider because the provider audience is too broad.

That is why Commonset does not reduce trust to a single green or red badge.

The product separates several related states so users can see what is true and why.

The Five Questions

When looking at a capability version, Commonset should help you answer five different questions:

1. Lifecycle: Is this capability active, deprecated, or archived?
2. Review: Has this version been drafted, reviewed, approved, or rejected?
3. Trust/security: Do current automated and policy checks allow it?
4. Availability: Who can currently receive this version at runtime?
5. Publication: Can this version be distributed through a particular provider surface?

These states work together, but they should not be conflated.

1. Capability Lifecycle

Lifecycle applies to the overall capability rather than one review event.

Active

The capability is available for normal ongoing lifecycle activity.

Deprecated

The capability remains part of the registry and history, but users should generally move toward a supported replacement for new use.

Archived

The capability is retained as a record but is treated as read-only and unavailable for normal new lifecycle actions until reactivated.

Lifecycle helps answer whether the capability as a whole is still intended for ongoing use.

2. Version Review State

Each version has its own review state.

Draft

The version is being developed and has not been organizationally approved.

In Review

A review request is open for the version.

Approved

The version received the applicable organizational approval decision.

Rejected

The version did not receive approval in its current form.

Deprecated

The version remains part of history but should generally not be selected for new use.

Approval is version-specific. A capability can therefore have an approved v1.0 while v1.1 is still Draft or In Review.

3. Security and Trust Result

A version separately records the result of Commonset's security/trust analysis.

Pending

Trust analysis has not completed or the expected result is not yet available.

Clean

Current automated checks do not identify a blocking condition.

Warning

The version has findings that require attention but may be reviewable depending on organizational policy.

Blocked

Current trust or policy conditions prevent normal deployment or approval progression.

Error

The trust process could not produce a valid result. Treat the missing evidence as a problem to resolve rather than assuming the version is safe.

A Clean result is not the same as Approved. Automated checks can establish technical evidence; organizational approval remains a governance decision.

4. Runtime Availability

Availability determines whether a particular user can receive a trusted runtime version.

Working scopes include:

Unavailable

The version cannot currently be selected for runtime use.

Creator only

The creator or owner may use a trusted draft privately while governance continues.

This state is explicitly not organizational approval.

Explicit team

The version is available to a defined team/group audience according to grants and trust state.

Organization

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

Availability can change without changing immutable version content.

5. Publication Readiness

Provider publication is another gate.

A version can be approved and trusted in Commonset but still not ready to publish to a provider.

Commonset's publication reasoning includes:

• Is the version approved?
• Do current trust checks pass?
• Is the capability active and publishable?
• Does the provider connection support publication?
• Is the provider audience compatible with Commonset access?
• Do provider-specific checks pass?

This distinction prevents an organizational approval decision from being mistaken for permission to distribute anywhere.

Why “Blocked” Can Mean Different Things

The word blocked should always have context.

A version may be blocked by a security finding, a policy rule, or a provider-distribution constraint.

The UI should explain the reason rather than presenting a red label alone.

For example:

Provider publication blocked by audience scope. Commonset access is limited to Finance, while this provider surface publishes workspace-wide.

That is more useful than simply saying Blocked.

Example: Trusted Draft

Imagine a developer creates Data Cleanup v0.2.

• Capability lifecycle: Active
• Review: Draft
• Security: Clean
• Availability: Creator only
• Provider publication: Not ready because organizational approval is required

The developer can continue testing without anyone mistaking the version for organization-approved content.

Example: Approved but Narrowly Available

Legal approves Contract Review v2.1.

• Capability lifecycle: Active
• Review: Approved
• Security: Clean
• Availability: Explicit team
• Commonset audience: Legal and Procurement

The version is trusted, but it is not available to everyone.

If a provider surface would publish it workspace-wide, provider publication can still be blocked by audience policy.

Example: New Version Under Review

Contract Review v2.1 remains approved while v2.2 is submitted.

• v2.1: Approved and available
• v2.2: In Review
• v2.2 security: Warning

The existing approved runtime version can remain the trusted version while reviewers decide whether the newer revision should replace it.

Example: Deprecated Capability

A newer capability replaces an older one.

The old capability may remain visible with:

• lifecycle: Deprecated
• historical approved versions retained
• replacement capability identified

This preserves auditability without encouraging new adoption.

Trust Is a Composition

The most useful mental model is not What color is the badge?

It is:

What evidence and policy decisions make this version available to this user in this context?

Commonset can compose review status, security results, grants, lifecycle, and provider policy into that answer.

Make Trust Visible

Trust should be explainable at the point of use.

When something is unavailable or blocked, Commonset should show:

• the relevant state
• the reason
• the version involved
• what action can resolve it
• whether the limitation applies locally, to a particular audience, or only to provider publication

That is what AI capabilities. Governed. means in practice.