• Track the same resource across revisions and representations.
• Disambiguate similar or related entities.
• Preserve long-term linkage across site structures and resource relationships.
• Identify resources even when the identifier is not the same as the resource URL.

• Stable — the identifier should remain stable across revisions unless the identity of the resource fundamentally changes.
• Unique — the identifier should be unique within its declared scope.
• Resolvable — the identifier should map to a meaningful resource, entity, or conceptual element when possible.
• Format-flexible — the identifier may be a URI, slug, UUID, opaque identifier, or system-specific identifier.

MSP-1 does not mandate a single ID format. Implementers should use consistent, maintainable patterns appropriate to the resource and scope.

MSP-1 identifiers may operate in several scopes:

• Site-level IDs — identify the site as a top-level semantic entity.
• Page-level IDs — identify individual pages or page-equivalent resources.
• Section-level IDs — identify logical or structural subdivisions of a page.
• Entity IDs — identify people, organizations, concepts, resources, or other declared entities.

Implementers should avoid overloading the same ID for multiple conceptual layers unless that reuse is intentional and clearly scoped.

• Be expressed as a single string.
• Be unique within its declared scope.
• Remain stable across revisions unless identity fundamentally changes.

Recommended forms include:

• URI — https://msp-1.org/spec/id/
• Slug — lighting-guide
• UUID — a globally unique identifier when that pattern is appropriate.
• Opaque ID — a non-semantic identifier such as a93f27bc.
• System ID — an identifier assigned by an internal or external system.

• AI agents should treat id values as persistent references; content changes do not imply ID changes.
• If a resource reuses an ID for a different concept, agents should treat this as an identity conflict or ambiguity.
• If no ID is present, agents should treat the resource as identifiable by URL or surrounding context, reducing long-term linkage reliability.
• Agents should not treat id, url, and canonical as interchangeable.
• If expanded object-form identifier metadata is encountered, validators may treat it as structured legacy drift or an extended identifier profile and issue an advisory warning when graceful degradation is appropriate.

• url — locates the resource on the web; id identifies the resource or entity.
• canonical — identifies the preferred authoritative URL representation when applicable.
• name — provides a human-readable label; id provides stable identity.
• parent — identifies the higher-level structural context that contains the current resource.
• site, page, and section — may each use IDs to establish stable identity at different structural levels.
• provenance and revision — may rely on IDs as stable anchors across origin, lineage, and change events.

Do not confuse id with url or canonical. id identifies the resource or entity; url locates it; canonical identifies the preferred authoritative URL representation when applicable.

{
  "id": "lighting-guide"
}

Entity identifier:

{
  "id": "mark-johnson"
}

URI identifier:

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

Opaque identifier:

{
  "id": "a93f27bc"
}

• Is expressed as a single string.
• Is stable across revisions unless the resource identity fundamentally changes.
• Is unique within the relevant scope.
• Uses a consistent identifier pattern appropriate to the implementation.
• Is not treated as interchangeable with url or canonical.