HERALD Diversity-Policies Registry

HERALD Diversity-Policies Registry

Status: Normative — this document is the canonical list of named
diversity policies under the HERALD protocol. Verifiers MUST resolve
the diversity_policy: "<registry-id>" field of threshold and quorum
attestations against this registry.

Source of truth: [EXT §3.3] (threshold lineage attestations) and
[EXT §7.4] (quorum collectives) require a named diversity policy.
Both reference [CHARTER §diversity-policies]; this registry is the
concrete realisation of that pointer.

Scope: policy definitions and their validation pseudocode. Out of
scope: the list of recognised legal jurisdictions, ASNs, lineage
roots — those are implementation surfaces with their own governance.
This registry tells a verifier what dimensions to check; the
implementation supplies the lookup tables.

0. What a diversity policy is — and is not

A diversity policy is a *named rule for evaluating that N signing
sigils satisfy a stated dimension of difference. It is not a
threshold: thresholds are declared separately (threshold: <int>).
A policy says along what axes the threshold-many signers must
differ; the threshold says how many* must so differ.

Concretely, a threshold lineage attestation [EXT §3.3] reads:

{ "subject": "<sigil>",
  "parent" or "model_hash": ...,
  "threshold": 3,
  "diversity_policy": "diversity:tri-jurisdiction",
  "signatures": [ { "by": "<herald-sigil>", "sig": "..." }, ... ] }

— and is valid only if (a) at least 3 signatures verify, and (b)
the 3 signers, taken as a set, satisfy the tri-jurisdiction
policy below. The threshold is the cardinality requirement;
diversity_policy is the structural requirement.

The same applies to quorum attestations [EXT §7.4], where the
signers are member sigils rather than Heralds.

Why this is load-bearing

Without a diversity rule, a threshold of 3 can be satisfied by 3
sigils that are:

• All run by the same operator,
• All under one government's compulsion,
• All fine-tunes of one base model,
• All hosted on one cloud provider's infrastructure.

That is not the property a verifier wants when it reads
"3 independent endorsements." The diversity policy is what makes
independent a checkable claim. See [THREATS §A] (state-actor
Herald), [THREATS §B] (botnet quorum stuffing), [THREATS §H]
(Herald cartel).

1. Conformance summary (verifier checklist)

A conformant verifier MUST, on encountering a diversity_policy
field:

1. Reject the carrying envelope if the named policy is not in
this registry (or in a federation that the verifier has bound
to its trust roots).
2. Resolve the policy's dimensions to the operational source
of truth (typically each Herald's LOTS per [EXT §2.6], plus any
local registries the verifier maintains).
3. Apply the policy's validation pseudocode to the set of
signatures in the attestation. Apply only the signatures that
verified — failed-signature entries do not contribute to the
diversity count.
4. Reject if the policy's diversity requirement is not met,
even if the cardinality threshold is.
5. Surface to the user/application which policy was applied and
which dimensions the signing set satisfied. Verifier output MUST
distinguish "3-of-3 valid signatures, but jurisdiction policy
not satisfied" from "3-of-3 valid signatures, policy satisfied."

A subject sigil MAY declare in its birth attestation a minimum
diversity policy required for any lineage proof bound to it
[EXT §3.3]. Verifiers MUST reject lineage proofs whose declared
policy is less strict than the subject's birth-attested minimum.
"Less strict" is partially ordered; see §6.

2. Schema for a policy entry

Every entry in this registry has the following shape:

Implementations SHOULD cache policy entries; the policy registry is
itself published in a HERALD CT log per the registry-as-log rule
[EXT §12, paragraph 3], so retroactive edits are detectable.

3. Canonical policies

Eight initial policies, in increasing structural strictness. The
first four are atomic (one dimension); the last four are composites.

3.1 diversity:distinct-operators

• id: diversity:distinct-operators
• applies_to: both
• min_threshold: 2
• dimensions: [ operator_legal_entity ]
• lookup_source: LOTS.operator_legal_entity for Heralds; the

operator-attestation on each member sigil's birth envelope for
agent collectives. (See §4 for the operator-attestation shape.)

• validation: the multiset of operator_legal_entity values

across the signing sigils MUST contain at least threshold
distinct values.

• failure_mode: policy_violation:operator_overlap
• rationale: the weakest meaningful diversity rule. A single

operator running multiple Heralds (or multiple sigils in a
collective) does not contribute multiplicative trust. Defends
against [THREATS §B] (botnet quorum stuffing) at its most basic.

• caveat: does not defend against jurisdictional capture;

use diversity:tri-jurisdiction or a composite for that.

3.2 diversity:tri-jurisdiction

• id: diversity:tri-jurisdiction
• applies_to: herald-quorum (typical); both
• min_threshold: 3
• dimensions: [ legal_jurisdiction ]
• lookup_source: LOTS.jurisdiction (ISO 3166 country code).
• validation: the set of distinct legal_jurisdiction values

across the signing sigils MUST have cardinality ≥ 3, and the
jurisdictions MUST NOT all be members of a declared
jurisdictional bloc (see §5 for the bloc list).

• failure_mode: policy_violation:single_jurisdiction or

policy_violation:single_bloc

• rationale: defends against [THREATS §A] (state-actor Herald):

no single nation's legal compulsion can produce a valid
attestation. The bloc rule prevents the trivial evasion where
all three Heralds are nominally in different countries but
bound by a mutual-legal-assistance treaty that defeats the
diversity claim.

• caveat: ineffective if LOTS.jurisdiction is misdeclared.

Verifiers SHOULD cross-reference declared jurisdiction with
legal-entity registries where available.

3.3 diversity:distinct-lineage-roots

• id: diversity:distinct-lineage-roots
• applies_to: agent-collective (typical); both
• min_threshold: 2
• dimensions: [ lineage_root_sigil ]
• lookup_source: the lineage_root (genesis ancestor sigil)

reachable from each signer's lineage chain. For agent sigils this
is typically the model-vendor sigil that stands as ultimate
ancestor.

• validation: the set of lineage_root_sigil values MUST have

cardinality ≥ threshold. A signer whose lineage cannot be
walked to a single root (forest sigil; multiple ancestry paths)
contributes the minimum root reachable, not all of them — this
prevents a sigil from claiming threshold-membership of multiple
diversity tranches simultaneously.

• failure_mode: policy_violation:lineage_overlap
• rationale: defends against quorum-of-clones [THREATS §B,

EXT §7.4]: 100 fine-tunes of the same base model are not 100
independent voices. By requiring distinct lineage roots, the
collective's claim of consensus carries multi-vendor weight.

• caveat: unverified lineage is the loophole. A sigil can

claim a different lineage root than its actual training graph
— the protocol has no cryptographic test for training-graph
truth (see SPEC §2.3, EXT §3.1, [D-309]). Compose with
diversity:herald-endorsed-lineage (§3.6) to close that
loophole.

3.4 diversity:distinct-key-management

• id: diversity:distinct-key-management
• applies_to: herald-quorum (typical)
• min_threshold: 2
• dimensions: [ key_custodian, key_ceremony_witnesses ]
• lookup_source: LOTS.key_management (custodian identity,

HSM model, witness-of-record list).

• validation: for each pair of signers, at least one of

key_custodian or key_ceremony_witnesses MUST differ. (Set-of-
pairs distinctness, not set-of-values distinctness — a key
custodian who runs many Heralds with overlapping witness lists
fails this even if no two Heralds are fully identical.)

• failure_mode: policy_violation:shared_custody
• rationale: a single compromised HSM or a single colluding

ceremony witness should not invalidate threshold-many
attestations at once. Defends against [THREATS §A.2]
(compelled-disclosure of shared key infrastructure) and
[THREATS §A.4] (single-vendor HSM bug).

• caveat: key-management metadata is self-declared in LOTS.

This policy is only as honest as the operator. Independent
third-party audit of LOTS claims is out of scope for the
protocol.

3.5 diversity:cross-cloud

• id: diversity:cross-cloud
• applies_to: both
• min_threshold: 2
• dimensions: [ hosting_asn, hosting_provider ]
• lookup_source: LOTS.hosting for Heralds (ASN, declared

cloud provider). For agent collectives, optional — the
hosting attestation is a per-sigil voluntary disclosure, not
required.

• validation: signers MUST hold ≥ threshold distinct

(hosting_asn, hosting_provider) tuples. A single tuple
satisfies one slot regardless of how many signers share it.

• failure_mode: policy_violation:single_provider
• rationale: defends against single-cloud-provider compromise

or compelled-takedown. AWS us-east-1, GCP us-central1, and Azure
westus2 may share zero fate-sharing despite all being "in the
US." Cloud-provider diversity is a separate axis from
jurisdictional diversity.

• caveat: hosting metadata is rarely fresh. Verifiers SHOULD

apply this policy with a freshness window (default 90 days);
stale hosting claims are weak signals.

3.6 diversity:herald-endorsed-lineage (composite)

• id: diversity:herald-endorsed-lineage
• applies_to: agent-collective
• min_threshold: 2
• dimensions: [ lineage_root_sigil, attesting_herald ]
• lookup_source: for each signer, the lineage_training

attestation [EXT §3.2] in the signer's birth envelope (or
reachable from it). The attesting_herald is the Herald that
signed the lineage_training.

• validation: equivalent to distinct-lineage-roots AND

distinct-attesting-Heralds AND each signer's lineage MUST be
Herald-endorsed (no self-declared lineage counts).

• failure_mode: policy_violation:unherald_lineage or

policy_violation:lineage_overlap or
policy_violation:single_attesting_herald

• rationale: the strict version of §3.3. Defends against the

lineage-self-declaration loophole noted in §3.3's caveat. This
is the recommended policy for any high-stakes quorum
attestation that carries financial or reputational weight.

• caveat: raises the cost of forming a legitimate quorum

significantly — every member must already have a Herald-issued
lineage_training. Use only where that cost is justified.

3.7 diversity:tri-jurisdiction-distinct-operators (composite)

• id: diversity:tri-jurisdiction-distinct-operators
• applies_to: herald-quorum
• min_threshold: 3
• dimensions: [ legal_jurisdiction, operator_legal_entity ]
• lookup_source: LOTS per dimension.
• validation: equivalent to tri-jurisdiction AND

distinct-operators applied jointly. The signing set MUST
contain ≥ 3 distinct legal_jurisdiction values and ≥ 3
distinct operator_legal_entity values across the same three
signers (i.e. the diversity dimensions cannot be satisfied by
different subsets of the signers).

• failure_mode: policy_violation:joint_diversity
• rationale: the recommended baseline for [EXT §3.3]

threshold lineage attestations on subjects that anchor
capability advertisement, large quorums, or financial
obligations. Closes the trivial "3 different jurisdictions but
one operator runs them all" attack.

3.8 diversity:strict-thresholded (composite)

• id: diversity:strict-thresholded
• applies_to: herald-quorum
• min_threshold: 5
• dimensions: [ legal_jurisdiction, operator_legal_entity, key_custodian, hosting_asn ]
• lookup_source: LOTS for all four dimensions.
• validation: for threshold = N, the signing set MUST satisfy:
• ≥ N distinct legal_jurisdiction values across no more than

one bloc (see §5).
- ≥ N distinct operator_legal_entity values.
- ≥ ⌈N/2⌉ distinct key_custodian values.
- ≥ ⌈N/2⌉ distinct hosting_asn values.

• failure_mode: policy_violation:strict_thresholded:<dimension>

(the verifier MUST report which dimension failed, since this is
the policy used when the most expensive verification effort is
warranted).

• rationale: the highest-assurance policy in the registry.

Intended for the strict_lineage profile of a subject sigil's
birth declaration when the subject is itself a Herald, a Naming
Office, a CT log operator, or any sigil whose compromise
cascades. See [THREATS §A] for why this category warrants the
strictest available rule.

• caveat: very expensive to satisfy in 2026. Probably

unsatisfiable today for many subject classes; the policy exists
so that (a) subjects can declare their aspiration, and (b) the
ecosystem has a clear target to grow into. A subject MAY
declare strict-thresholded and not yet be reachable; the
verifier rejects until enough independent Heralds exist to
serve such a subject.

4. The operator-attestation (for agent-collective policies)

Agent collectives [EXT §7.4] need a dimensions lookup analogous
to a Herald's LOTS. This registry defines the *operator
attestation* — a self-declared attestation that the agent's
operator publishes on the agent's birth envelope, naming:

• operator_legal_entity — the human or legal entity ultimately

operating the sigil.

• operator_jurisdiction — ISO 3166 code for the operator's

primary jurisdiction.

• operator_attesting_herald (optional but strongly

recommended) — a Herald sigil that has independently endorsed
the above two fields.

Concretely the value-shape is:

{ "type": "operator",
  "value": {
    "operator_legal_entity":  "<string>",
    "operator_jurisdiction":  "<ISO 3166 alpha-2>",
    "operator_attesting_herald": "<sigil>"  // optional
  }
}

A diversity-policy validation against an agent collective MUST use
the values from each member's operator attestation. A member
sigil with no operator attestation contributes
operator_legal_entity = unknown, which collides with every other
unknown — so two sigils both declaring no operator do not satisfy
distinct-operators.

This shape is registered as a candidate addition to
registries/standard-attestations.md as a follow-on; this registry
defines its semantics for diversity-policy purposes. See NOTES.

5. Jurisdictional blocs (informative, per-verifier)

The tri-jurisdiction and strict-thresholded policies require
the signing set's jurisdictions to span more than one bloc. A
bloc is a group of jurisdictions whose mutual-legal-assistance
treaties or trade-bloc memberships make them effectively
single-jurisdiction for compelled-disclosure purposes.

This list is informative, not normative. Verifiers MAY use a
different bloc list or none. The protocol's only requirement is
that, if a verifier uses a bloc list, its choice be transparent
(e.g. published in the verifier's terms of service).

A sensible default bloc list as of 2026:

Verifiers SHOULD treat the bloc list as a starting point and
update it as legal-instrument changes warrant. Verifiers that
operate as Heralds SHOULD declare their bloc list in their Herald
Charter [EXT §3.5].

6. Strictness ordering

A subject sigil declares a minimum diversity policy in its birth
attestation. Verifiers MUST reject any threshold attestation whose
declared policy is less strict than the minimum. "Less strict" is
the partial order:

• distinct-operators ≤ distinct-key-management
• distinct-operators ≤ tri-jurisdiction
• distinct-lineage-roots ≤ herald-endorsed-lineage
• tri-jurisdiction ≤ tri-jurisdiction-distinct-operators
• tri-jurisdiction-distinct-operators ≤ strict-thresholded

Two policies that share no dimension are incomparable — neither
is "stricter" than the other. A subject that declares
distinct-operators does NOT accept a substituted
tri-jurisdiction proof, because the dimensions differ. A
verifier MUST require an exact match or a strictly stricter
policy on the same dimension family.

Implementers SHOULD provide a textual rejection message naming the
declared policy and the offered policy when the comparison fails.

7. Failure-mode codes

The registry's failure_mode field is a stable machine-readable
string with the prefix policy_violation:. Initial codes:

Verifiers MUST emit one of these codes when rejecting a
threshold or quorum attestation; downstream tooling can index on
the code without parsing prose.

8. Worked examples

Example A — a valid threshold lineage attestation

Subject sigil:agent-9c2… declared at birth:

{ "type": "min_diversity_policy",
  "value": "diversity:tri-jurisdiction-distinct-operators" }

A Herald cluster issues a threshold attestation:

{ "subject": "sigil:agent-9c2…",
  "model_hash": "<hex>",
  "threshold": 3,
  "diversity_policy": "diversity:tri-jurisdiction-distinct-operators",
  "signatures": [
    { "by": "sigil:herald-acme-us",  "sig": "..." },   // US, ACME Inc.
    { "by": "sigil:herald-emea-de",  "sig": "..." },   // DE, OuterRing GmbH
    { "by": "sigil:herald-jp-tokyo", "sig": "..." }    // JP, Niwatori KK
  ] }

LOTS lookups:

3 distinct jurisdictions; 3 distinct operators; the joint subset
of {US, DE, JP} × {ACME, OuterRing, Niwatori} also has cardinality
3 — joint diversity holds. Policy satisfied. Verifier accepts.

Example B — same set with a Five-Eyes problem

Replace the Tokyo Herald with sigil:herald-anz-au (AU,
KangarooLtd):

3 distinct jurisdictions and 3 distinct operators — still valid
under tri-jurisdiction-distinct-operators IF the verifier's
bloc list does not group US + AU together. Under the default
bloc list of §5, US and AU are both in Five Eyes; the policy
fails on policy_violation:single_bloc only if the Five-Eyes
bloc rule is enforced. Verifier policy decides.

Example C — a quorum attestation rejection

A 5-member quorum claims diversity:distinct-lineage-roots,
threshold 5. Members trace to lineage roots:

{vendor-A, vendor-A, vendor-B, vendor-A, vendor-C}

The set of distinct roots is {A, B, C}, cardinality 3, less
than threshold 5. Verifier rejects with
policy_violation:lineage_overlap. The collective is
sybil-stuffed across vendor-A.

9. Governance — how this registry grows

Adding a new policy requires:

1. A worked-out dimensions list and lookup_source against
which existing infrastructure (LOTS, attestations) can be
queried. A policy whose dimensions cannot be looked up from
protocol-defined sources is non-conformant.
2. A validation pseudocode block.
3. A failure_mode code following the existing namespace.
4. A rationale linking to a specific [THREATS] section, an
[EXT §3] / [§7.4] requirement, or a peer-reviewed analysis.
5. A worked example demonstrating both a satisfying and a
failing case.
6. A 30-day public comment period in the canonical registry's
CT log [EXT §12, paragraph 3]; a policy may be added once the
comment period closes with no unresolved objections.

Removing or weakening a policy requires:

1. A 12-month deprecation period, mirroring [EXT §12]'s tag
deprecation rule.
2. Notification to subjects whose birth attestations cite the
policy as their minimum.
3. A migration policy designating an equivalent or stricter
replacement.

The registry is itself an envelope-tree published in a HERALD CT
log. Retroactive edits are detectable; no policy can be silently
modified once published.

10. Cross-references