docs(governance): state who may author normative text

CONTRIBUTING.md

@@ -18,9 +18,11 @@ This adds `Signed-off-by: Your Name <you@example.com>`. PRs without DCO sign-off
 
 Changes to `spec/trace-v0.2.md` that affect what implementations must do.
 
+Read [who may author normative text](GOVERNANCE.md#who-may-author-normative-text) first. Normative changes 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 in the list below, including informative crosswalks and mappings to external schemas, needs no sponsor.
+
 1. Open a GitHub issue using the **Spec change proposal** template. Describe the problem, the proposed change, and the spec section affected.
 2. Allow 5 business days for comment. Changes touching wire format, cryptographic algorithms, or Trust Record required fields require 14 days.
-3. Submit a PR. Mark changed normative text with an HTML comment: `<!-- CHANGED: #NNN — description -->`.
+3. Submit a PR. Mark changed normative text with an HTML comment: `<!-- CHANGED: #NNN - description -->`.
 4. Update `CHANGELOG.md`.
 5. Breaking changes (backward-incompatible field removals, algorithm deprecations) require Project Lead approval and an explicit backward-compatibility statement.
 

GOVERNANCE.md

@@ -36,6 +36,20 @@ Final decision authority on specification changes, conformance requirements, AAI
 
 **Voting**: If consensus cannot be reached, Maintainers vote. Simple majority for non-breaking changes; two-thirds for breaking changes. Project Lead has 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 TRACE, including implementations whose authors are not in the discussion.
+
+**Normative spec changes require an organizational sponsor.** The sponsor is an organization that implements TRACE, 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** editorial changes, 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. 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 commercial interest in a proposal before participating in its review. Disclosed conflicts do not disqualify a Maintainer from voting but must be on record in the PR or issue.