MSP-1 - AI-friendly semantics for trusted information.

Enterprise & Development Network

Development Guide

The MSP-1 Development Guide provides practical implementation guidance for developers, site owners, tool builders, and teams adding MSP-1 declarations to websites, applications, content systems, or agent-facing workflows.

Implementation First, Protocol Creep Never

MSP-1 is intentionally minimal. The development goal is not to add complexity to a site, but to give AI systems a clearer starting point for understanding identity, intent, provenance, trust posture, and interpretive scope.

Good implementation should be conservative, deterministic, and easy to validate.

Baseline Deployment Pattern

A practical MSP-1 implementation usually begins with two complementary layers: a site-level declaration published at the canonical discovery endpoint and page-level declarations embedded where more specific context is needed.

  • Publish site-level MSP-1 at /.well-known/msp.json.
  • Add page-level MSP-1 JSON-LD to key pages.
  • Use canonical URLs consistently.
  • Keep declarations truthful, scoped, and non-promotional.
  • Validate structure before publishing.

Site-Level Declaration

Site-level MSP-1 establishes the default identity and posture of a website. It is best suited for stable information such as site identity, canonical URL, general intent, default trust posture, provenance, and discovery.

Page-Level Declaration

Page-level MSP-1 describes the intent and interpretive framing of a specific page. It should include a stable page ID, URL, title, canonical URL, description, intent, provenance, revision metadata, and trust posture.

Discovery

MSP-1 discovery should be deterministic. The canonical endpoint is /.well-known/msp.json, and page-level declarations may include a discovery object that points to that endpoint.

Validation

Validation confirms structural correctness. It does not prove semantic truth, so human review remains essential for intent, authority, trust, provenance, and interpretive framing.

Recommended Workflow

  1. Identify the target page, site, or content system.
  2. Confirm canonical URLs and stable identifiers.
  3. Create the site-level or page-level MSP-1 declaration.
  4. Review high-impact fields such as intent, interpretiveFrame, authority, provenance, and trust.
  5. Validate the JSON structure against the current MSP-1 schemas.
  6. Deploy the declaration in the correct location.
  7. Re-check after publishing to confirm accessibility and crawler visibility.

Developer Principles

MSP-1 implementation should favor clarity over completeness. Declare what can be supported, omit what cannot, and avoid overstating trust or authority. The strongest implementations are often the most restrained.

  • Use stable IDs and canonical URLs.
  • Separate factual description from intent and interpretive framing.
  • Default to self-asserted trust unless a stronger claim is supported.
  • Record meaningful changes with revision metadata.
  • Do not treat MSP-1 as SEO markup.

Common Implementation Risks

Most implementation issues come from overstatement, scope leakage, missing required fields, or treating generated metadata as publish-ready without review. MSP-1 works best when it behaves like a declaration layer, not a promotional layer.

When unsure, declare less and preserve semantic accuracy.

Related Labs Areas

Development work often connects with the broader Labs ecosystem.

  • Extensions for proposed MSP-1 expansion patterns.
  • Evaluative Tooling for quality and interpretation checks.
  • Experiments for testing MSP-1 behavior across models and workflows.
  • SDK for future implementation helpers and developer resources.