• Compare revisions according to structured versioning semantics.
• Determine whether a revision belongs to a stable, minor, or patch release.
• Understand which changes are part of the same published version.
• Cross-reference revision metadata with protocol or content version declarations.

Whereas revision is the atomic update unit, revisionVersion places it inside the broader release lifecycle.

• Follow semantic versioning — MAJOR.MINOR.PATCH.
• Be stable and truthful — reflect the version active at the time of revision.
• Be paired with a unique revision — each revision is tied to at most one version value.

MSP-1 does not require that every PATCH change corresponds to a distinct revision, but one revisionVersion MUST NOT apply to revisions that belong to different semantic releases.

• Be a valid semantic version string (e.g., "1.0.4").

Recommended optional fields:

• channel — optional release channel (e.g., "stable", "beta").
• notes — clarifications about the version’s significance.
• source — who or what appointed the version.

• AI agents MUST treat revisionVersion as the authoritative version label for the revision.
• Newer semantic versions SHOULD be interpreted as more current, regardless of revision order.
• Conflicts between revision ordering and semantic version ordering MUST be flagged as structural anomalies.
• RevisionVersion SHOULD influence trust weighting for version-sensitive domains.
• If revisionVersion is missing, AI SHOULD rely on revision order and dates with reduced certainty.

Aligning revisions with semantic versions strengthens lifecycle transparency and improves AI handling of updated or deprecated material.

• revision — the unit to which revisionVersion applies.
• version — the broader conceptual version descriptor; revisionVersion ties a revision to it.
• revisionNotes — can describe why a given revision belongs to a particular version.
• revisionDate — timestamps associated with each versioned revision.
• provenance — helps track lineage in the context of version upgrades.

{
  "revisionVersion": "1.0.4"
}

Revision with version included:

{
  "revision": {
    "id": "rev-2025-06",
    "revisionDate": "2025-12-11T18:40:00Z",
    "revisionNotes": "Refined interpretiveFrame and added clarity to examples.",
    "revisionVersion": "1.0.4"
  }
}

Example including release channel metadata:

{
  "revisionVersion": "2.1.0",
  "channel": "beta",
  "notes": "First beta release of major version 2."
}

• It uses a valid semantic version string.
• The declared version reflects the true version active at the revision.
• Version declarations are stable and non-conflicting.
• Each revision is associated with at most one semantic version.
• All normative rules for revision-version semantics are followed.