• Identify the higher-level resource that contains or organizes the current resource.
• Distinguish direct structural hierarchy from logical or organizational grouping.
• Represent breadcrumb-like context without requiring agents to infer hierarchy from URLs alone.
• Support clear containment relationships among sites, pages, sections, collections, and resources.

Parent metadata provides structural context. It should not be treated as a canonical URL declaration or provenance claim.

• Provide stable reference through id.
• Represent one parent relationship for the declared resource.
• Avoid loops or contradictory hierarchy paths.
• Use relation values consistently when relation context is declared.
• Remain distinct from section and canonical.

MSP-1 uses a single direct-parent model to avoid graph-like ambiguity. Logical or organizational grouping may be declared through the relation field when appropriate.

• id — required; stable identifier for the parent resource.

Recommended fields include:

• url — URL of the parent resource when it is web-addressable.
• type — classification of the parent entity: site, section, page, collection, or other.
• label — human-readable label for the parent resource.
• relation — relationship class: direct, logical, or organizational.
• path — ordered list of ancestor identifiers from top-level down to this parent.
• depth — depth of the current resource in the hierarchy relative to the top-level root.
• lastUpdated — date when this parent relationship was last reviewed or updated.

Relation values such as sectionOf or childPageOf should not be emitted unless added by an active schema or profile.

• AI agents should treat parent as the declared structural or grouping context for the resource.
• Agents should use parent.id as the required parent reference.
• Agents should distinguish relation: "direct" from relation: "logical" or relation: "organizational".
• Contradictory parent declarations, hierarchy loops, or undefined relation values should be treated as non-ideal structural conditions.
• Legacy flat-string parent values may receive an advisory warning and be interpreted as a parent URL or identifier when graceful degradation is appropriate.

Parent metadata supports structural interpretation without converting hierarchy into a broader claim of authority, provenance, or canonical representation.

• site — may serve as a top-level parent context for pages or resources.
• page — commonly acts as the parent of sections or page-level subresources.
• section — may have a page or higher-level section as parent.
• id — provides the stable identifier used by parent references.
• url — may identify the web-addressable location of the parent resource.
• canonical — identifies preferred URL representation; it is not a parent relationship.
• provenance — documents origin and lineage; it is not a substitute for structural parent context.

Do not confuse parent with section or canonical. parent defines hierarchical containment or grouping; section identifies a content subdivision or category; canonical identifies the preferred authoritative URL representation.

{
  "parent": {
    "id": "lighting-guide"
  }
}

Parent declaration with type and relation:

{
  "parent": {
    "id": "guides",
    "type": "collection",
    "relation": "organizational"
  }
}

Parent declaration with URL and path:

{
  "parent": {
    "id": "documentation",
    "url": "https://msp-1.org/spec/",
    "type": "page",
    "relation": "direct",
    "path": [
      "site-root",
      "documentation"
    ],
    "depth": 2
  }
}

• It expresses parent as an object.
• It provides required id for the parent reference.
• It uses relation values allowed by the active schema.
• It avoids contradictory parent declarations, hierarchy loops, or graph-like ambiguity.
• It does not confuse parent relationships with section identity, canonical representation, or provenance lineage.