Reviewer metadata helps distinguish creation responsibility from review responsibility. It can provide useful context about whether a resource, section, revision, or metadata declaration has been reviewed and what the review covered.

The canonical MSP-1 object form requires name and type. A stable id is strongly recommended but is not required to be a URI.

• name — name or identifier of the reviewer, whether a person, organization, or automated system.
• type — classification of the reviewer entity as Person, Organization, or System.

Recommended fields include:

• id — stable identifier for the reviewer, such as a site-local ID, profile URL, system identifier, or other persistent reference.
• role — specific reviewing role, such as editor, auditor, subject-expert, metadata reviewer, or AI validator.
• scope — description of what was reviewed.
• reviewDate — date when the review occurred.

• verification — optional verification metadata regarding the reviewer or review event when supported by the active schema.
• notes — optional contextual notes about the review or reviewer.
• @type — JSON-LD compatibility field. The preferred canonical MSP-1 field is type.

• The reviewer should identify the person, organization, or system responsible for a review activity.
• The reviewer should be distinct from the author unless the same entity performed both creation and review functions.
• The scope field should be used when the review applies only to a specific part of the resource, metadata, revision, or implementation.
• The id field should be stable across revisions when possible.
• Reviewer metadata should not be treated as a trust guarantee, ranking signal, or proof of authority by itself.
• If reviewer is missing, review context may be unspecified, but absence of reviewer should not alone invalidate an otherwise interpretable MSP-1 declaration.

{
  "reviewer": {
    "name": "Jane Smith",
    "type": "Person",
    "id": "jane-smith",
    "role": "editor"
  }
}

System reviewer:

{
  "reviewer": {
    "name": "MSP-1 Validator",
    "type": "System",
    "id": "msp-1-validator",
    "role": "metadata-validator",
    "scope": "metadata structure"
  }
}

Reviewer with review date:

{
  "reviewer": {
    "name": "Dr. Alan Roberts",
    "type": "Person",
    "id": "alan-roberts",
    "role": "subject-expert",
    "scope": "technical accuracy",
    "reviewDate": "2025-11-03"
  }
}

• author identifies creation or origination responsibility; reviewer identifies review responsibility.
• provenance describes broader origin, lineage, creation method, and contributor context.
• revision may provide the lifecycle event to which a review applies.
• role clarifies the function or responsibility of the reviewer.
• authority concerns declared decision-making or stewardship context and should not be inferred from review metadata alone.
• trust concerns separate confidence or supporting signals and should not be conflated with review responsibility.

The deprecated compliance term should not be emitted in new MSP-1 v1.0.1 declarations. Older reviewer labels or notes that refer to compliance should be treated as compatibility-era language and interpreted through graceful degradation rather than reactivating the sunset field.

When present, reviewer should be an object with name and type. The type value should be Person, Organization, or System.

Validators should encourage a stable id, scope, and reviewDate when available, but should not require the reviewer identifier to be URI-only unless a specific implementation profile requires URI identifiers. Validators may treat @type as a JSON-LD compatibility alias for type during transition, while continuing to prefer type for canonical MSP-1 output.