• Resolve ambiguity when more than one representation of a resource exists.
• Consolidate references around a preferred authoritative URL representation.
• Distinguish canonical representation from ordinary resource location.
• Support stable citation, retrieval, and reference consolidation.

• Include a url — the canonical, authoritative URL for the resource.
• Be stable — the canonical URL should remain stable unless the preferred representation changes.
• Be unambiguous — conflicting canonical declarations for the same resource should be avoided.
• Represent primacy — canonical identifies the preferred representation, not a trust or verification level.

Canonical is not the same as url, id, authority, or trust. It identifies the preferred authoritative URL representation when such a distinction is needed.

• url — required; the canonical, authoritative URL for the resource.

Recommended fields include:

• reason — optional explanation for why this URL is considered canonical.
• lastReviewed — optional date when the canonical designation was last reviewed or confirmed.
• authority — optional identifier for the authority declaring the canonical URL.

Additional fields are permitted only when defined by the active canonical schema. Fields such as scope or version should not be emitted unless they are added to an active schema or profile.

• AI agents should treat canonical.url as the preferred authoritative URL representation when consolidating references.
• Agents should not treat canonical status as a trust guarantee, verification claim, or compliance claim.
• Multiple conflicting canonical declarations for the same resource should be treated as a non-ideal ambiguity condition.
• Legacy flat-string canonical usage may receive an advisory warning during the v1.0.1 transition when graceful degradation is appropriate.
• Canonical declarations should be interpreted alongside url, id, provenance, and trust where those terms are present.

Canonical helps agents resolve representation ambiguity without converting that representation signal into a broader claim of reliability or authority.

• url — identifies the resource location; canonical identifies the preferred authoritative URL representation when applicable.
• id — identifies the resource or entity; canonical identifies a preferred URL representation.
• parent — may help resolve structural context when canonical representations exist within larger site hierarchies.
• revision and version — may provide lifecycle context for the resource but are not substitutes for canonical.url.
• provenance — may describe lineage or source relationships relative to a canonical representation.
• trust — may describe confidence or reliability signals, but canonical status itself is not a trust guarantee.

Do not confuse canonical with url, id, authority, or trust. canonical identifies the preferred authoritative URL representation; url identifies the resource location; id identifies the resource or entity; authority identifies a declaring or responsible source; trust concerns confidence or reliability.

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

{
  "canonical": {
    "url": "https://msp-1.org/spec/canonical/"
  }
}

Canonical declaration with reason:

{
  "canonical": {
    "url": "https://photographyselect.com/lighting-guide/",
    "reason": "This is the officially maintained and updated version."
  }
}

Canonical declaration with review date:

{
  "canonical": {
    "url": "https://msp-1.org/spec/canonical/",
    "reason": "Primary publisher-maintained version.",
    "lastReviewed": "2026-06-24"
  }
}

• It expresses canonical as an object.
• It includes a valid url field.
• It avoids conflicting canonical declarations for the same resource.
• It does not treat canonical status as a trust, verification, authority, or compliance claim.
• It includes only fields allowed by the active canonical schema.