New MSP-1 v1.0.1 metadata should not include compliance. Validators should issue a soft advisory warning when compliance is encountered and should not require or recommend it in new output.

The term is sunset because it conflates implementation status, validation, authority, trust, and conformance language. Active meanings should be handled by more specific MSP-1 terms or by external validator/tooling output rather than by a core metadata field.

Legacy schema form

Some legacy declarations used a level-based object form.

{
  "compliance": {
    "standard": "MSP-1 core",
    "version": "1.0.0",
    "level": "core",
    "scope": "documentation only",
    "status": "deprecated"
  }
}

Legacy boolean form

Earlier examples used boolean fields such as core, verified, and authoritative. These fields are deprecated compatibility syntax only.

{
  "compliance": {
    "core": true,
    "verified": true,
    "authoritative": false,
    "versionRange": "MSP-1.0.x"
  }
}

Do not replace compliance with a single equivalent field. Instead, route useful meaning to the appropriate active MSP-1 terms or validator output.

• protocol — use for protocol name and MSP-1 version identity.
• version — use for site, page, section, resource, implementation, or protocol-related version context.
• discovery — use for canonical MSP-1 well-known discovery.
• provenance — use for origin, lineage, creation method, source relationship, or contributor context.
• authority — use for declared scope-bound authority.
• trust — use for trust-context metadata, confidence indicators, verification information, or supporting signals.
• reviewer — use for declared review responsibility.
• revision — use for documented lifecycle change events.
• validator output — use for validation results, warnings, errors, or implementation reports.

{
  "protocol": {
    "name": "MSP-1",
    "version": "1.0.1"
  },
  "discovery": {
    "wellKnown": "/.well-known/msp.json",
    "canonical": true
  }
}

• New MSP-1 v1.0.1 declarations should not include compliance.
• Legacy compliance declarations may be ignored or surfaced as advisory compatibility information.
• The presence of compliance in legacy metadata should not by itself invalidate an otherwise interpretable MSP-1 declaration.
• Compliance should not be treated as proof of correctness, trust, authority, validation, implementation quality, or conformance.
• Where a legacy compliance declaration expresses useful meaning, migrate that meaning to active terms or external validator output rather than preserving compliance.

• protocol identifies the semantic protocol being used and the MSP-1 version being implemented.
• version identifies a declared version for a site, page, section, resource, implementation, or protocol-related context.
• discovery declares the canonical well-known endpoint used to locate a site's MSP-1 declaration.
• provenance documents origin, lineage, creation method, source relationship, and contributor context.
• authority identifies scope-bound authority and should not be conflated with compliance.
• trust declares trust-context metadata and should not be conflated with compliance.
• reviewer identifies review responsibility.
• revision describes documented change events in the lifecycle of a resource.

Validators should issue a soft advisory warning when compliance is encountered. Validators should not require compliance, should not recommend compliance, and should not generate compliance in new output.

Existing compliance declarations may be parsed only for compatibility and migration assistance. Legacy fields such as core, verified, authoritative, versionRange, validatedAt, and validatedBy should be treated as deprecated compatibility fields, not active v1.0.1 syntax.