revisionVersion helps place a revision within a lifecycle or release context. It should not be confused with protocol.version, and it does not by itself establish correctness, trust, verification, freshness, or ranking priority.

MSP-1 v1.0.2 allows revisionVersion as either a string or a structured object. The string form is preferred when revisionVersion appears as a simple field inside a revision object. The object form is available when structured semantic-version components or compatibility metadata are useful.

String form

The string form should be used when one version label is sufficient.

{
  "revisionVersion": "1.0.2"
}

Object form

The object form should be used when semantic-version components, compatibility ranges, effective dates, build metadata, or explanatory notes are needed.

{
  "revisionVersion": {
    "major": 1,
    "minor": 0,
    "patch": 1,
    "string": "1.0.2",
    "label": "stable"
  }
}

• major — required. Major version number representing incompatible, substantial, or release-significant changes.
• minor — required. Minor version number representing backward-compatible additions or meaningful non-breaking changes.
• patch — required. Patch version number representing backward-compatible fixes, refinements, or clarifications.
• string — optional. Full version represented as a single version string.
• label — optional. Pre-release, channel, or lifecycle label such as alpha, beta, rc1, draft, or stable.
• build — optional. Build metadata such as a commit hash, timestamp, or internal build number.
• isCompatibleWith — optional. Versions or version ranges that this revisionVersion declares compatibility with.
• effectiveDate — optional. Date when this version becomes effective if different from the revisionDate.
• notes — optional. Notes describing the reasoning, implications, or compatibility context of the version update.

Older examples may use channel where the structured schema now uses label. New MSP-1 v1.0.2 output should prefer label. Validators may treat channel as an advisory compatibility alias during transition.

• revisionVersion should remain stable after it is associated with a revision unless the original record was incorrect.
• revisionVersion should be associated with a specific revision or revision context.
• Semantic versioning is preferred where applicable, but implementation-defined labels may be used when semantic versioning is not appropriate.
• revisionVersion should not be confused with protocol.version.
• revisionVersion should inform lifecycle and compatibility context but should not be treated as proof of correctness, trust, freshness, verification, or ranking value by itself.

{
  "revisionVersion": "1.0.2"
}

Structured revision version:

{
  "revisionVersion": {
    "major": 1,
    "minor": 0,
    "patch": 1,
    "string": "1.0.2",
    "label": "stable"
  }
}

Revision object with revisionVersion:

{
  "revision": {
    "id": "rev-2026-06-24",
    "revisionDate": "2026-06-24",
    "revisionNotes": "Clarified lifecycle term handling for v1.0.2 harmonization.",
    "revisionVersion": "1.0.2"
  }
}

• revision identifies the documented change event associated with the version label.
• revisionDate records when the revision event occurred.
• revisionNotes explain what changed and why.
• version identifies a declared version for a broader site, page, section, resource, implementation, or protocol-related context.
• provenance may provide origin or lineage context for the versioned change.
• trust is a separate interpretive signal and should not be inferred from revisionVersion alone.

The deprecated compliance term should not be emitted in new MSP-1 v1.0.2 declarations. revisionVersion metadata should not reactivate compliance language or imply that version labels alone establish trust, correctness, freshness, or reliability.

When revisionVersion appears as a field inside a revision object, a non-empty string should be accepted. When revisionVersion is represented as a structured semantic-version object, major, minor, and patch should be required.

Validators may warn when non-semantic labels are used in contexts that require semantic versioning, but should not reject stable non-semantic labels unless a specific implementation profile requires strict semantic versioning. Validators may warn when channel is used instead of label unless compatibility aliases are explicitly supported.