Trust metadata may describe declared confidence, verification status, verification source, supporting signals, audit context, and notes about limitations or caveats. It provides context for interpretation, but it does not by itself establish correctness, authority, safety, verification, or ranking priority.

The canonical MSP-1 object form requires level. Verification details are expressed through separate optional fields so that declared confidence and verification status remain distinct.

• level — general declared confidence context for the resource.

Allowed level values include:

• low — low declared confidence context.
• medium — medium declared confidence context.
• high — high declared confidence context.

• verified — indicates whether the resource has undergone a declared verification process.
• verificationLevel — declared verification status, using self-declared or verified.
• verifiedBy — identifier for the person, organization, or system that performed or declared verification.
• verificationDate — date when verification was performed or declared.
• confidence — declared confidence in the accuracy, reliability, or interpretive stability of the resource.
• signals — optional list of trust-related supporting signals or justifications.
• auditTrail — optional chronological audit entries describing trust or verification events.
• notes — optional notes describing trust context, limits, caveats, or interpretation.

• Trust metadata should declare context and supporting signals rather than instruct agents how to rank or believe content.
• Trust declarations should align with provenance, reviewer, authority, and revision metadata when those declarations are present.
• Trust declarations should apply only to their declared or reasonably implied scope.
• Trust should not be treated as proof of truth, correctness, authority, safety, verification, or ranking priority by itself.
• Missing trust metadata should be treated as unspecified trust context, not as evidence of unreliability.
• Authority meaning should be declared through authority, not through the trust level field.

{
  "trust": {
    "level": "medium"
  }
}

Verified trust declaration:

{
  "trust": {
    "level": "high",
    "verified": true,
    "verificationLevel": "verified",
    "verifiedBy": "editorial-team",
    "verificationDate": "2026-06-24",
    "signals": [
      "human-reviewed",
      "metadata-checked"
    ]
  }
}

Authority-supported high trust context:

{
  "trust": {
    "level": "high",
    "verified": true,
    "verificationLevel": "verified",
    "verifiedBy": "msp-1-org",
    "notes": "Declared high confidence for MSP-1 protocol documentation scope. Authority context should be evaluated through the authority declaration, not through the trust level alone."
  }
}

• provenance describes origin and lineage; trust declares trust-context metadata.
• reviewer identifies review responsibility and may support trust context when review metadata is present.
• authority identifies scope-bound authority and should not be collapsed into trust level vocabulary.
• revision may document lifecycle events that affect trust or verification context.
• site, page, and section may define the scope to which trust metadata applies.

The deprecated compliance term should not be emitted in new MSP-1 v1.0.1 declarations. Legacy trust declarations that function like compliance, validation, or authority badges should be treated as compatibility-era language and interpreted through graceful degradation rather than reactivating the sunset field.

Legacy flat-string trust values such as verified may receive advisory handling when unambiguous. Legacy authoritative trust values should be routed to the separate authority term or treated as advisory compatibility drift.

When present, trust should be an object with level. The level value should be low, medium, or high.

Validators should flag unsupported level values, contradictory verified and verificationLevel combinations, unsupported fields such as validated, legacy badge-like values such as authoritative, or trust declarations that conflict with provenance, reviewer, authority, revision metadata, or observable content as non-ideal clarity conditions.