Revision metadata helps describe updates, freshness, stability, and temporal context. It informs change history but does not by itself establish correctness, trust, verification, or reliability.

The canonical MSP-1 object form requires id. The preferred explicit revision subterms are revisionDate, revisionNotes, and revisionVersion.

• id — stable identifier for the revision event.

Recommended fields include:

• revisionDate — date associated with the revision event.
• revisionNotes — human-readable explanation of what changed and, when useful, why it changed.
• revisionVersion — version identifier associated with this revision event.

• updatedBy — identifier of the person, organization, or system that performed the update.
• reviewer — optional reviewer metadata associated with this revision.
• provenance — optional provenance metadata associated with the change event.
• relatedChanges — optional list of related revisions, resources, or identifiers affected by this change.
• confidence — optional confidence level in the accuracy or completeness of the recorded revision details.

Older revision structures may use generic field names. These fields may receive compatibility handling, but new MSP-1 v1.0.1 output should prefer the explicit revision subterms.

• version — compatibility field. Prefer revisionVersion.
• date — compatibility field. Prefer revisionDate.
• summary — compatibility field. Prefer revisionNotes when describing the revision change.
• notes — compatibility field. Prefer revisionNotes.

• Each revision should represent one meaningful change event or documented update point.
• Revision identifiers should remain stable after declaration.
• Revision dates should support coherent chronological interpretation.
• Revision notes should provide enough context to understand the nature of the change when the change is meaningful.
• Revision metadata should not be treated as proof of correctness, trust, verification, or ranking value by itself.
• revisionVersion should not be confused with protocol.version.

{
  "revision": {
    "id": "rev-2026-06-24"
  }
}

Revision with explicit MSP-1 revision terms:

{
  "revision": {
    "id": "rev-2026-06-24",
    "revisionDate": "2026-06-24",
    "revisionNotes": "Clarified namespace definitions and updated examples.",
    "revisionVersion": "1.0.1"
  }
}

Revision with reviewer context:

{
  "revision": {
    "id": "rev-2026-06-24",
    "revisionDate": "2026-06-24",
    "revisionNotes": "Updated page metadata for v1.0.1 harmonization.",
    "revisionVersion": "1.0.1",
    "reviewer": {
      "id": "editorial-team"
    }
  }
}

• revisionDate records the date or date-time associated with a specific revision or lifecycle event.
• revisionNotes explains what changed in a revision and why the change was made when that context is useful.
• revisionVersion provides the version identifier associated with a specific revision event.
• version identifies a declared version for a site, page, section, resource, implementation, or protocol-related context.
• provenance describes origin and lineage and may provide context for the change event.
• reviewer may identify review responsibility associated with the revision.
• trust is a separate interpretive signal and should not be inferred from revision metadata alone.

The deprecated compliance term should not be emitted in new MSP-1 v1.0.1 declarations. Revision metadata should not reactivate compliance language or imply that change history by itself establishes conformance, trust, or reliability.

When present, revision should be an object with a stable id. Validators should flag missing id, contradictory revision dates, duplicate revision identifiers, unsupported field names, or incoherent revision timelines as non-ideal structural conditions.

During v1.0.1 transition, validators may warn when revision uses version, date, summary, or notes instead of revisionVersion, revisionDate, or revisionNotes.