diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index ae959c1..351d82b 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -58,6 +58,8 @@ bandit -r src/agent_manifest
 
 ## Spec changes
 
+Read [who may author normative text](GOVERNANCE.md#who-may-author-normative-text) first. Normative changes, meaning anything with an uppercase RFC 2119 keyword, need an organizational sponsor accountable for the requirement. Anyone may propose one, and a Maintainer carries the PR for an accepted proposal that has no sponsor. Everything else, including informative crosswalks and mappings to external schemas such as OCSF, needs no sponsor.
+
 Spec changes follow this process:
 
 1. Open a GitHub issue describing the problem and proposed change. Reference the spec section.
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
index d1d974b..fd24542 100644
--- a/GOVERNANCE.md
+++ b/GOVERNANCE.md
@@ -34,6 +34,20 @@ Final decision authority on specification changes, standards contribution scope,
 
 **Voting**: If consensus cannot be reached, Maintainers vote. Simple majority decides routine changes; two-thirds majority required for breaking spec changes. The Project Lead has a tie-breaking vote.
 
+## Who may author normative text
+
+Normative text is any statement using an RFC 2119 keyword in uppercase: what a conformant implementation MUST, SHOULD or MAY do. A normative change binds every implementation of Agent Manifest, including implementations whose authors are not in the discussion.
+
+**Normative spec changes require an organizational sponsor.** The sponsor is an organization that implements Agent Manifest, or produces the attestation platform the change concerns, and is willing to be named as accountable for the requirement in the PR. In practice that has meant silicon and cloud attestation vendors, platform and framework implementers, and standards bodies carrying the work forward. Reviewers confirm the sponsorship, not the individual's competence.
+
+The reason is maintenance cost, not merit. A MUST is a promise the project keeps for every future version. Evaluating whether it can be implemented, at what cost, across which platforms, needs an organization that will actually implement it and answer for it later. Individual authorship gives the project no way to make that assessment and no one to return to when the requirement proves wrong.
+
+**Anyone may propose a normative change.** Open a Spec change proposal issue. Proposals are evaluated on the technical argument alone. If one is accepted without a sponsor, a Maintainer carries the normative PR and the proposer is credited in the CHANGELOG entry. This is a question of who signs the requirement, not whose idea it was.
+
+**No sponsor is required for** bug fixes, SDK work, examples, conformance tests, tooling, schema changes tracking an already-merged spec change, and informative additions such as crosswalks and mappings to external schemas. Informative text carries no RFC 2119 keywords and binds no implementation, so it is the right home for a mapping that is still settling: an OCSF or OpenTelemetry field correspondence is useful as guidance long before anyone should be required to follow it. Most contributions are in this set.
+
+A normative PR opened without a sponsor is not rejected on that basis. Reviewers will say so on the PR and either identify a sponsor or convert it to an informative change.
+
 ## Conflict of interest
 
 Maintainers must disclose any commercial interest in a proposal before participating in its review. Disclosed conflicts do not disqualify a Maintainer from voting but must be on the record.