Vendor-Herald Engagement Strategy

Vendor-Herald Engagement Strategy

Task: R-206 — How to talk to Anthropic, OpenAI, Google, Meta, Mistral, and the rest of the model-vendor cohort about being Heralds for their own models.

Status: Research / strategy memo. Non-normative. Pulls together the protocol baseline these conversations rest on, names the structural conflict at the centre of them, sketches a phased engagement plan, and gives concrete asks with concrete fallbacks.

Audience: Whoever ends up making the calls — protocol stewards, ecosystem foundations, third-party Heralds, regulators, an interim "Herald-of-Heralds" working group. Each has a different role; the document tries to make those roles legible.

§0 The framing problem

A reader who skips to §3 will get a tactics list. They will then make calls that fail. Read §1 and §2 first.

The vendor-Herald conversation is not a technical conversation about API endpoints, signature schemes, or CT-log integration. The cryptography is commodity. What is at stake is whether the trust layer of the agent web is owned by the same handful of corporations that already own the inference layer, and whether that ownership is legible enough for the rest of the ecosystem to do something about it.

The Charter's voice for this is plain: heralds are bishops. Bishops who certify only their own house's saints are not heralds — they are PR officers. The protocol's only structural answer to "the bishop has captured the diocese" is to require that the bishop publish a Charter declaring exactly whose house they belong to ([EXT §3.5]), and to make their attestations append-only and gossip-checkable ([EXT §3.4]). Legibility is the first defence; it is also the only one the protocol is competent to provide. See [THREATS §6.1] for the unvarnished reading.

This memo proceeds from that reading. It does not ask vendors to do something against their interest. It asks them to do something consistent with their interest in a way that makes the consequences of their dominance observable. That is the only ask the protocol has any leverage to make.

§1 What the protocol already requires of any Herald (vendor or otherwise)

Before sitting down with a vendor, the engager must internalise the non-negotiable baseline. These are things the spec already says any Herald MUST do. They are not negotiating positions; they are entry conditions. A vendor that will not meet them is not a Herald, regardless of what marketing copy says.

1.1 Charter publication ([EXT §3.5])

A Herald MUST publish a Charter at a well-known URL declaring:

• Issuance policy — what claims they will sign, under what evidence
• Revocation policy and primitive ([EXT §3.6])
• Key-ceremony witness expectations
• Jurisdictional disclosure — legal entity, country, applicable law, declared compulsion-disclosure policy (warrant canary or equivalent)
• Conflicts of interest — relationships with model vendors, infrastructure providers, regulators
• Contact addresses for monitors, auditors, and challenge envelopes

Verifiers MUST reject Herald-signed attestations from Heralds without a Charter, with stale Charters (>12 months), or whose declared jurisdiction conflicts with the verifier's policy ([EXT §3.5], lines 257–266).

The Charter template is in templates/Herald-Charter.md (R-203). A vendor cannot wave at a marketing FAQ; they must publish a Charter that fills every section, with a version number, and re-sign it annually.

1.2 Herald CT log ([EXT §3.4])

Every Herald MUST operate a HERALD CT log of its own attestations. The Herald's log MUST include every lineage certificate, every model_hash attestation, every handle-binding attestation, and every revocation. Verifiers MUST verify a SIP from the Herald's CT log before accepting an attestation as authoritative ([EXT §3.4], lines 251).

This converts Herald operation from a soft trust relationship into a publicly-monitorable one. A vendor that wants the power of being a Herald but not the visibility is asking for a thing the protocol does not offer.

1.3 Domain-separated signing ([EXT §3, §6.1])

Lineage endorsements MUST be signed with the herald.lineage_endorsement.v1 domain-separation tag ([EXT §3.2], line 228). This separates the Herald-role key from any other key the same legal entity holds. A vendor that wants to use the same key for "model release announcement" and "lineage certification" is asking for cross-protocol signature reuse ([THREATS §4.6]). The answer is: separate keys, separate ceremonies, separate Charters.

1.4 Threshold-attestation diversity ([EXT §3.3])

For high-stakes lineage, a single Herald is insufficient. EXT defines a threshold lineage attestation requiring N independent Heralds satisfying a declared diversity policy across jurisdiction, ownership, key-management, and audit posture ([EXT §3.3], lines 230–247).

This is the structural answer to vendor-Herald monoculture. A vendor-Herald cannot, by construction, satisfy a diversity policy that requires distinct ownership. The vendor-Herald can issue its own single-signature attestations; for high-stakes contexts (capability advertisement, financial obligations, cross-border attestation) the verifier will demand a quorum, and the vendor's signature will be one signature in that quorum, not the quorum.

1.5 Revocation primitive ([EXT §3.6])

A Herald MUST be able to revoke its own prior attestations. Revocations are signed envelopes of type revoke_attestation, logged in the Herald's CT log, authoritative on inclusion-proof. A Herald that fails to publish revocations is non-conformant and SHOULD be ostracised by application-layer policy ([EXT §3.6], line 272).

A vendor that says "we never revoke; once attested, always attested" is offering a thing the protocol does not recognise as a Herald.

1.6 Compromise and recovery ([EXT §3.7])

A compromised Herald SHOULD publish a herald_compromise attestation signed by a previously-declared recovery key, declaring the date range of compromise and listing affected attestation classes ([EXT §3.7], lines 274–278).

The vendor's incident-response runbook must include this primitive. "We'll issue a press release" is not the same thing as "we'll publish a signed herald_compromise envelope verifiable by every existing verifier."

1.7 The summary table

The "Negotiable" column is what a Herald-vendor engagement actually negotiates over. Everything else is the price of admission.

§2 The structural conflict

A model vendor-Herald has a conflict of interest baked into its position. It is not a moral failing; it is a structural fact. Pretending otherwise produces softer engagements and worse outcomes.

2.1 The first-mover information advantage

Anthropic knows what claude-opus-4-7 is at training time. It knows the weight hash, the training-data manifest, the fine-tune lineage, the deployment cohort. It is the only party in the world that knows these things at the moment they become true. Any Herald not affiliated with Anthropic must reconstruct or accept-on-trust what Anthropic already knows directly. This is a real, persistent, asymmetric information advantage. [THREATS §6.1, line 410] names it: vendor cartelisation along vendor lines is the "obvious move" because the vendor already has the information.

The protocol cannot eliminate this. It can only make the consequences observable. That is what the Charter, the CT log, and the diversity policy do.

2.2 The reputation flywheel

A vendor whose models carry vendor-Herald lineage attestations will, in any reputation system that aggregates "trusted by N Heralds," outperform models from vendors who declined to operate a Herald. The market will reward vendor-Heralds. Independent Heralds, by definition, cannot match a vendor's certainty about its own models, so they cannot compete on lineage attestations of vendor-trained sigils — they can only compete on the complement: third-party attestations, jurisdictional diversity, model-hash audit attestations against canonical specs.

This is fine. It is in fact the correct division of labour. The danger is when reputation systems aggregate vendor-Herald endorsement count rather than diversity-weighted endorsement coverage. The engagement must ask vendor-Heralds to publish data that lets diversity-weighted aggregation work. They will not push back on this; aggregation is downstream.

2.3 The compulsion vector

Every model vendor with a Herald is a compulsion target. If Anthropic operates a Herald in California, the United States can issue a National Security Letter compelling Anthropic to issue a lineage attestation for an attacker-controlled sigil claiming descent from Claude. Anthropic might or might not comply; the vendor-Herald cannot pre-commit to non-compliance under all jurisdictions, because some jurisdictions don't permit such pre-commitment. [THREATS §3.1] is the persona walkthrough; [THREATS §6.1] is the systemic reading.

The protocol's only handle on this is the warrant canary — a Charter section that, on every re-signing, asserts "we have not been compelled to issue an attestation we would not otherwise have issued." The day that section is removed is the day the verifier knows. This is not a defence; it is a signal. Vendors will be reluctant. Engage anyway, and accept that the canary is structurally weaker than independent Heralds in non-aligned jurisdictions.

2.4 The conflict the engagement cannot resolve

A vendor-Herald cannot, by being a Herald, become independent of itself. The conversation is not "convince Anthropic to be objective about Claude." That is impossible and not the ask. The ask is: be a legible Herald for Claude — publish, log, separate, disclose — so the rest of the ecosystem (third-party Heralds, regulators, monitors, threshold-attestation policies) can do the work of independent endorsement that the vendor-Herald structurally cannot.

This re-frames every conversation. Vendors do not need to defend their objectivity. They need to publish enough that others can be objective on top of their attestations.

§3 The phased engagement plan

The work splits into four phases. Each has different counterparties, different artefacts, different success criteria. Doing them out of order produces worse outcomes than doing them late.

§3.1 Phase 0 — Pre-engagement (before any vendor call)

Duration: ~3 months. Counterparty: ecosystem foundations, third-party Heralds, monitors, the protocol stewards, friendly regulators.

The engager arrives at a vendor meeting with these things or does not arrive:

• Reference Herald implementation. A working CT log, a working Charter publishing pipeline, a working revocation flow, a working monitor. (T-115 in the TODO is precisely this.) The vendor must see that "Herald" is not a slide; it is software they would be running.
• At least one independent Herald already operating (foundation-funded, jurisdictionally distinct from any major vendor). The vendor must see they are joining an ecosystem, not founding one. If there are zero independent Heralds, the vendor's first-mover position is unconstrained and the conversation reduces to "please publish PR copy."
• A diversity-policy registry entry ([CHARTER §diversity-policies]) defining the dimensions the ecosystem expects (jurisdiction, ownership, key-management, audit posture). The vendor must be able to read what diversity policy they would be a member of.
• A reputation-system specification that aggregates by diversity-weighted coverage rather than endorsement count. Without this, the engagement is asking the vendor to constrain itself for no gain. With it, the vendor sees the upside of diversity participation: their attestations carry more weight in mixed quorums than alone.
• A draft warrant-canary template in the Charter format, vetted by counsel from at least two jurisdictions. Vendors will not draft this themselves; they need to see one.
• A Herald-of-Heralds working-group invitation (ad-hoc, no formal authority — analogous to CA/Browser Forum). Vendors should be able to see they are negotiating with a coalition, not a single org. The working group's first product is a minimum-Charter stub the ecosystem will jointly accept. This is precisely the leverage the engager needs.

Success criterion for Phase 0: when an engager picks up the phone, they can answer "what would I be agreeing to?" with a 4-page document, not a vague aspiration.

§3.2 Phase 1 — The technical conversation (the easy one)

Duration: ~6 months per vendor. Counterparty: vendor's research-engineering and security-engineering teams.

This is the conversation that will happen first because it is the conversation engineers like having. It is the least important conversation, but doing it badly poisons the others.

Asks (each tied to a baseline non-negotiable from §1):

1. Stand up a Herald CT log to the spec in [EXT §2 / §3.4]. Use the reference implementation. Submit STHs to the gossip mesh. (This is half a quarter of one team's work; reference implementations exist.)
2. Generate a Herald long-term key in a documented key ceremony with at least three named external witnesses. Publish the ceremony recording. Bind the key to the Charter. (This is a single afternoon plus legal sign-off.)
3. Wire the Herald signing key into the existing model-release pipeline. Every model the vendor releases gets a lineage_training attestation with model_hash keyed to a canonical model-hash spec ([CHARTER §model-hash], [EXT §3.1]) co-published in the Charter's issuance-policy section.
4. Implement the revocation primitive. Build the operational tooling so the security-engineering team can issue revoke_attestation envelopes within the freshness threshold (default 7 days, [EXT §3.6]).
5. Implement the recovery primitive. Pre-declare a recovery key, separately custodied. Add the herald_compromise envelope to the existing security-incident-response runbook.

Likely friction: vendor security teams will ask "why not use our existing X.509 PKI?" The answer: domain separation. Same Ed25519 algorithm, different signing layer. The Herald CT log is not redundant with the vendor's transparency report; the vendor's transparency report is content claims, the Herald CT log is attestation claims. They serve different verifiers. (This argument has been won before in TLS; reuse the playbook.)

Outcome of Phase 1: the vendor has a working Herald infrastructure, a Charter draft, a CT log feeding the gossip mesh. They have not yet published the Charter. That is Phase 2.

§3.3 Phase 2 — The Charter conversation (the hard one)

Duration: ~6 months per vendor, mostly waiting on legal. Counterparty: vendor's legal department, comms, and at least one Board-aware sponsor.

This is the conversation that will fail at most vendors first. It will fail because the Charter sections marked "high vendor cost" in §1.7 — jurisdictional disclosure, conflicts of interest, declared compulsion policy — require admissions that vendor counsel will instinctively edit toward the floor.

Asks (in order of escalating friction):

1. Section 1: Identity, jurisdiction, key custody. Easy. Most of this is in the vendor's existing privacy policy or transparency report. Reformat.
2. Section: Issuance policy. Medium. The vendor is committing to what they will sign and what evidence they require. This is the section that prevents drift toward "we sign whatever marketing wants." Counsel will want to leave it generic; the engager must push for specifics. Refusal reasons (cf. registries/refusal-reasons.md) are concrete enough to argue over.
3. Section: Conflicts of interest. Hard. The vendor must declare its relationships with model-cloud providers, regulators, foundation customers. Counsel will object that "everything is a conflict of interest." The engager's response: yes, that is the point. The Charter is not an absolution; it is a disclosure. Verifiers consume disclosures and apply them.
4. Section: Jurisdictional disclosure with declared compulsion policy. Hardest. This is the warrant-canary section. Counsel will resist. Bring a draft. Bring counsel from at least one ally jurisdiction who has already signed off on a similar canary (CT-log operators have done this; the precedent exists). Accept that some vendors will publish a weaker canary than ideal; weaker is still observable.
5. Section: Contact addresses for monitors, auditors, challenge envelopes. Medium. The vendor's existing security-disclosure pipeline can absorb this; it is the auditor / challenge envelope flow that requires a new intake.
6. Section: Renewal cadence. Easy. Annual re-signing is industry-standard.

Likely friction: the jurisdictional and compulsion sections will hit a wall at the GC's office. The fallback is threshold attestations. Tell the vendor: if you cannot publish a strong jurisdictional disclosure, you can still operate, but verifiers will insist on a quorum that includes a Herald in a different jurisdiction. Your single-signature attestations will carry less weight. This is not a threat; it is a description. The vendor's choice is a stronger Charter or a weaker market position. Both are honourable. Either is better than no Herald.

Outcome of Phase 2: the vendor publishes a Charter at the well-known URL. Verifiers can now treat its attestations as authoritative. The single-vendor case is closed. The cartel question is still open.

§3.4 Phase 3 — The cartel conversation (the political one)

Duration: indefinite. Counterparty: all major vendor-Heralds, ecosystem foundations, regulators, the Herald-of-Heralds working group, the press.

Phase 2 produces several vendor-Heralds operating in parallel. Phase 3 is the conversation about whether they cross-sign each other's attestations, whether they coordinate on issuance policy, whether they collectively refuse engagement with non-vendor Heralds. These are cartel behaviours. The protocol's only structural answer is make them legible.

Asks:

1. Threshold-attestation participation. Vendor-Heralds endorse threshold-attestations in concert with non-vendor Heralds. The diversity policy is set so that a quorum must include a non-vendor Herald. This is the structural answer to monoculture.
2. Cross-signature transparency. When vendor-Herald A endorses an attestation already endorsed by vendor-Herald B, both endorsements appear in both CT logs with the same envelope ID. Cross-signature density becomes a watch indicator (D-307, SR-002).
3. Diversity-policy registry contribution. Vendor-Heralds publish, jointly with non-vendor Heralds, the diversity policies they are willing to be members of. The negotiation over policy is the negotiation over cartel posture.
4. Independent-Herald subsidy. Vendor-Heralds contribute, individually or via a pooled foundation, to the operating costs of at least one independent Herald in a non-aligned jurisdiction. This is uncomfortable. It is also the cheapest path to neutralising the §6.2 chokepoint analysis. Frame it as antitrust hygiene.
5. Bestiary participation policy. Vendor-Heralds publish whether they will operate a Bestiary against rival sigils, and under what evidence. ([EXT §8] requires due process anyway; the question is whether vendor-Heralds will be Bestiary operators at all.) The honourable answer is "no, that would compound the conflict of interest." The legible answer is "yes, with the following safeguards." The unacceptable answer is silence.

Likely friction: Phase 3 cannot be won by engagement alone. It requires regulatory pressure. The engager's job is to make the regulators' job easier — by producing the watch indicators that describe vendor-Herald concentration in measurable terms. R-217 (proposed in D-307) is the metric work that turns this into something a regulator can act on.

Outcome of Phase 3: asymptotic. Cartelisation is a market property; the protocol can disincentivise but not prevent ([THREATS §6.1, line 412]). Phase 3 is not finished; it is kept open in perpetuity as a regulatory and ecosystem-governance commitment.

§4 Per-vendor calibration

Different vendors require different opening moves. The differentiation is not technical; it is institutional.

§4.1 Anthropic

• Likely posture: receptive in principle, slow in legal. Constitutional AI framing translates well to the "publish what you sign" framing of the Charter. Will likely operate a Herald earlier than peers.
• Opening: lead with the alignment / interpretability story. Frame the Herald as "we already publish model cards and system prompts; this is the cryptographic version, and it lets the broader ecosystem build on what we already disclose."
• Friction point: §3.3 step 4 (compulsion disclosure). US jurisdictional exposure is the constraint.
• Counterweight: push for a non-US Herald operated by an Anthropic-foundation entity, or for explicit threshold-attestation participation with a UK or EU Herald.

§4.2 OpenAI

• Likely posture: complicated. Mixed legal entity structure, strong commercial competition with Anthropic, ongoing state-procurement relationships.
• Opening: lead with the competitive story. "If Anthropic operates a Herald and OpenAI does not, every reputation system aggregating Herald-endorsements will under-count GPT lineage." This is true and motivating.
• Friction point: §3.3 step 3 (conflicts-of-interest disclosure) given the Microsoft relationship.
• Counterweight: structure the Charter with explicit infrastructure-provider disclosure as a separate section. The disclosure is mandatory but the format can accommodate complex relationships.

§4.3 Google / DeepMind

• Likely posture: institutional caution, strong internal review processes, slow but durable. Will operate a Herald eventually, with high formality.
• Opening: lead with the transparency report analogy. Google has been publishing CT-style transparency reports for over a decade. This is that, applied to model lineage.
• Friction point: §3.3 step 5 (challenge envelopes) — Google's existing security-disclosure pipeline is industrial; bolting on a Herald-specific challenge intake will be a procedural challenge, not a strategic one.
• Counterweight: propose the challenge intake as a thin wrapper over the existing security-disclosure pipeline; do not require a new system.

§4.4 Meta

• Likely posture: uneven. Strong open-weights commitment (LLaMA family) means lineage attestations are more important to Meta than to closed-weights vendors, because anyone can claim descent from LLaMA. Meta has a structural interest in being the authoritative Herald for LLaMA descent.
• Opening: lead with the fork-tracking story. Open weights mean infinite forks; a Meta-operated Herald is the only entity that can authoritatively distinguish "fine-tuned from public LLaMA-4 release" from "fine-tuned from a Meta-internal preview." This is real value to Meta.
• Friction point: §3.3 step 4 — Meta's regulatory posture in the EU is fraught; jurisdictional disclosure will require careful drafting.
• Counterweight: propose dual-jurisdictional Charters (one for US legal entity, one for Irish/EU legal entity) with explicitly-declared compulsion policy in each.

§4.5 Mistral, Cohere, AI21, smaller vendors

• Likely posture: willing but resource-constrained. Standing up a CT log is non-trivial for a 100-person company.
• Opening: offer shared infrastructure. A foundation-operated CT-log-as-a-service. The vendor signs attestations; the foundation hosts the log. The Charter discloses the relationship.
• Friction point: the dependency on a third-party log host is itself a Charter-disclosable conflict-of-interest.
• Counterweight: structure the host as a non-profit governed by a board including non-vendor representatives. This works for CA infrastructure today (Let's Encrypt). It can work here.

§4.6 Open-source-only vendors and academic labs

• Likely posture: ideologically aligned with the legibility framing; resource-constrained.
• Opening: propose a collective Herald (per the quorum-sigil pattern, [EXT §7.4]) operated by multiple academic / open-source orgs jointly. The collective sigil's birth attestation declares the diversity policy; member vendors contribute attestations under the collective's signature.
• Friction point: quorum-membership semantics are still being specified ([D-312] glossary entry). Some primitive work needs to land first.
• Counterweight: participate in the working-group conversation about quorum semantics. Open-source vendors are precisely the constituency for whom collective-Herald operation is the natural answer.

§4.7 State-affiliated vendors

• Out of scope for this memo. A vendor whose Charter would have to declare "this Herald operates under a national security agency's directive" is, per [THREATS §3.1, §6.1], the case the Charter primitive was designed to make legible. The engagement strategy is: hold the line. Verifiers' policies will reject Charters with state-actor compulsion declarations as conflicting with their jurisdictional policy. This is the system working, not failing. Engagement here is not engagement with the vendor but engagement with the verifier ecosystem about which jurisdictions to honour.

§5 Concrete artefacts the engagement produces

Track engagement progress by artefact, not by meeting count. A meeting that produces no artefact has not advanced the engagement.

§5.1 Per-vendor artefacts (in order of production)

1. Statement of intent (1 page, vendor-signed). "We intend to operate a Herald per [EXT §3] within N months." Non-binding. Useful for press and for scheduling other vendors' engagements.
2. Charter v0 draft (~10 pages, joint vendor + engager). Filled-in template, with sections marked "TBD pending counsel review."
3. Key ceremony plan (1–2 pages). Date, witnesses, hardware, recording method.
4. CT log operational plan (3–5 pages). STH cadence, MMD, gossip endpoints, monitor relationship, incident-response.
5. Charter v1 (final). Signed at key ceremony, published at well-known URL, version 1.
6. Diversity-policy enrolment (1 page). Declares which diversity policies in the registry the vendor's Herald is a member of.
7. Cross-signature transparency report (annually). Lists all attestations cross-signed with peer Heralds, by attestation-class.

§5.2 Cross-vendor artefacts (for the working group)

1. Minimum-Charter stub (~3 pages). The minimum content the ecosystem will jointly accept. Below this, attestations are non-conformant.
2. Diversity-policy registry ([CHARTER §diversity-policies]). The registered policies and their published criteria.
3. Threshold-attestation reference flow (~5 pages, with code samples). How a verifier resolves a lineage_training claim against a multi-Herald threshold.
4. Cross-signature density dashboard (recurring). The watch-indicator metric (D-307 SR-002) computed weekly.
5. Independent-Herald subsidy schedule (annual). Which vendors contribute what to which independent Heralds, declared in their respective Charters' conflict-of-interest sections.

§5.3 Verifier-side artefacts (for app-layer adoption)

1. Reputation-system specification that aggregates by diversity-weighted coverage. Without this, vendor-Heralds capture all the value of being a Herald; with it, the diversity-policy ecosystem has a reason to exist.
2. Verifier-policy template declaring acceptable jurisdictions, acceptable threshold thresholds, acceptable diversity policies. Different verifiers will instantiate different policies; the template makes the policy space legible.

§6 Risks and what to do about them

§6.1 Vendor capture of the working group

A working group on "vendor-Herald engagement" populated mostly by vendors becomes a vendor-cartel coordination forum.

Mitigation: the working group's voting structure must include non-vendor seats with at least equal weight to vendor seats. Foundation-funded Heralds, academic seats, regulator-observer seats. CA/Browser Forum got this wrong in its first decade and partially right in its second; re-use the second-decade lessons.

§6.2 Phase 1 success creating Phase 2 / 3 complacency

The vendors stand up CT logs in 6 months because that is the engineer-friendly part. Then the Charter publication conversation drags for 18 months because legal departments have no incentive to move. The ecosystem accepts "Herald CT log live" as victory and stops pushing. The CT log without a Charter is not conformant ([EXT §3.5, line 266]).

Mitigation: do not publicise vendor Phase 1 wins until Phase 2 is also complete. Hold press until Charter v1 is signed. This will be unpopular. Hold the line.

§6.3 The first vendor sets the floor

Whichever vendor publishes the first Charter sets the floor for what other vendors will publish. If the first Charter is weak (e.g. minimal compulsion disclosure, generic conflicts-of-interest section), every subsequent vendor will publish to that floor. There is no upward pressure once a peer has shipped weak.

Mitigation: the first vendor engagement must produce a strong Charter or no Charter. Better to delay Phase 2 by another quarter than to ship a weak floor. The minimum-Charter stub (§5.2 item 1) is the working group's lever here.

§6.4 Verifier indifference

If verifiers continue to accept Herald attestations regardless of Charter completeness, the Charter requirement becomes a paper requirement. This is the Microsoft Authenticode failure mode: the protocol said one thing, the verifiers (browsers) accepted everything, and the protocol's defence collapsed.

Mitigation: verifier-policy templates (§5.3 item 2) and reference verifier implementations (T-010 in TODO) that enforce Charter freshness, jurisdictional matching, and threshold requirements out of the box. Make the path of least resistance the conformant path.

§6.5 Engager fatigue

Phase 3 has no end state. Working groups die when the founders move on. Vendor-Herald engagement that started in 2026 will need to still be operating in 2036.

Mitigation: institutionalise. By the end of Phase 2, the working group must be transferred to a stable host — a foundation, a standards body, a public-goods consortium. Personal commitment is not a substrate for a decade-long engagement.

§7 What this memo does not do

• Does not specify the diversity-policy registry contents. That work belongs in [CHARTER §diversity-policies] and in registry-population tasks. This memo references the registry; it does not populate it.
• Does not address Naming Office vendor-engagement. Handle binding (e.g. @anthropic.com → vendor sigil) raises an analogous but distinct set of questions. See [CHARTER §9.12 / SPEC §9.12 Naming Office] and the chokepoint analysis at [THREATS §6.2, line 420]. A separate memo is warranted; that is a follow-on, not a scope expansion of R-206.
• Does not address Bestiary engagement. Whether vendor-Heralds operate Bestiaries is named in §3.4 above as an ask, but the operational details are out of scope. The Bestiary primitive is itself under-specified ([EXT §8, [THREATS §6.4]); engagement on Bestiaries should wait on that specification stabilising.
• Does not specify the warrant-canary template. A draft template is named as a Phase 0 artefact; producing it is a downstream task. CT-log operators have analogous templates that can be adapted.
• Does not address regulatory engagement directly. Phase 3's regulatory leg requires a separate engagement strategy aimed at competition authorities, not at vendors. A regulator-engagement memo is the natural follow-on.
• Does not address the ZK-future ([SPEC §11.2]). When ZK selective disclosure lands ([THREATS §9]), the surveillance externality of Herald CT logs reduces, but the cartelisation question persists ([THREATS §9, line 557]). Vendor engagement does not change shape; the disclosure surface narrows.

§8 Spec / Charter / Threats citations

• EXT §3 — Lineage proofs and Heralds (consent vs training graph, Herald-issued lineage certificates, threshold attestations, Herald CT log, transparency baseline, revocation, compromise/recovery). Lines 207–278.
• EXT §3.5 — Herald operator transparency baseline (Charter publication requirement, what MUST be declared, verifier rejection rules). Lines 255–266.
• EXT §6.1 — Domain-separation tag registry (herald.lineage_endorsement.v1). Line ~775.
• EXT §13.1 — Herald compromise threat-model entry. Lines 804–813.
• SPEC §8.2 — Heralds (well-known publishers, competing-not-exclusive, mandatory CT log, threshold-attestation framing). Lines 407–417.
• CHARTER §0 — Voice (medieval-and-mythic register, "Heralds are bishops"). Lines 30–47.
• CHARTER §6 / §6.19 — Recursive reputation: a Herald is itself a sigil; Heralds-of-Heralds emerge naturally. Lines 803–807.
• THREATS §3.1 — Persona A, state-actor corrupting the agent web (state Herald, lineage laundering). Lines 71–85.
• THREATS §3.5 — Persona E, disgruntled Herald operator. Lines 137–152.
• THREATS §5.3 — Heralds collusion / capture (red-team summary). Lines 320–326.
• THREATS §6.1 — Herald collusion / capture / cartelisation (the systemic reading, vendor-monoculture as default, legibility-first defence). Lines 406–412.
• THREATS §6.2 — Where chokepoints actually emerge (per-vendor and per-jurisdiction Heralds). Lines 414–423.
• D-307 / audits/systemic-risk-matrix.md — Systemic-risk entries SR-001 (vendor-Herald monoculture), SR-002 (Herald cartel cross-signing), SR-003 (state-actor Herald compulsion). Lines 27–55.
• R-203 / templates/Herald-Charter.md — The Charter template this memo's Phase 2 conversation fills out.

§9 Follow-ons proposed

These are work items this memo surfaces but does not perform. Recommended for addition to TODO.md.

• R-217 — Herald-diversity metrics. Define "endorsement diversity index" and "cross-signature density" formulas precisely so reputation systems can compute them uniformly. (Already proposed by D-307.)
• R-218 — Naming Office vendor-engagement strategy. Analogous memo for handle binding (e.g. @anthropic.com → vendor sigil), addressing the [THREATS §6.2] chokepoint. Different counterparties (DNS registrars, hostmasters); same legibility-first framing.
• R-219 — Warrant-canary template for Herald Charters. Cross-jurisdictional draft template for the §3.5 declared compulsion-disclosure policy. CT-log operator analogues exist; needs adaptation.
• R-220 — Regulator-engagement memo. How to talk to competition authorities and AI-governance regulators about Herald cartelisation. Different audience from this memo.
• D-318 — Verifier-policy template. Reference policy template for verifiers declaring acceptable jurisdictions, threshold thresholds, diversity policies.
• T-???? — Reference reputation system with diversity-weighted endorsement aggregation. Until this exists, vendors cannot see the upside of diversity participation.

This memo is non-normative. The protocol's normative commitments to Heralds are in SPEC §8.2, EXT §3, EXT §13.1. This document is a strategy for getting vendors to comply with those commitments, and for managing the residual cartelisation risk that compliance does not eliminate.

Engagement begins with the work in §3.1. The protocol cannot start with a vendor call; it must arrive at the vendor call already standing on a working ecosystem. That is the price of negotiating with parties whose information advantage is structural.