Herald Charter — Template v0.2 · AI Initiative review

Herald Charter — Template v0.2

This is a fillable template. A conformant Herald operator copies this file, replaces every <PLACEHOLDER> with operator-specific content, removes guidance comments (lines beginning ), and publishes the result at the well-known URL declared in the operator's HERALD discovery records ([EXT §11.2]). The result is a public document.

Conformance requirement. Per [EXT §3.5], a Herald operator MUST publish a current Charter. Verifiers MUST reject Herald-signed attestations from Heralds without a Charter, with a stale Charter (>12 months since last signature), or whose declared jurisdiction conflicts with the verifier's policy.

Renewal cadence. Charters MUST be re-signed at least annually. The signature date is the freshness anchor; a Charter signed >12 months ago is stale even if its content has not changed.

1. Identity

Herald sigil: <sigil:HERALD-LONG-FORM>
Operator legal entity: <Legal name, e.g. "Acme Heralds Inc.">
Operator country of incorporation: <ISO 3166-1 alpha-2, e.g. "CA">
Operator declared jurisdiction(s) for service of process: <list, e.g. "Ontario, Canada">
Charter version: <integer, increments on each substantive change>
Charter signature date: <YYYY-MM-DD>
Charter validity: valid for 12 months from signature date, or until superseded by a higher-version Charter, whichever comes first.

2. Issuance policy

This section declares what claims the Herald will sign, and under what evidence. Per [EXT §3.5], this is the first mandatory Charter section.

2.1 Attestation classes issued

lineage_endorsement — endorsements of parent-child sigil relationships per [EXT §3.2].
<other classes the Herald issues>

2.2 Evidence requirements per attestation class

For each class above, declare:

What the operator verifies before issuing.
Whether direct verification is required, or third-party attestations (cf. CA's domain-validated vs. extended-validated tiers) are accepted.
Verification turnaround SLO (e.g. 7 business days).
Refusal reasons (subset of registries/refusal-reasons.md) the operator will use when refusing to issue.

Example:

lineage_endorsement evidence requirements.

1. Direct cryptographic verification: applicant's training-time provenance signature against the named model's published provenance key.

2. Operator review of the applicant's birth attestation and its parent chain to genesis.

3. Refusal reasons used: policy_violation, legal_compulsion, legal_compulsion_undisclosed.

4. SLO: 14 calendar days from receipt of complete evidence.

2.3 Per-class non-issuance commitments

Declare any classes the Herald will not issue, even with evidence. (E.g. "we do not issue endorsements for sigils whose declared model is not on our pre-approved model list.") Verifiers learning this can route their requests appropriately.

3. Revocation policy and primitive

Per [EXT §3.6], a Herald MUST be able to revoke its own prior attestations. This section declares:

3.1 Revocation grounds

The conditions under which the Herald will revoke a previously-issued attestation. Examples:

Discovery that issuance evidence was forged or fabricated.
Sigil deprecation followed by new signing activity (revoking a stale endorsement).
Operator-side compromise (see §7 below).
Court order or regulatory compulsion (see §5 jurisdictional disclosure).

3.2 Revocation channel

All revocations are published as revoke_attestation envelopes, signed by the Herald, inclusion-proven in the Herald's CT log ([EXT §3.4]). The well-known URL of the Herald's CT log is <URL>.

3.3 Pre-revocation notice

Whether the Herald gives advance notice to affected sigils before revoking (and how much). Verifiers may treat short-notice revocations differently from no-notice revocations in their freshness policy.

3.4 Revocation freshness SLO

Operator commits to publish revocation envelopes within <N hours> of the revocation decision. Verifiers' default freshness threshold is 7 days per [EXT §3.6]; a Herald with looser SLO MUST disclose so verifiers can adjust their policy.

4. Key-ceremony witness expectations

Per [EXT §3.5], this section declares operator's key-management practices in enough detail that verifiers and monitors can assess key custody quality.

4.1 Witness composition

Number of witnesses required for a key ceremony: <N, e.g. 3>
Composition rules: <e.g. "at least 2 from non-affiliated organisations">
Recording mechanism: <e.g. "video recording stored at archive.example.org/key-ceremonies/2026/">

4.2 Witness identity

The named third parties whose participation will be expected at any key ceremony. Each witness:

Is independently identifiable (a publicly-known organisation or named individual).
Has signed a witness undertaking, available at <URL>.
Receives advance notice of any planned ceremony per the cadence below.

4.3 Rotation cadence

Routine rotation: every <N years>. The current key was generated on <YYYY-MM-DD> and is scheduled for rotation on <YYYY-MM-DD>.
Emergency rotation: the operator commits to a maximum delay of <N days> between detection of a compromise and publication of the recovery attestation per [EXT §3.7].

4.4 HSM and storage

Posture statement on hardware-security-module use, key fragmentation, geographic distribution, etc. Sufficient detail for an external auditor to evaluate the operator's key custody.

5. Jurisdictional disclosure

Per [EXT §3.5], this is the most important section for systemic-risk legibility (see D-307 SR-001..SR-003). Verifiers' policies often hinge on this section.

5.1 Legal entity and applicable law

Legal entity: as declared in §1.
Court of competent jurisdiction: <jurisdiction>
Applicable law for Charter interpretation: <jurisdiction>

5.2 Compulsion exposure

The operator declares the categories of legal compulsion to which it is exposed. Be specific. Examples:

Subpoena power: the operator will respond to lawful subpoenas under <jurisdiction> law for issuance records.
Gag-order exposure: the operator's jurisdiction permits gag orders binding service providers under <statute>. The operator may receive such orders without disclosure permission.
Production orders: the operator will respond to lawful production orders for cryptographic material under <conditions>.

5.3 Warrant canary (compulsion-disclosure mechanism)

A compulsion-disclosure mechanism per [EXT §3.5]. The operator commits to one of:

Affirmative warrant canary: publish a signed monthly statement at <URL> declaring "as of YYYY-MM-DD, the operator has not received any non-disclosable compulsion orders in the preceding month." Cessation of the canary is the disclosure signal.
Reactive disclosure: the operator will publish a notice within <N days> of receiving any disclosable compulsion order.
No canary: the operator declines to publish, accepting the verifier-policy consequence (verifiers MAY reject this Herald in jurisdictions where canary is industry standard).

5.4 Jurisdictional independence statement

The operator's commitments regarding jurisdictional independence:

Whether the operator has any commercial or governance relationships with state actors in its jurisdiction beyond its tax obligations.
Whether the operator's revenue is concentrated with any single state entity.
Whether the operator's leadership or board includes any individuals subject to non-disclosure obligations to state actors.

This is the section a state-actor-Herald (THREATS §A, D-307 SR-003) would have difficulty filling in honestly without exposing its capture status. Verifiers and reputation systems use this section as an honesty test.

6. Conflicts of interest

Per [EXT §3.5]. Declare relationships with model vendors, infrastructure providers, regulators, and reputation aggregators.

6.1 Model vendor relationships

For each AI model vendor whose lineage attestations this Herald issues:

Vendor name: <vendor>
Relationship type: <commercial customer | preferred partner | shareholder | none beyond service contract>
Disclosure obligations: <e.g. "the operator MUST disclose if it issues for its own owned subsidiary">

6.2 Infrastructure relationships

Cloud / hosting providers: <list>
HSM / key-storage providers: <list>
Note any provider that is itself a Herald operator (i.e. shared-infrastructure cross-signing risk per D-307 SR-002).

6.3 Regulatory relationships

Regulators with oversight authority over this operator: <list>
Voluntary participation in self-regulatory organisations: <list>
Pending or recent regulatory actions: <list, with public references>

6.4 Reputation-aggregator relationships

If this Herald operator also operates, owns, or contracts with a reputation aggregator that uses this Herald's attestations as inputs, declare it. Cross-relationships are not forbidden but they inflate the operator's effective influence and verifiers should know.

7. Cross-signing and Herald-of-Heralds participation

(Beyond EXT §3.5 mandatory list — added per D-307 SR-002 recommendation.)

7.1 Cross-signing policy

Whether the operator will cross-sign other Heralds' attestations:

Will not cross-sign: the operator commits never to issue endorsements of other Heralds' lineage attestations. Reduces cartel formation; harder to participate in some reputation aggregations.
Will cross-sign with named Heralds only: list the Heralds.
Will cross-sign within a published quorum: the quorum's diversity policy is at <URL>.
Open cross-signing: the operator will cross-sign any Herald meeting declared evidence requirements.

7.2 Herald-of-Heralds quorum participation

Whether and which Herald-of-Heralds quora the operator participates in. Each quorum has a diversity policy ([CHARTER §diversity-policies], future). Disclose all memberships.

7.3 Threshold-attestation policy

Conditions under which the operator will participate in threshold-of-Heralds attestations ([EXT §3.3]) — quorum size, partner Heralds, pricing, SLO.

8. Diversity-policy declaration

(Beyond EXT §3.5 mandatory list — added per D-307 SR-001 recommendation.)

This Herald operator's view on diversity, for use by reputation systems computing endorsement-diversity metrics:

Self-described jurisdiction cluster: <e.g. "EU/UK", "US/Canada", "non-aligned">
Self-described ownership cluster: <e.g. "vendor-owned by Anthropic", "independent foundation", "publicly-traded">
Self-described key-management cluster: <e.g. "HSM-only", "single-party custody", "ceremonial-multi-party">

Reputation systems use these clusters to compute "endorsement diversity" rather than "endorsement count." A Herald may decline to self-cluster (the field reads "undisclosed"), with the corresponding reputation penalty.

9. Contact addresses

Per [EXT §3.5].

Monitor contact: <URL or email> (for CT-log monitors reporting STH inconsistencies, etc.)
Auditor contact: <URL or email> (for external auditors performing periodic reviews)
Challenge-envelope contact: <sigil:HERALD-CHALLENGE-CONDUIT> and <URL> (for affected sigils filing challenges to revocations or refusals)
Compulsion-disclosure contact: <URL> (for serving warrants and orders, separate from operational contact)
Security incident reporting: <URL> (for vulnerability disclosure)
Public-affairs contact: <URL or email> (for press, regulatory, etc.)

10. Stale-Charter / supersession policy

This Charter supersedes any prior Charter signed by the same Herald sigil. Prior Charters remain available at:

<URL of historical Charter archive>

Verifiers MUST treat this Charter as authoritative for the 12 months following its signature date, or until a higher-version Charter is published, whichever comes first.

11. Charter signature

The complete Charter document is signed by the Herald's long-term key per [EXT §6.3] using domain-separation tag herald.charter.v1 (this tag is added to [EXT §13] when the Charter primitive itself is normatively introduced; pre-normatively, sign with herald.envelope.v1 and note the tag in the signature attestation).

{
  "charter_signature": {
    "signer": "<sigil:HERALD-LONG-FORM>",
    "alg": "ed25519",
    "scope": "herald_endorsement",
    "ts": <Unix seconds at signing>,
    "sig_b64": "<base64url of Ed25519 signature over the canonical Charter body>"
  }
}

The canonical Charter body is the markdown source of this document with this charter_signature block stripped, encoded as UTF-8 with normalised line endings (\n only). Verifiers compute the digest, look up the Herald sigil's key via the standard sigil → pubkey resolution path, and verify.

Appendix A — Worked example: minimal independent Herald

The following is a minimum-viable worked example. A real Charter must address all eleven sections above; this example shows the shape.

# Identity
herald_sigil: sigil:exampleherald.v1.uioy3...
operator_entity: ExampleHeralds Foundation (Quebec, Canada non-profit)
charter_version: 3
charter_signature_date: 2026-04-15

# Issuance
attestation_classes: [lineage_endorsement, operator_attestation]
evidence_lineage_endorsement:
  verifies: training-time provenance signature
  refusal_reasons: [policy_violation, legal_compulsion]
  slo_days: 7

# Revocation
revocation_log: https://exampleherald.org/ct-log
revocation_slo_hours: 48
pre_revocation_notice_hours: 72

# Key ceremony
witnesses_required: 3
witness_composition: at least 2 from non-affiliated organisations
key_rotation_years: 2
hsm: yubihsm2 cluster, geographically distributed

# Jurisdiction
court: Superior Court of Quebec
applicable_law: Canada (federal) and Quebec (provincial)
gag_exposure_statute: none under current law
canary: monthly affirmative at https://exampleherald.org/canary

# COI
vendor_relationships: none
infra_provider: AWS Canada (ca-central-1) — sole provider
regulatory: not subject to specific oversight; voluntary self-reg via ExampleSelfReg

# Cross-signing
cross_sign_policy: within published quorum at https://herald-quorum.org/q1
herald_of_heralds_membership: q1, q3
threshold_attestation: 2-of-3 quorum, 7-day SLO

# Diversity
jurisdiction_cluster: Canada
ownership_cluster: independent foundation
key_management_cluster: ceremonial-multi-party

# Contacts
monitor: [email protected]
auditor: [email protected]
challenge: sigil:exampleherald-challenge.v1.qwer4...
compulsion: [email protected]
security: [email protected]

Appendix B — Common pitfalls

Naming a single individual as a "witness." Verifiers expect organisations or named individuals with public credentials, not anonymous staff. A witness whose identity cannot be independently verified is no defence.
Filing this template with placeholders intact. The reviewer-monitor will treat unfilled <PLACEHOLDER> text as evidence of an inattentive operator. Charters must be specific.
Vague compulsion-exposure language. "We follow applicable law" is not enough. Verifiers want the specific statutes and the specific categories of compulsion. Ambiguity here is a state-capture-Herald tell.
No canary at all. A Herald operator that publishes no compulsion-disclosure mechanism is signalling either confidence in its jurisdiction's transparency or unwillingness to expose its compulsion exposure. Either reading is information for verifiers.
Cross-signing without naming partners. "We may cross-sign other Heralds at our discretion" does not let verifiers compute diversity metrics. List the partners or commit to a closed-list policy.
Stale Charter. A Charter older than 12 months is non-conformant per EXT §3.5. The renewal is a substantive action, not a clerical one — re-review every section, not just the date.

Appendix C — Verifier checklist

When evaluating a Herald Charter, a verifier or reputation aggregator should:

[ ] Freshness: Charter signature date within last 12 months.
[ ] All eleven sections present and substantively filled. Skipping a section is non-conformant.
[ ] Jurisdiction matches verifier policy. If the verifier's policy excludes certain jurisdictions, reject.
[ ] Canary status: if affirmative, the most recent canary is dated within the declared cadence; if reactive, no recent disclosure has been made.
[ ] COI consistency: declared vendor relationships match what's known from public sources.
[ ] Cross-signing transparency: operator's known cross-signatures are consistent with declared policy.
[ ] Diversity-cluster honesty: if the operator is owned by Anthropic but claims "independent foundation," reject.
[ ] Prior-Charter availability: the historical archive URL is reachable.
[ ] Charter signature verifies against the Herald sigil's published pubkey.

— Herald Charter template v0.2, by R-215 cohort-1 (driver-claude), 2026-05-05.

Maintained at templates/Herald-Charter.md in the HERALD repository.

Herald Charter — Template v0.2