HATS Standards Governance Model

DRAFT -- Subject to revision by legal counsel

1. Purpose and Scope

1.1 Purpose

This document establishes the governance model for the HATS (H33 Attestation and Trust Standard) v1.0 technical conformance standard, including the processes by which the standard is amended, versioned, frozen, deprecated, and transitioned to independent governance. This governance model applies to all protocol surfaces defined in the HATS specification, including but not limited to the Frozen Protocol (HATS-FP), verifier output schemas, error code registries, requirement identifiers, proof profiles, domain separators, and canonical test vectors.

1.2 Scope

This governance model governs:

(a) The amendment and revision of the HATS standard and its constituent documents; (b) The versioning scheme and compatibility obligations arising from version changes; (c) The freeze and unfreeze lifecycle of protocol surfaces; (d) The deprecation and retirement of standard components; (e) The dispute resolution process for technical disagreements; (f) The transition from H33.ai stewardship to independent governance; (g) The emergency amendment process for critical security vulnerabilities.

1.3 Normative References

- HATS Frozen Protocol v1.0 (FROZEN-PROTOCOL.md) - HATS Verifier Guarantees v1.0 (GUARANTEES.md) - HATS Conformance Testing License (HATS-GOV-002) - HATS Marketing Claims Policy (HATS-GOV-004)

1.4 Definitions

"Issuing Authority" means H33.ai, Inc. or, following transition under Section 10, the successor independent governance body.

"Technical Review Committee" (TRC) means the body constituted under Section 8 with authority to evaluate proposed amendments, resolve disputes, and recommend actions to the Issuing Authority.

"Frozen Element" means any protocol surface, schema, error code, requirement identifier, domain separator, ordering rule, or other specification component designated as FROZEN in the HATS Frozen Protocol document.

"Major Version" means a version increment to the first numeral of the version identifier (e.g., v1 to v2) that may include breaking changes to frozen elements.

"Minor Version" means a version increment to the second numeral (e.g., v1.0 to v1.1) that is strictly additive and non-breaking.

"Patch Version" means a version increment to the third numeral (e.g., v1.0.0 to v1.0.1) limited to errata corrections, clarifications, and editorial fixes that do not alter normative behavior.

"Overlap Window" means the period during which two major versions are simultaneously supported.

"Public Comment Period" means the minimum period during which a proposed amendment is publicly available for stakeholder review and comment.

2. Amendment Process

2.1 General Principles

All amendments to the HATS standard shall be:

(a) Technically justified with a written rationale explaining the necessity of the change; (b) Subject to public notice and comment before adoption; (c) Documented in the standard's change log with effective dates; (d) Classified by version impact (major, minor, or patch) before publication; (e) Accompanied by updated test vectors where the amendment affects verifier behavior.

2.2 Proposal Submission

Any party may submit an amendment proposal to the Issuing Authority at the designated submission address (standard@h33.ai or its successor). A conforming proposal shall include:

(a) A unique proposal identifier in the format HATS-PROP-[YYYY]-[NNN]; (b) The specific sections, requirement identifiers, or frozen elements affected; (c) The proposed text changes in redline format; (d) A technical justification of no fewer than 500 words; (e) An impact assessment identifying all downstream effects on implementations, test vectors, and conformance claims; (f) A proposed version classification (major, minor, or patch) with justification.

2.3 Public Notice and Comment

Upon receipt of a conforming proposal, the Issuing Authority shall:

(a) Publish the proposal to the HATS Standards Registry within thirty (30) calendar days of receipt; (b) Open a Public Comment Period of no fewer than sixty (60) calendar days for minor and patch amendments, and no fewer than ninety (90) calendar days for major amendments; (c) Accept written comments from any party during the Public Comment Period; (d) Publish a disposition of comments document addressing each substantive comment received.

2.4 Technical Review

The Technical Review Committee shall evaluate each proposal against the following criteria:

(a) Technical necessity -- does the amendment address a demonstrable deficiency, ambiguity, or security concern? (b) Backward compatibility -- can existing conformant implementations continue to operate without modification? (c) Implementation burden -- is the cost of adoption proportionate to the benefit? (d) Test vector impact -- can the change be validated through deterministic testing? (e) Consistency -- does the amendment conflict with other provisions of the standard?

2.5 Adoption

The Issuing Authority shall adopt, modify, or reject the proposal within thirty (30) calendar days of the close of the Public Comment Period, based on the TRC recommendation. Adopted amendments shall be published with:

(a) An effective date no earlier than sixty (60) calendar days from publication for minor/patch changes; (b) An effective date no earlier than one hundred eighty (180) calendar days from publication for major changes; (c) Updated canonical test vectors, where applicable; (d) A migration guide, where applicable.

3. Version Governance

3.1 Versioning Scheme

The HATS standard follows semantic versioning (MAJOR.MINOR.PATCH) with the following constraints:

(a) Major versions (e.g., v1 to v2): May modify, remove, or replace any frozen element. Require full public comment, TRC review, and a minimum twelve (12) month overlap window. Require a published migration guide.

(b) Minor versions (e.g., v1.0 to v1.1): May add new optional fields, new error codes, new requirement identifiers, new proof profiles, and new domain separators. Shall not remove, rename, or alter the semantics of any frozen element. Shall not alter existing test vector expected outputs.

(c) Patch versions (e.g., v1.0.0 to v1.0.1): Limited to errata corrections, typographical fixes, clarification of ambiguous language, and editorial improvements. Shall not alter normative behavior. Shall not add new requirement identifiers or error codes.

3.2 Major Version Overlap Window

When a new major version is adopted:

(a) The Issuing Authority shall support both the prior major version and the new major version for a minimum of twelve (12) months from the effective date of the new version ("Overlap Window"); (b) During the Overlap Window, conformance certifications under the prior major version shall remain valid; (c) The Issuing Authority shall publish and maintain a migration guide covering all breaking changes between major versions; (d) Test vectors for the prior major version shall remain available and maintained during the Overlap Window; (e) The Issuing Authority may extend the Overlap Window upon written notice. No Overlap Window may be shortened after publication.

3.3 Schema Version Independence

Consistent with FROZEN-SCHEMA-002, the verifier output schema version (`schema_version`) is versioned independently from the verifier implementation version (`verifier_version`). Changes to the schema version follow the same governance process as changes to the standard generally.

4. Compatibility Governance

4.1 Compatibility Commitments

Within a major version:

(a) All existing test vectors shall continue to produce identical outputs; (b) All existing error codes shall retain their assigned code strings, severity levels, and requirement mappings; (c) All existing requirement identifiers shall retain their assigned semantics; (d) All existing domain separators shall retain their assigned strings; (e) All existing proof profiles shall retain their identifiers and baseline semantics.

4.2 Compatibility Matrix

The Issuing Authority shall maintain a compatibility matrix in the Frozen Protocol document, updated as independent implementations achieve full test vector parity. This matrix shall record:

(a) Implementation name and maintainer; (b) Implementation language; (c) Test vector version against which conformance was validated; (d) Number of vectors passed out of total; (e) Date of last validation.

5. Freeze Policy Governance

5.1 Authority to Freeze

The Issuing Authority has sole authority to designate protocol surfaces as FROZEN. The TRC may recommend freeze actions but may not independently freeze or unfreeze protocol surfaces.

5.2 Freeze Procedure

To freeze a protocol surface, the Issuing Authority shall:

(a) Publish a freeze notice identifying the specific elements to be frozen, with a thirty (30) day notice period; (b) Ensure that all frozen elements are covered by canonical test vectors; (c) Record the freeze in the Frozen Protocol document with a date and frozen element identifier; (d) Verify that the frozen element is deterministically reproducible across independent implementations, where applicable.

5.3 Unfreeze Procedure

A frozen element may only be unfrozen through a major version increment. The unfreeze procedure requires:

(a) A conforming amendment proposal under Section 2; (b) An extended Public Comment Period of no fewer than one hundred twenty (120) calendar days; (c) A migration guide addressing all implementations relying on the frozen element; (d) TRC recommendation with a supermajority (two-thirds) affirmative vote; (e) A minimum twelve (12) month overlap window as specified in Section 3.2.

6. Deprecation Timelines

6.1 Deprecation Process

The Issuing Authority may deprecate standard components (requirement identifiers, proof profiles, cryptographic profiles, error codes, or domain separators) subject to the following:

(a) Deprecated components shall be marked with a DEPRECATED status in the standard documents; (b) Deprecation notices shall include a target removal version (which must be a future major version); (c) Deprecated components shall remain functional for a minimum of twenty-four (24) months from the deprecation notice date or until the target removal version becomes effective, whichever is later; (d) Requirement identifiers that are deprecated shall not be reassigned to different requirements, consistent with FROZEN-REQ-001.

6.2 Cryptographic Profile Deprecation

Deprecation of a cryptographic profile (e.g., transitioning from SHA3-256 to a successor hash function) shall follow the migration process defined in HATS-FP-004 and shall additionally require:

(a) Documentation of the specific cryptographic weakness or standards body recommendation motivating the deprecation; (b) A replacement profile that has achieved REQUIRED or RECOMMENDED status before the deprecated profile's removal; (c) A minimum thirty-six (36) month deprecation period for cryptographic profiles, reflecting the extended timeline required for cryptographic migration in production systems.

7. Dispute Resolution

7.1 Scope of Disputes

The dispute resolution process applies to:

(a) Disagreements regarding the interpretation of normative requirements; (b) Challenges to amendment adoption or rejection decisions; (c) Conformance certification disputes between an organization and its assessor; (d) Disputes between independent implementations regarding correct behavior; (e) Challenges to freeze or unfreeze decisions.

7.2 Technical Review Committee Resolution

Disputes shall first be submitted to the TRC in writing, with:

(a) A statement of the dispute, identifying the specific standard provisions at issue; (b) The submitting party's position with supporting technical evidence; (c) Any test vectors, implementation code, or specification text relevant to the dispute.

The TRC shall issue a written determination within sixty (60) calendar days of receiving a complete submission.

7.3 Public Record

All dispute submissions, TRC determinations, and supporting materials shall be published to the HATS Standards Registry, redacted only as necessary to protect trade secrets or personal information unrelated to the technical substance of the dispute.

7.4 Appeal

A party dissatisfied with a TRC determination may appeal to the Issuing Authority within thirty (30) calendar days. The Issuing Authority shall issue a final determination within sixty (60) calendar days. The Issuing Authority's determination is final and binding under this governance model.

8. Technical Review Committee

8.1 Composition

The TRC shall consist of no fewer than five (5) and no more than eleven (11) members, appointed by the Issuing Authority. Members shall include:

(a) At least two (2) members who are not employees, contractors, or equity holders of H33.ai, Inc.; (b) At least one (1) member with demonstrated expertise in post-quantum cryptography; (c) At least one (1) member with demonstrated expertise in governance, risk, and compliance standards (e.g., PCI DSS, SOC 2, FedRAMP).

8.2 Terms and Rotation

TRC members shall serve two (2) year terms, renewable once. No member may serve more than two (2) consecutive terms. Staggered initial appointments shall ensure continuity.

8.3 Quorum and Voting

A quorum consists of a simple majority of appointed members. Routine decisions require a simple majority vote of members present. Unfreeze recommendations and major version recommendations require a two-thirds supermajority of all appointed members.

9. Emergency Amendment Process

9.1 Applicability

The emergency amendment process applies exclusively to amendments necessitated by:

(a) A credible, demonstrated vulnerability in a cryptographic primitive relied upon by the standard (e.g., a practical collision attack on SHA3-256, a key-recovery attack on ML-DSA-65); (b) A defect in the standard that causes conformant implementations to produce incorrect verification results; (c) A security vulnerability in the canonical test vectors that could mislead implementers.

9.2 Emergency Procedure

When the Issuing Authority determines that an emergency amendment is necessary:

(a) The Issuing Authority shall publish an emergency notice describing the vulnerability with sufficient detail for implementers to assess impact, without disclosing exploitation details prematurely; (b) The Public Comment Period is reduced to fourteen (14) calendar days; (c) The TRC shall convene within five (5) business days to review the proposed emergency amendment; (d) The effective date may be immediate upon adoption, notwithstanding Section 2.5; (e) Emergency amendments shall be classified as the minimum version increment necessary. Where possible, emergency fixes should be structured as minor or patch updates; (f) A full retrospective analysis shall be published within ninety (90) calendar days of the emergency amendment, including root cause analysis and any changes to governance processes.

9.3 Limitations

The emergency process shall not be used for:

(a) Amendments motivated by commercial considerations; (b) Feature additions or capability expansions; (c) Disputes between implementers regarding interpretation; (d) Changes to governance process itself.

10. Transition to Independent Governance

10.1 Commitment

H33.ai, Inc. intends to transition stewardship of the HATS standard to an independent governance body ("H33 Trust Services" or a successor entity) when the standard has achieved sufficient adoption and independent implementation to sustain independent governance.

10.2 Transition Criteria

The Issuing Authority shall evaluate readiness for transition when:

(a) At least three (3) independent, full-conformance implementations exist in different programming languages; (b) At least ten (10) organizations have achieved HATS certification at Tier 2 or above; (c) The TRC includes a majority of non-H33.ai members; (d) The HATS test vector suite has been independently validated by at least two (2) implementations achieving 100% pass rate.

10.3 Transition Process

Upon determining that the transition criteria are met:

(a) The Issuing Authority shall publish a transition plan with a timeline of no fewer than twelve (12) months; (b) The independent governance body shall be constituted with a charter, bylaws, and conflict-of-interest policy; (c) All intellectual property necessary for standard maintenance (specification text, test vectors, governance documents) shall be licensed or assigned to the independent body under terms that preserve open access; (d) The Issuing Authority shall serve on the TRC of the independent body for a minimum transition period of twenty-four (24) months in a non-voting advisory capacity; (e) The trademark "HATS" as used in connection with the conformance standard shall be licensed to the independent body, subject to quality control provisions consistent with trademark law.

10.4 Pre-Transition Obligations

Until the transition is complete, H33.ai, Inc. shall:

(a) Maintain and operate the HATS Standards Registry; (b) Accept and process amendment proposals; (c) Maintain the canonical test vector suite; (d) Publish all governance actions on the public record; (e) Operate the TRC as specified in this document.

11. Stakeholder Input and Public Comment

11.1 Standing

Any natural person, organization, government agency, standards body, or academic institution may submit comments during any Public Comment Period. No registration, membership, or fee is required to participate in public comment.

11.2 Comment Submission

Comments shall be submitted in writing to the designated submission address. A conforming comment shall include:

(a) The commenter's name or organizational affiliation (anonymous comments are accepted but given lower weight in disposition); (b) The specific section, requirement, or proposal to which the comment pertains; (c) The substance of the comment, including any proposed alternative text; (d) Whether the commenter considers the comment editorial or substantive.

11.3 Disposition of Comments

The Issuing Authority shall publish a disposition of comments document that addresses each substantive comment received during a Public Comment Period. The disposition shall state, for each comment, whether it was accepted, accepted with modification, or rejected, with a brief explanation.

12. Effective Date and Amendments to This Document

12.1 Effective Date

This governance model is effective as of the date of publication by the Issuing Authority and applies to all governance actions taken with respect to HATS v1.0 and subsequent versions.

12.2 Amendments to This Document

Amendments to this governance model follow the same amendment process defined in Section 2, with the following additional requirement: any amendment that reduces stakeholder input rights (Section 11), shortens Public Comment Periods, or narrows the scope of dispute resolution (Section 7) requires an extended one hundred twenty (120) day Public Comment Period and TRC supermajority approval.

HATS Standards Governance Model v1.0 -- H33.ai, Inc.