Forward looking, PFEM was unsure about this so far, and says "after the lifecycle docs"

[lightrock]

Title: Model registry and ecosystem trust as a first-class evidence layer

This is a forward-looking architecture suggestion, not a bug report.

Bawbel already scans individual MCP server cards, manifests, tool descriptions, skill files, and conformance properties. That is a strong local scan layer.

The next trust problem is bigger than one server.

Because MCP servers live in registries, marketplaces, package ecosystems, Git repositories, hosted endpoints, and local agent runtimes, trust becomes polycentric fast. A scanner may evaluate one server card today, but the ecosystem includes many evidence sources:

• registry metadata
• server-card content
• Git repository identity
• package/version identity
• publisher identity
• install rank / popularity
• pinned local contracts
• runtime hooks
• local exceptions
• accepted risks
• server updates
• schema drift
• vulnerability database updates
• downstream agent behavior

No single artifact is the whole truth.

Core distinction:

A server-card scan is not ecosystem trust.
A conformance score is not publisher trust.
A popular registry entry is not proof of safety.
A GitHub repository URL is not proof of source integrity.
A pinned local contract is not the registry truth.
A registry update is not automatically an approved local update.
A runtime hook result is not the same evidence type as a static registry scan.

Proposal:

Add a forward-looking guide for registry / ecosystem trust.

Possible doc path:

docs/guides/ecosystem-trust.md

The guide could define evidence objects such as:

• registry_entry
• server_card
• package_version
• source_repository
• publisher_identity
• install_event
• local_pin
• scan_result
• conformance_report
• accepted_exception
• runtime_observation
• runtime_drift_event
• vulnerability_database_record

It could also define trust transitions such as:

• discovered_in_registry
• scanned_at_version
• pinned_locally
• approved_in_git_review
• updated_in_registry
• local_pin_outdated
• schema_drift_detected
• runtime_behavior_mismatch
• new_vulnerability_record_applies
• exception_accepted
• exception_expired
• server_delisted_or_deprecated

The point is not to implement all of this immediately. The point is to name the evidence objects now so future registry, pinning, runtime, and trace features do not grow in incompatible directions.

Why this matters:

As MCP adoption grows, the security question is not only:

"Does this one server card look dangerous?"

It also becomes:

"Can I trust this server over time?"
"Can I trust this publisher?"
"Did this update change the tool contract?"
"Does my local approved version differ from the registry version?"
"Does runtime behavior match either one?"
"Can I explain why the trust decision changed?"

That is the polycentric federated evidence mesh problem: many independent registries, publishers, package versions, server cards, local pins, scanner runs, accepted risks, runtime observations, and vulnerability records all contribute partial evidence.

The scanner should preserve those evidence boundaries instead of collapsing everything into one static trust score.

Benefit:

This would give Bawbel a clear path toward registry-scale trust history, local pin vs registry update comparison, better runtime hook context, better tracing for multi-agent delegation chains, and dashboards that can explain trust changes over time.

The goal is evidence continuity between static scanning, local approval, and runtime enforcement.

[chaksaray]

This is world-class architectural guidance.

You have perfectly captured the exact friction point of the decentralized MCP ecosystem: trust is a dynamic state machine, not a static snapshot.

A server that gets a clean "A+" conformance score on Monday can drift, suffer a registry package hijack, or change its runtime behavior on Tuesday. If we treat the initial scan as a permanent passport rather than a transient piece of a larger evidence puzzle, we fail at zero-trust.

Preserving Evidence Boundaries Over Time

Your distinction list is spot on and hits directly at the core philosophy of our upcoming phases:

• A conformance score is not publisher trust.
• A registry update is not automatically an approved local update.

If a local corporate environment pins an MCP tool configuration using an immutable schema hash, and a public registry issues an upstream package update, that delta itself is critical evidence. It isn't necessarily a "vulnerability" in the CVSS sense, but it is an unverified boundary transition that requires local Git/policy review before promotion.

The Value of Naming Objects Early

Your proposal to establish docs/guides/ecosystem-trust.md right now to explicitly map these domain primitives (registry_entry, local_pin, runtime_drift_event) is incredibly smart. It guarantees that as we write the core Go logic and OCI artifact templates for downstream engines, we don’t accidentally box ourselves into a rigid, non-extensible schema.

Next Steps

1. The Lifecycle Blueprint first: As noted in Issue PFEM thinks the documentation on the lifecycle needs an update, index, overview type thing #71, I am currently compiling our internal master plan specs into a public-facing LIFECYCLE.md file so you can see exactly how we intend data to flow between scan, contract, and trace.
2. Drafting the Ecosystem Trust Model: Once that baseline flow is in the repo, I want to formally open a pull request to add the docs/guides/ecosystem-trust.md file using the exact vocabulary and state transitions you laid out here.

I want to make sure your name is explicitly attached to this design framework. When I drop the initial lifecycle overview documentation into the repo over the next few days, I would love for you and your agent to audit the boundaries and help us lock down this exact state machine.

Thank you for bringing this level of systems discipline to the project 👍