Authority helps distinguish authorship, ownership, operational control, editorial responsibility, stewardship, and scope-bound governance. It informs interpretation but does not by itself establish correctness, trust, verification, compliance, or ranking priority.

The canonical MSP-1 object form requires name and type. A stable id and clear scope are strongly recommended.

• name — human-readable label for the authority entity.
• type — declares whether the authority entity is a Person, Organization, or System.

Recommended fields include:

• id — stable identifier for the authority entity, such as a site-local ID, profile URL, homepage, registry URI, or persistent system identifier.
• scope — description of what the authority covers, such as an entire site, page family, policy area, product line, or MSP-1 metadata only.
• role — specific authority role, such as site owner, publisher of record, policy owner, data controller, editorial board, maintainer, or metadata steward.
• jurisdiction — optional legal, organizational, geographic, or operational boundary for the authority declaration.

• verification — optional verification metadata for the authority declaration when supported by the active schema.

• Authority should be interpreted only within the declared or reasonably implied scope.
• Authority should not imply global authority outside the declared resource, topic, jurisdiction, or operational boundary.
• Authority may overlap with author, reviewer, or provenance declarations, but it should remain conceptually distinct from each.
• The scope field should be used when the authority applies only to a specific resource, topic, jurisdiction, page family, or operational area.
• Authority identifiers and roles should remain stable unless governance, ownership, or operational responsibility changes.
• Authority metadata should not be treated as a trust guarantee, ranking signal, proof of correctness, or verification claim by itself.

{
  "authority": {
    "name": "MSP-1",
    "type": "Organization",
    "id": "https://msp-1.org/",
    "scope": "MSP-1 protocol documentation",
    "role": "publisher of record"
  }
}

Person authority:

{
  "authority": {
    "name": "Mark Johnson",
    "type": "Person",
    "id": "mark-johnson",
    "scope": "MSP-1 protocol stewardship",
    "role": "protocol maintainer"
  }
}

System authority:

{
  "authority": {
    "name": "MSP-1 Validator",
    "type": "System",
    "id": "msp-1-validator",
    "scope": "MSP-1 metadata validation output",
    "role": "validation system"
  }
}

• author identifies creation or origination responsibility; authority identifies declared decision-making, stewardship, or operational responsibility within scope.
• reviewer identifies review responsibility and should not be conflated with authority.
• provenance describes broader origin, lineage, creation method, and contributor context.
• trust concerns separate confidence or supporting signals and should not be conflated with authority.
• role clarifies the function or responsibility of the authority-bearing entity.
• site, page, and section may provide the resource boundaries to which authority applies.

The deprecated compliance term should not be emitted in new MSP-1 v1.0.1 declarations. Legacy authority labels that function like compliance, validation, or trust badges should be treated as compatibility-era language and interpreted through graceful degradation rather than reactivating the sunset field.

When present, authority should be an object with name and type. The type value should be Person, Organization, or System.

Validators should strongly encourage scope to prevent overbroad interpretation. Validators should flag flat-string authority badges, unsupported type values, missing scope in sensitive contexts, or authority declarations that imply global trust or verification as non-ideal clarity conditions.