• Identify the version associated with a protocol, site, page, section, resource, or implementation.
• Understand compatibility and lifecycle state when version context is relevant.
• Distinguish version identity from revision history.
• Apply version-specific interpretation context without expanding the core declaration unnecessarily.

Versioning supports clarity and stability across evolving MSP-1 resources.

• MAJOR — indicates incompatible or foundational changes.
• MINOR — indicates backward-compatible additions or expansions.
• PATCH — indicates backward-compatible fixes, clarifications, or housekeeping updates.

The required MSP-1 protocol version is declared as protocol.version inside the protocol object. Broader version fields are contextual and should not be treated as substitutes for protocol.version.

• 1.0.1
• 1.1.0
• 1.0.2

Compatibility ranges such as MSP-1.0.x should be expressed through fields such as supportedVersionRange or compatibleWith where those fields are defined, not as the primary version value.

• version — contextual; when present, should be a semantic version string.

The broad version term is not universally required. It is required only where the active schema or declaration context requires version identity.

The required MSP-1 protocol version remains protocol.version within the protocol object.

• AI agents should treat version as a semantic version string when it appears in active MSP-1 declarations.
• Agents should use protocol.version to determine the MSP-1 protocol version being implemented.
• Broader version fields may identify site, page, section, resource, or implementation version state.
• Agents should not treat a contextual version field as a substitute for a missing protocol.version.
• If expanded object-form version metadata is encountered, validators may treat it as schema drift or legacy structured metadata and issue an advisory warning when graceful degradation is appropriate.

Version consistency supports reliable interpretation across time without requiring expanded metadata for simple version identity.

• protocol — contains the required protocol.version subfield identifying the MSP-1 protocol version being implemented.
• site — may declare a site-level version where implementation or content version identity is needed.
• page — may declare a page-level version where page version identity is needed.
• section — may declare a section-level version where section version identity is needed.
• revision — describes a discrete change event in the lifecycle of an MSP-1 resource.
• revisionVersion — identifies the version associated with a specific revision event.

Do not confuse version with protocol.version or revisionVersion. protocol.version identifies the MSP-1 protocol version being implemented. The broader version term is contextual. revisionVersion identifies the version associated with a specific revision event.

The former compliance term is sunset/deprecated compatibility only and should not be emitted in new MSP-1 v1.0.1 declarations.

{
  "protocol": {
    "name": "MSP-1",
    "version": "1.0.1"
  }
}

Site-level version declaration:

{
  "site": {
    "id": "msp-1-org",
    "version": "1.0.1"
  }
}

Page-level version declaration:

{
  "page": {
    "id": "example-page",
    "version": "1.0.1"
  }
}

Version connected to a revision event:

{
  "revision": {
    "id": "rev-2026-06-29",
    "revisionDate": "2026-06-29",
    "revisionVersion": "1.0.1"
  }
}

• It uses a semantic version string when declaring version.
• It uses protocol.version for the required MSP-1 protocol version.
• It does not use compatibility ranges as the primary version value.
• It avoids contradictory version declarations across protocol, site, page, section, resource, and revision contexts.
• It treats expanded version metadata as outside the core version term unless defined by an active profile or schema.