HATS Independent Verifier Policy

DRAFT -- Subject to revision by legal counsel

1. Purpose and Scope

1.1. This document establishes the policies governing independent implementations of the HATS verification protocol, including: the rights and responsibilities of independent implementors; conformance requirements; trademark restrictions on the use of "HATS-conformant verifier" and related terms; liability allocations; bug reporting and security disclosure processes; and the treatment of modified forks and non-conformant derivatives.

1.2. HATS is designed for independent verification. As stated in HATS GUARANTEES: "Verification requires zero network access. Verification requires zero API keys. Verification requires zero trust in H33 or any platform. A verifier bundle is self-contained: nodes + public keys." This document provides the governance framework that enables that independence while maintaining ecosystem integrity.

1.3. This policy applies to all parties that implement, distribute, modify, or commercially offer HATS verification software, whether in Rust, Go, TypeScript, Python, Java, or any other language.

2. Definitions

2.1. "Independent Verifier" means a software implementation of the HATS verification protocol that is not produced by or under the control of H33.ai, Inc.

2.2. "Conformant Verifier" means an Independent Verifier that satisfies all conformance requirements specified in Section 4 of this policy.

2.3. "Reference Implementation" means the Rust-based HATS verifier published and maintained by H33, which serves as the authoritative implementation against which conformance is measured.

2.4. "Canonical Test Vectors" means the 26 test vector bundles published in `standards/hats/test-vectors/v1/`, as referenced in HATS GUARANTEES (Independent Implementation Challenge) and HATS-FP (Frozen Protocol, Compatibility Matrix).

2.5. "Implementor" means the natural person or legal entity responsible for developing, maintaining, and distributing an Independent Verifier.

2.6. "Non-Conformant Derivative" means software that implements some but not all HATS verification checks, produces outputs that do not conform to the frozen verifier output schema, or fails to pass 100% of the canonical test vectors.

3. Rights of Independent Implementors

3.1. Right to Implement. Any party may implement the HATS verification protocol based on the published HATS specification (Sections 2 through 7 of the standard), the Frozen Protocol document (HATS-FP), the GUARANTEES document, and the canonical test vectors. No license from H33 is required to implement the HATS verification protocol for the purpose of verifying HATS governance graph bundles.

3.2. Right to Distribute. Implementors may distribute Conformant Verifiers under any software license of their choosing, subject to the trademark restrictions in Section 5 and the conformance requirements in Section 4.

3.3. Right to Commercial Use. Implementors may commercially offer verification services using a Conformant Verifier, including integration into commercial products, SaaS platforms, and consulting engagements, without payment of royalties to H33 for the act of verification itself.

3.4. Right to Extend. Implementors may add functionality beyond what the HATS specification requires, provided that: (a) the core HATS verification output conforms to the frozen schema (HATS-FP, Section 1); (b) extensions are clearly distinguished from HATS-specified behavior; (c) any additional output fields use the vendor extension namespace (HATS_ERR_VENDOR_[NAME]_[CODE]) for error codes.

3.5. Access to Specification. H33 will maintain public access to the HATS specification, Frozen Protocol, GUARANTEES, and canonical test vectors at no charge. No access to H33 source code is required to implement a conformant verifier.

4. Conformance Requirements

4.1. Vector Parity. A Conformant Verifier must produce byte-identical outputs for all 26 canonical test vectors. Specifically, for each test vector input bundle, the verifier must produce:

(a) Identical graph root hashes. (b) Identical Merkle roots. (c) Identical replay frame hashes at the specified timestamps. (d) Identical verification pass/fail results. (e) Identical error code classifications (code, severity, requirement).

4.2. 100% Requirement. The conformance threshold is 100% of the 26 canonical test vectors. There is no partial conformance. A verifier that passes 25 of 26 vectors is non-conformant.

4.3. Schema Conformance. The verifier's JSON output must conform to the frozen verifier output schema (HATS-FP, Section 1), including all required top-level fields. Optional fields may be added. Required fields may not be omitted, renamed, or restructured.

4.4. Determinism. The verifier must be deterministic: given the same input bundle and the same configuration, it must produce byte-identical output on every invocation, across all supported platforms, regardless of execution environment, thread scheduling, or system locale.

4.5. Error Code Compliance. The verifier must implement all frozen error codes (HATS-FP, Section 2) with the specified severity levels. The verifier must not reassign error codes, change severity levels, or omit any frozen error code.

4.6. Frozen Protocol Compliance. The verifier must comply with all FROZEN-* rules in HATS-FP, including but not limited to: deterministic ordering rules (FROZEN-ORD-001 through FROZEN-ORD-004), hex encoding rules (FROZEN-HEX-001 through FROZEN-HEX-003), canonical whitespace rules (FROZEN-WS-001 and FROZEN-WS-002), and severity level semantics (FROZEN-SEV-001).

4.7. Proof Profile Support. A Conformant Verifier must support at a minimum the HATS-PROOF-HASH-ONLY-v1 proof profile (FROZEN-PROOF-001). Support for HATS-PROOF-SIGNED-v1 and other proof profiles is optional.

4.8. Self-Attestation and Publication. To claim conformance, an Implementor must: (a) run the full canonical test vector suite and produce a conformance report; (b) publish the conformance report, including the verifier version, language, platform, test vector version, and per-vector results; (c) submit the conformance report to H33 at standard@h33.ai for inclusion in the HATS-FP Compatibility Matrix.

4.9. Ongoing Conformance. Conformance is assessed against the current canonical test vector set. When H33 publishes additional test vectors in minor version updates (v1.x), Conformant Verifiers must pass the expanded vector set to maintain conformance status.

5. Trademark Restrictions

5.1. "HATS-Conformant Verifier." The phrase "HATS-conformant verifier" (and substantially similar phrases such as "HATS-compliant verifier," "HATS-compatible verifier," or "HATS-verified implementation") may be used to describe an Independent Verifier only if the verifier satisfies all conformance requirements in Section 4.

5.2. No Endorsement. Use of the phrase "HATS-conformant verifier" does not imply endorsement, certification, approval, or sponsorship by H33. Implementors must include the following disclaimer in prominent documentation: "This is an independent implementation. It is not produced, endorsed, or supported by H33.ai, Inc."

5.3. "HATS" Wordmark. Implementors may use the HATS wordmark in a descriptive capacity (nominative fair use) to identify their software as implementing the HATS verification protocol. Implementors must not use the HATS wordmark as part of their product name in a manner that implies official status (e.g., "Official HATS Verifier," "HATS Verifier Pro," "The HATS Verifier").

5.4. Non-Conformant Software. Software that does not meet the conformance requirements in Section 4 must not use the phrases "HATS-conformant," "HATS-compliant," "HATS-compatible," or "HATS-verified" in its name, description, marketing, or documentation. Non-conformant software may use descriptive phrases such as "implements a subset of the HATS protocol" or "inspired by HATS," provided such phrases are accompanied by a clear statement of non-conformance.

5.5. Enforcement. H33 reserves the right to enforce its trademark rights against any party that uses the HATS Marks in connection with non-conformant software or in a manner that misleads users about conformance status.

6. No Endorsement and No Liability

6.1. No Endorsement. Inclusion of an Independent Verifier in the HATS-FP Compatibility Matrix does not constitute an endorsement, warranty, or representation by H33 regarding the quality, security, reliability, or fitness for purpose of the verifier. The Compatibility Matrix is a factual record of reported conformance test results.

6.2. No Liability for Independent Implementations. H33 disclaims all liability for bugs, defects, vulnerabilities, security flaws, incorrect verification results, or any other failure in any Independent Verifier. H33's obligations extend solely to the Reference Implementation and to the accuracy of the published specification, Frozen Protocol, and canonical test vectors.

6.3. Implementor Responsibility. Each Implementor is solely responsible for: (a) the correctness of their implementation; (b) the security of their software supply chain; (c) the accuracy of their conformance claims; (d) providing support, maintenance, and security updates to users of their implementation; (e) any liability arising from the use of their implementation in production environments.

6.4. User Responsibility. Users of Independent Verifiers are responsible for evaluating the trustworthiness of the Implementor and the implementation before relying on verification results in production or compliance contexts.

6.5. No Indemnification. H33 does not indemnify Implementors or users of Independent Verifiers against any claims, losses, or damages arising from the use of Independent Verifiers.

7. Bug Reporting and Security Disclosure

7.1. Specification Bugs. If an Implementor discovers what they believe to be an ambiguity, inconsistency, or error in the HATS specification, Frozen Protocol, GUARANTEES document, or canonical test vectors, they should report it to standard@h33.ai. H33 will acknowledge receipt within five (5) business days and provide a substantive response within thirty (30) calendar days.

7.2. Security Vulnerabilities in the Specification. If an Implementor discovers a vulnerability in the HATS protocol itself (as opposed to a bug in a specific implementation), they should report it to standard@h33.ai with the subject line "HATS Security Disclosure -- [Brief Description]." H33 will:

(a) Acknowledge receipt within 48 hours.

(b) Assess severity within 14 calendar days.

(c) If confirmed, issue a security advisory and, if necessary, updated canonical test vectors, within 30 calendar days of confirmation.

(d) Credit the disclosing party in the advisory unless they request anonymity.

7.3. Coordinated Disclosure. H33 requests that security vulnerabilities in the HATS protocol be disclosed to H33 before public disclosure, with a maximum coordinated disclosure window of 90 calendar days. If H33 does not respond substantively within 90 days, the disclosing party may proceed with public disclosure.

7.4. Implementation-Specific Bugs. Bugs in Independent Verifiers should be reported to the Implementor, not to H33. H33 does not triage or track bugs in Independent Verifiers.

7.5. Reference Implementation Bugs. Bugs in the H33 Reference Implementation should be reported to standard@h33.ai. If a bug in the Reference Implementation causes a canonical test vector to produce incorrect results, H33 will issue a corrected test vector set and notify all Implementors listed in the Compatibility Matrix.

8. Safe Harbor for Conformant Implementations

8.1. H33 will not assert trademark claims against any Implementor that: (a) satisfies all conformance requirements in Section 4; (b) complies with the trademark restrictions in Section 5; (c) accurately represents the conformance status of their implementation; (d) does not misrepresent endorsement by or affiliation with H33.

8.2. H33 will not assert patent claims against any Implementor solely for implementing the HATS verification protocol as described in the published specification, provided the implementation is limited to verification functionality (consuming a governance graph bundle, applying verification checks, and producing a conformant verification output). This safe harbor does not extend to: (a) implementation of HATS governance graph generation, attestation, or enforcement; (b) integration with proprietary H33 services; (c) use of H33 proprietary code, libraries, or binaries.

8.3. This safe harbor is a unilateral commitment by H33 and does not create a license, covenant, or contractual obligation. H33 reserves the right to modify this safe harbor in future versions of this policy, with 12 months' notice to Implementors listed in the Compatibility Matrix.

9. Modified Forks and Non-Conformant Derivatives

9.1. Modified Forks. A modified fork is an Independent Verifier that was initially conformant but has been modified in a way that may affect conformance. Modified forks must re-run the full canonical test vector suite after each modification. If the fork no longer passes all 26 vectors, it must remove all "HATS-conformant" claims.

9.2. Non-Conformant Derivatives. Software that intentionally implements a subset of HATS, uses a different hash function, uses a different serialization format, or produces outputs that do not conform to the frozen schema is a Non-Conformant Derivative. Non-Conformant Derivatives:

(a) Must not claim HATS conformance.

(b) Must clearly and prominently state their non-conformant status in documentation and marketing.

(c) Must not use the HATS Marks in their product name or primary branding.

(d) May reference HATS in descriptive contexts (e.g., "based on concepts from the HATS standard") with appropriate disclaimers.

9.3. Interoperability. H33 encourages but does not require interoperability between Conformant Verifiers. The canonical test vectors define the minimum interoperability baseline: any two Conformant Verifiers must produce identical results for the same input bundle.

10. Compatibility Matrix Governance

10.1. The HATS-FP Compatibility Matrix (HATS-FP, Section 11) is the authoritative registry of implementations that have demonstrated full canonical test vector parity.

10.2. Listing Requirements. To be listed in the Compatibility Matrix, an Implementor must submit: (a) the conformance report described in Section 4.8; (b) a point of contact (email) for security disclosures and specification updates; (c) the verifier version and language; (d) the test vector version against which conformance was assessed.

10.3. Delisting. An implementation may be delisted from the Compatibility Matrix if: (a) a new canonical test vector set is published and the Implementor does not submit an updated conformance report within 90 calendar days; (b) H33 discovers that the implementation does not, in fact, produce conformant results for the claimed test vectors; (c) the Implementor requests removal.

10.4. No Ranking. The Compatibility Matrix is an unordered list. H33 does not rank, rate, or recommend Independent Verifiers.

11. Specification Updates and Implementor Notification

11.1. When H33 publishes a minor version update (v1.x) to the HATS specification, Frozen Protocol, or canonical test vectors, H33 will notify all Implementors listed in the Compatibility Matrix by email at least 30 calendar days before the update becomes the conformance baseline.

11.2. When H33 publishes a major version update (v2), H33 will provide a minimum 12-month overlap window during which both versions are supported, as specified in HATS-FP (Purpose section). H33 will publish a migration guide and updated canonical test vectors for the new version.

11.3. Implementors are responsible for monitoring the HATS public documentation for updates. The email notification in Section 11.1 is a courtesy and does not constitute a contractual obligation.

12. Governing Law

12.1. This policy is governed by the laws of the State of Delaware, United States, without regard to conflict of laws principles. Any dispute arising under this policy shall be resolved through binding arbitration administered by JAMS in Wilmington, Delaware.

13. Amendments

13.1. H33 reserves the right to amend this policy. Material amendments will be published with at least 90 days' notice. The safe harbor in Section 8 may not be narrowed with less than 12 months' notice.

HATS Independent Verifier Policy v1.0 -- H33.ai, Inc.