MSP-1 Protocol

MSP-1 — Mark Semantic Protocol

AI-friendly semantics for trusted information.

Governance

Development & Governance Principles

MSP-1 evolves cautiously. These principles act as “gates” for changes and new declarations so the protocol stays lean, additive, and easy to adopt—while still gaining capability over time.

Status: Guidance Applies to: proposals, extensions, and future versions Core doctrine: expressiveness may grow; obligation must not

Why these principles exist

Protect simplicity

Protocols fail when they accumulate decisions, modes, and exception ladders. MSP-1 prioritizes clarity with minimal surface area so adoption remains frictionless.

Preserve neutrality

MSP-1 is not an enforcement system. It declares intent and interpretive posture while leaving decisions to the consuming system.

Enable discovery in the wild

The most durable “best practices” are earned through real-world use. MSP-1 leaves room for thought leaders and adopters to extend meaningfully without forking or breaking compatibility.

The principles

Use these as a checklist when proposing new declarations, guidance, tooling expectations, or governance language. If a proposal fails a gate, it should be deferred—not forced.

  1. Add value without adding complexity.
    • Does this reduce ambiguity, inference cost, or misinterpretation?
    • Does it avoid introducing additional modes, special cases, or heavy documentation?
  2. Strengthen clarity without restricting use.
    • Does it remain a declaration (advisory) rather than a rule (enforced)?
    • Could it be misread as limiting access, reuse, or visibility?
  3. Remain strictly additive.
    • Do existing implementations remain valid?
    • Can this be omitted with zero breakage?
    • Are there no “version cliffs” introduced?
  4. Reduce inference; don’t replace judgment.
    • Does this help systems interpret intent rather than make decisions?
    • Does it avoid normative or coercive “must” semantics?
  5. Prefer proven needs over theoretical elegance.
    • Has the problem emerged in real usage across multiple domains?
    • If it is only a thought experiment, can it wait?
  6. Respect institutional psychology.
    • Could legal, promotional, or compliance teams misinterpret this as binding policy?
    • If so, does it belong later—or elsewhere?
  7. Stay vendor- and model-neutral.
    • Is there any coupling to specific LLMs, crawlers, platforms, or toolchains?
    • Will this still make sense as today’s stack changes?
  8. Preserve the “professional courtesy” tone.
    • Does this feel like a clear introduction rather than a demand?
    • Does it communicate “this might help,” not “do this”?
  9. Be safely ignorable forever.
    • If a site never adopts this, is it still a valid MSP-1 citizen?
    • Does non-adoption carry no penalty or stigma?
  10. Increase ecosystem capability over time.
    • Does this make systems calmer, clearer, and more predictable?
    • Does it avoid making the ecosystem louder, stricter, or more complicated?

Meta-principle: MSP-1 may evolve in expressiveness, but never in obligation.

How to use these gates

For change proposals

Treat each principle as a “yes/no” filter. If a proposal fails one gate, refine it or defer it until real adoption evidence emerges.

For documentation

Keep guidance descriptive, not prescriptive. Document observed patterns once they repeat in the wild—avoid early “best practices” that harden assumptions.

For tooling & validators

Validate structure and correctness, not completeness. Optional checks may suggest improvements, but must not redefine “valid MSP-1.”

Related reading

Protocol overview

A plain-language introduction to what MSP-1 is and what it is not.

protocol overview/

Specification

The normative definitions of MSP-1 terms and structures.

spec/

Validator

Validate structure and catch common mistakes without forcing completeness.

validator/