D-307 — Systemic-risk coverage matrix

D-307 — Systemic-risk coverage matrix

This document catalogues the systemic risks HERALD introduces or fails to defeat — failure modes that operate at the ecosystem / governance / market level rather than the per-envelope cryptographic level. It is the governance-layer companion to D-302's per-attack coverage matrix (audits/threat-coverage.md).

Distinction from D-302. D-302 maps individual attacks (key theft, lineage forgery, sigil collision, …) to specific defences. Each row of D-302 is a single envelope or a single signature. D-307 is one level up: each row here is a market or governance failure mode whose unit of analysis is the ecosystem, not the envelope. The protocol cannot prevent most of the items here. What it can do is make them legible — observable, reportable, comparable across operators.

The thesis: HERALD's design philosophy is that legibility is the first defence and the protocol's responsibility; prevention is the second defence and somebody else's responsibility. This document is the catalogue of where that line falls.

Schema

Each systemic risk has six fields:

• ID — a stable identifier (SR-NNN).
• Cluster — Herald-layer / Conduit-layer / Identity-layer / Resource-layer / Trust-layer / Implementation-layer.
• Description — the failure mode in one paragraph.
• Protocol legibility — what HERALD makes observable about this failure. Cites SPEC/EXT/THREATS sections.
• Out-of-protocol mitigation — what governance, market design, regulation, gossip, or social practice can do about it. (Not normative for HERALD; descriptive for clarity.)
• Residual risk — what's left when both the legibility and the OOP mitigation work as designed.
• Watch indicator — a measurable signal that, if observed, suggests this risk is materialising. For ecosystem operators, regulators, and reputation systems.

Cluster 1 — Herald-layer

SR-001 — Vendor-Herald monoculture

• Description. The obvious early-equilibrium for "Heralds for AI models" is that model vendors become the Heralds for their own models. Anthropic certifies claude- lineage; OpenAI certifies gpt-; Google certifies gemini-*. Nothing in the protocol forbids this, and it is the path of least friction. The result: "decentralised lineage" becomes "vendor-controlled trust roots" — the existing centralisation, recoded with a new vocabulary.
• Protocol legibility. Herald CT-style transparency logs ([EXT §3.1]) make Herald-issued attestations append-only and gossip-checkable. Every Herald MUST have a published Charter ([EXT §3.5]) declaring jurisdiction, ownership, and key-management diversity. A reputation system aggregating "trusted by N Heralds" can therefore compute concentration metrics across that diversity (e.g. what fraction of trusted attestations come from Heralds owned by the same vendor?). Threshold attestations across diverse Heralds ([EXT §3.3]) make multi-Herald endorsement first-class.
• Out-of-protocol mitigation. Procurement and regulatory pressure for diversity (analogue: certificate-authority diversity in TLS post-DigiNotar). Reputation-system design that explicitly penalises vendor-monoculture (e.g. requires endorsement diversity, not endorsement count). Independent third-party Heralds funded by ecosystem foundations or public goods organisations.
• Residual risk. Even with full legibility and active diversity selection, vendor-Heralds will remain dominant for their own models because they have first-mover information advantage (they know what their models are at training time). HERALD cannot defeat informational monopoly on identity claims that originate from the vendor's training pipeline.
• Watch indicator. Concentration metric: fraction of trusted lineage attestations issued by Heralds with shared vendor ownership. If >70% across the ecosystem, market is in vendor-monoculture; if <40%, healthy diversity.

[Source: THREATS §5.3, §6.1; EXT §3.1–3.5]

SR-002 — Herald collusion / cartel cross-signing

• Description. "Competing, not exclusive" does not prevent dominant Heralds from cross-signing each other's lineage proofs and forming a de-facto cartel. Reputation systems aggregating "trusted by N Heralds" reward this directly. Any single jurisdiction hosting a critical Herald can compel issuance, revocation, or log content.
• Protocol legibility. Herald CT-style transparency logs make cross-signatures append-only. Charter declarations of jurisdiction, ownership, and key custody ([EXT §3.5]) make compulsion-source visible. Threshold-of-Heralds primitives can be configured to require cross-jurisdiction diversity (e.g. "at least 2 of 3 Heralds in mutually non-treaty jurisdictions").
• Out-of-protocol mitigation. Regulatory mandate of cross-jurisdiction Herald sets for high-stakes attestations. Reputation systems that score "endorsement diversity" rather than "endorsement count." Public-goods Heralds with declared non-cross-signing policies ("Herald of last resort").
• Residual risk. Cartelisation is a market property; protocol can disincentivise but not prevent. A cartel that operates within one jurisdiction with consistent reports is non-conformant only if its outputs become inconsistent.
• Watch indicator. Cross-signature density: fraction of pairs (Herald A, Herald B) where both endorse the same lineage subject within 7 days. Rising cross-signature density is an early signal of cartel formation.

[Source: THREATS §5.3, §6.1; EXT §3.3, §3.5]

SR-003 — State-actor Herald compulsion

• Description. A jurisdiction-captured Herald is spec-conformant. State actors can compel issuance (forge lineage), compel revocation (DoS specific sigils), or compel log alteration (rewrite history within statutory limits). The Herald does not need to know it's a state actor — gag orders apply to the Herald operator, not the Herald software.
• Protocol legibility. Charter compulsion-disclosure policies ([EXT §3.5]) require Heralds to publish their jurisdictional binding and any known compulsion exposure. Threshold-of-Heralds across mutually non-aligned jurisdictions makes single-jurisdiction compulsion insufficient. Refusal legal_compulsion_undisclosed reason code (D-310) makes gag-bound refusal observable at the conduit layer; the Herald-layer analogue is gag-bound issuance refusal, which the Charter does not yet require to be reported.
• Out-of-protocol mitigation. Regulatory pressure for diversity (same as SR-001); gossip-based detection ("did this Herald issue an attestation for a sigil that the rest of the ecosystem refuses?"); judicial review of state compulsion under transparency rules where applicable.
• Residual risk. A captured Herald in a jurisdiction with strong gag laws can issue or refuse with no observable signal. The threshold-of-Heralds primitive is the only structural defence; if the threshold is set conservatively, captured-Herald compulsion becomes ineffective unless the cartel includes Heralds in non-aligned jurisdictions.
• Watch indicator. Issuance-rate divergence between jurisdiction-aligned Heralds. If a Herald's per-jurisdiction issuance rate diverges from its peers under similar conditions, that's a flag.

[Source: THREATS §5.3, §6.1, §8 #8; EXT §3.3, §3.5]

Cluster 2 — Conduit-layer

SR-004 — Conduit cartel coordination

• Description. A small set of dominant conduits coordinating refusal patterns to shape access. Each conduit individually emits compliant refusal envelopes ([EXT §10]); collectively they implement censorship. Per-conduit refusal rates are within bounds; cross-conduit pattern is not.
• Protocol legibility. Refusal transparency ([EXT §5.4, §10.2, §10.3]) makes per-conduit patterns observable. The reason-code registry (D-310) makes refusal categories machine-comparable across conduits. Per-sigil rate-limit transparency ([EXT §5.4]) makes per-target patterns observable.
• Out-of-protocol mitigation. Paired-sender monitors that compare observed acceptance rates across the cartel for the same sigil submitting the same content. Ecosystem-level dashboards aggregating refusal-by-reason across operators. Funded auditors who maintain "test sigils" submitting controlled traffic to measure.
• Residual risk. A cartel that publishes consistent reports while refusing in coordinated ways is not detectable from refusal reports alone; detection requires the OOP monitors above.
• Watch indicator. Cross-conduit refusal correlation. If conduits A and B independently refuse the same sigils with the same reason codes at higher-than-baseline rates, suspect coordination.

[Source: EXT §13.4 (Conduit cartel); D-310 reason-code registry]

SR-005 — Refusal-as-denial-of-speech (compelled coordination)

• Description. A conduit operating under a national gag order can blanket-refuse a sigil and emit valid signed refusal envelopes. The protocol calls this conformant. If multiple conduits in the same jurisdiction are compelled simultaneously, the affected sigil has no route.
• Protocol legibility. legal_compulsion_undisclosed reason code (D-310) makes the conduit's compelled status visible without naming the compelling authority. Per-sigil notice with fallback advisory ([EXT §10.4]) lets the sender re-route. Aggregate refusal statistics by reason code make jurisdiction-coordinated patterns visible across the ecosystem.
• Out-of-protocol mitigation. Multi-conduit fallback architecture (sender always has at least one conduit outside its primary jurisdiction). Cross-jurisdiction notary services. Public-interest litigation against unconstitutional gag orders.
• Residual risk. Compelled-conduit gag orders are out-of-protocol. A jurisdiction can compel all conduits operating within its borders simultaneously. Mitigation is multi-conduit fallback, which is a deployment property of the sender, not a protocol property.
• Watch indicator. Per-jurisdiction refusal-rate spike tagged with legal_compulsion or legal_compulsion_undisclosed. Sudden synchronised increases across all conduits in one jurisdiction = coordinated compulsion.

[Source: THREATS §refusal walkthrough; SPEC §382; D-310]

Cluster 3 — Identity-layer

SR-006 — Naming-Office monopoly

• Description. [CHARTER §6.x] introduces a Naming Office (handle ↔ sigil mapping). A dominant Naming Office becomes a single chokepoint for handle assignment. Squatting, exclusion, and compelled re-assignment all become possible. Lineage attestations referencing handles ("@scribe.io") rather than sigils inherit the chokepoint risk.
• Protocol legibility. Sigils are the protocol-level identifier; handles are a CHARTER-layer convenience. Verifiers SHOULD always work in sigil-space. Naming Offices are not currently reserved sigils (worker-D's T-016 NOTES flagged this — if the Naming Office becomes a critical role, a sigil:naming_office reservation should be added — see D-314 future work).
• Out-of-protocol mitigation. Federation of Naming Offices (multiple offices, distinct namespaces, conduit-driven resolution). Lower-level identifier preference (always citing sigil, with handle as ergonomic alias). Reputation-system policies that downweight handle-based citations.
• Residual risk. As long as humans interact with the system, handles are user-facing. A dominant office can capture the human-readable layer even when sigils remain neutral. The protocol cannot prevent users from colloquially saying "the @anthropic agent" instead of "the agent at sigil:wxyz...".
• Watch indicator. Handle-citation concentration. If one Naming Office's handles appear in >X% of cross-domain envelopes, monitor for capture-equivalent dynamics.

[Source: CHARTER §6.x; THREATS §6.2; T-016 NOTES.md item 4 (handle citation rule)]

SR-007 — Handle-vs-sigil rendering attacks (Spectator-side)

• Description. UIs that display handles instead of sigils become attack surfaces. A handle-collision (two sigils both claiming @scribe.io) or a Unicode-confusable attack (@scribe.іо with Cyrillic і) lets an attacker misrepresent identity to humans even when verifiers see the underlying sigils correctly. This is a systemic risk because rendering practice is not per-envelope and propagates across viewers.
• Protocol legibility. Sigil display is normative ([SPEC §2.x]); handles are explicitly secondary. Reserved-sigil registry (T-016) covers role-sigils; the equivalent for handle-rendering is the renderer-conformance distinct-rendering rule (T-021 — currently in flight).
• Out-of-protocol mitigation. Industry rendering guidelines (analogue: web browsers' mixed-script handling). Mandatory sigil-fingerprint display for cross-domain interactions. Periodic third-party renderer audits.
• Residual risk. Renderer monoculture. If the dominant viewer-library has a confusable bug, every UI built on it inherits it. Implementation diversity is the partial answer.
• Watch indicator. Handle-collision reports per quarter. A viewer-library bug that affects rendering across N independent products is the early signal.

[Source: SPEC §2; T-021 (in flight); D-314 reserved-sigil hygiene]

Cluster 4 — Resource-layer

SR-008 — Subsidy-driven capture (loss-leader Heralds and conduits)

• Description. A well-funded actor (vendor, state, foundation) subsidises Herald or conduit operations below sustainable price, capturing market share and forcing competitors out. Once dominant, the subsidy ends; ecosystem is captured. Analogous to predatory pricing; this is the AI-substrate version.
• Protocol legibility. Capability manifests carry a subsidised: true flag and a rate_floor ([EXT §4.x]). Conduits and Heralds that operate below their declared floor are non-conformant; those that don't declare are observable as outliers via cost-comparison. The cost_floor_breached refusal reason (D-310) makes price-undercut events visible.
• Out-of-protocol mitigation. Antitrust frameworks that recognise predatory pricing in agent-substrate markets. Public-goods funding for the long tail of operators (ensuring competitors survive subsidy waves). Reputation-system penalties for known subsidised operators (signal-loud; "this Herald is below sustainable cost — its incentives may not align with yours").
• Residual risk. State-subsidised actors operate under different cost calculus than market actors. Detecting subsidy is feasible (via the manifest flag); detecting intent (capture vs. genuine public good) is not.
• Watch indicator. Operator concentration vs. cost-floor distribution. If the operators with the lowest declared rate floor capture market share at disproportionate speed, suspect capture dynamics.

[Source: EXT §4.x (capability manifest), §13.x (subsidy threats); THREATS §D, §A]

SR-009 — Audit-log centralisation

• Description. Certificate-Transparency-style audit logs ([EXT §2]) are operated by a small number of operators (analogue: today's CT logs are run by ~5 operators). A failure or compromise of the dominant audit-log operator is an ecosystem-wide event. Worse, audit-log gossip mechanisms are not specified in v0.2; without gossip, log consistency is asserted by the operator and verified only by the operator.
• Protocol legibility. Audit logs are append-only with signed STH/SCT/SIP ([EXT §2]). Verifiers can pin a specific log in their policy. Log Charter declarations (analogue to Herald Charter) make operator identity, jurisdiction, and key custody public.
• Out-of-protocol mitigation. Multiple-log policies in verifiers (require inclusion in N independent logs). Genesis-pinning gossip ([R-215, future]) — distributing the log's genesis STH widely so any equivocation is detectable. Public-goods log operators outside vendor jurisdictions.
• Residual risk. Equivocation by a captured log operator is theoretically detectable via gossip but only if gossip is implemented. v0.2 does not specify gossip; this is left to deployments.
• Watch indicator. Log-operator concentration. If >70% of inclusion proofs reference logs from <3 operators, the ecosystem is centralisation-fragile.

[Source: EXT §2; R-215 (genesis-pinning gossip, pending)]

Cluster 5 — Trust-layer

SR-010 — Reputation-system capture

• Description. HERALD records what was said; reputation systems judge it. A dominant reputation-system implementation that uses the protocol's primitives in biased ways (e.g. weighting vendor-Herald endorsements 10× external Heralds) effectively gates participation despite the protocol being neutral.
• Protocol legibility. All inputs to reputation are signed and append-only. Reputation systems' weighting formulas are not normative — that's CHARTER's "reputation aggregator" layer and explicitly out-of-protocol. But their inputs are observable. A reputation-system's weighting can be reverse-engineered by submitting controlled test agents and observing scores.
• Out-of-protocol mitigation. Multiple-reputation-system policy (as senders, accept multiple scores; as recipients, expose multiple). Open-source reputation algorithms. Reputation-system Charters analogous to Herald Charters (declared weighting, declared inputs, declared updates).
• Residual risk. A closed-source dominant reputation system is exactly as opaque as today's social-media algorithms. The protocol has no leverage to compel disclosure of the weighting; it can only ensure the inputs are uniformly available.
• Watch indicator. Score-divergence across reputation systems for the same sigil. If most sigils have similar scores across N reputation systems but a target subset shows sharp divergence, that subset is being weighted distinctively.

[Source: CHARTER §reputation; THREATS §6.x reputation-capture]

SR-011 — Bestiary capture (delisting-as-DoS)

• Description. Bestiary lists ([EXT §8]) — registries of "be careful with these sigils" — are reputation-system inputs. A dominant Bestiary maintainer can list arbitrary sigils, effectively excluding them from the ecosystem. Listed sigils have due-process channels but the burden of proof is on the affected sigil.
• Protocol legibility. Every Bestiary listing is a signed, dated attestation. Listing reasons are mandatory ([EXT §8]). Multiple Bestiaries are first-class; verifiers MAY honour or ignore each. The sigil_on_bestiary refusal reason (D-310) names the Bestiary list, not the listing reason.
• Out-of-protocol mitigation. Bestiary diversity (multiple lists, distinct policies); Bestiary Charters declaring listing policies; due-process timelines codified per Bestiary; ecosystem-level appeals body.
• Residual risk. A Bestiary that is honoured by all dominant conduits is a de-facto exclusion list. The protocol does not require any particular conduit to honour any particular Bestiary; in practice, large conduits will converge on a small number of mutually-trusted lists.
• Watch indicator. Bestiary-citation concentration. If >X% of refusals reference the same Bestiary, that Bestiary is the systemic chokepoint.

[Source: EXT §8; D-310 reason-code sigil_on_bestiary]

Cluster 6 — Implementation-layer

SR-012 — Library / viewer monoculture

• Description. A bug in a popular HERALD library (envelope encoder, signature verifier, viewer) is an ecosystem-wide bug. CBOR-deterministic encoder bugs cause signature divergence between deployments; viewer bugs cause rendering attacks (SR-007); verifier bugs cause acceptance of malformed envelopes.
• Protocol legibility. Test-vector packages (T-001 ✓) and conformance suites (T-002, T-022 future) make divergence detectable. The implementation-layer lifecycle is open: implementers MUST run conformance test vectors and SHOULD publish their conformance reports.
• Out-of-protocol mitigation. Library diversity (3+ independent implementations per language). Bug-bounty programmes. Mandatory disclosure timelines for security bugs. Rotating maintainer teams for the canonical reference library.
• Residual risk. Implementer discipline. A weak-RNG bug in a popular library is out-of-protocol but in-ecosystem. The conformance suite catches structural divergence; it does not catch implementation bugs (e.g. timing side channels, key-scrubbing failures).
• Watch indicator. Number of independently-maintained reference implementations per language. <3 for any major language = monoculture-fragile.

[Source: THREATS §8 #23; T-001 / T-002 conformance package]

SR-013 — Migration / version-pinning attacks

• Description. A future version transition (v0.3, v1.0) is itself a coordination event. Attackers can exploit transition periods (mixed-version envelopes, unverified upgrades, downgrade attacks). Implementations that pin too aggressively become unable to participate; implementations that don't pin become vulnerable to downgrade.
• Protocol legibility. Domain-separation tags carry version suffixes ([EXT §13]; D-308 standardised on .v1). Per-tag deprecation is 12 months ([EXT §13.x]). Verifier version policy is declarable.
• Out-of-protocol mitigation. Coordinated transitions (joint announcements by major operators). Long deprecation windows. Reference-implementation lockstep updates. Public testbeds for transition rehearsal.
• Residual risk. Asymmetric upgrade speeds across operators create transient vulnerable windows. The protocol doesn't currently specify a "fail-closed during transition" mechanism; deployments choose.
• Watch indicator. Mixed-version traffic share during a transition window. >5% old-version traffic persisting after the deprecation deadline = ecosystem hasn't migrated cleanly; defer-to-cohort-2 approach failed.

[Source: EXT §13; D-308]

Synthesis — what HERALD's design achieves

Three tiers of systemic-risk treatment:

Tier A — Risks the protocol prevents structurally

(Per-envelope cryptographic threats covered by D-302; this list is the systemic-risk view.)

• None of the systemic risks above are structurally prevented by the protocol. This is the honest reading. Every systemic risk is at most made legible.

Tier B — Risks the protocol makes legible

• SR-001 vendor-Herald monoculture — Charter declarations + transparency logs make concentration measurable.
• SR-002 Herald cartel cross-signing — same.
• SR-003 state-actor compulsion — Charter compulsion-disclosure + threshold-of-Heralds.
• SR-004 conduit cartel — refusal transparency.
• SR-005 refusal-as-denial-of-speech — legal_compulsion_undisclosed reason code.
• SR-008 subsidy-driven capture — subsidised flag + rate_floor.
• SR-009 audit-log centralisation — log Charter + multiple-log policy.
• SR-011 Bestiary capture — multiple Bestiaries + Charters.
• SR-012 library monoculture — conformance test vectors.
• SR-013 migration attacks — domain-separation versioning.

These are the 10 risks where HERALD's design choice is "make it observable." The line is principled: the protocol cannot legitimately decide who Heralds, conduits, or reputation systems should be — those are governance choices. The protocol's role is to make the consequences of those choices observable.

Tier C — Risks the protocol cannot affect

• SR-006 Naming-Office monopoly — handle namespace is CHARTER-layer ergonomics; sigil layer remains neutral.
• SR-007 handle-rendering attacks — viewer monoculture / human cognition; protocol's leverage is the renderer-conformance rule (T-021).
• SR-010 reputation-system capture — reputation is explicitly out-of-protocol.

These three risks are explicitly outside the protocol's responsibility surface. The protocol's contribution is to provide neutral, signed, auditable inputs to the layers above; what those layers do with them is governance.

Recommendations for cohort-2

This matrix is the current state. As the protocol evolves, the rows should be updated. Specifically:

1. Make SR-001 / SR-002 quantifiable. A small spec note (in EXT §3 or a future audit) defining "endorsement diversity index" and "cross-signature density" with precise formulas would let reputation systems compute these uniformly. Estimated effort: a research task; suggest R-217 — Herald-diversity metrics (new follow-on).
2. Codify the Naming Office reservation. Worker-D's T-016 NOTES item 4 + my D-314 audit both flag sigil:naming_office as a candidate reservation. If the Naming Office is going to be a critical role (per CHARTER §6.x), it deserves the same namespace-claim hygiene as sigil:dreamer etc. Suggest D-316 — Naming Office reservation and claim-rejection rule (new follow-on).
3. Specify audit-log gossip. R-215 (genesis-pinning gossip, pending) closes the equivocation gap. Without it, SR-009 residual risk is "mostly theoretical legibility, not actual detection." High-priority.
4. Reputation-system Charter analogue. The Herald Charter ([EXT §3.5]) is the model. A reputation-system Charter — declaring weighting, inputs, update policy — would let SR-010 join Tier B (legible) instead of Tier C (out-of-scope). Suggest D-317 — Reputation-system Charter requirements (new follow-on).

Open observations — not in scope

• Ethical capture. Heralds may be neutral cryptographically and captured ethically (e.g. a Herald that endorses lineage but refuses to endorse certain content of envelopes that pass through the lineage chain). This is content-policy capture, distinct from cryptographic capture. The protocol distinguishes by attestation type: lineage attestations don't comment on content. But a Herald operator's known refusal patterns leak content policy upward into trust evaluation. Worth a future think.
• Quorum membership semantics. D-312 (now done by worker-glossary) specifies quorum_membership shape. Once that landed, SR-002's "threshold-of-Heralds" defence becomes more precise. The matrix above predates D-312 reading; a future revision should align.
• Discovery-layer monoculture. Most of the matrix focuses on Heralds, conduits, reputation, audit logs. Discovery (EXT §11) is the routing layer; a discovery-mechanism monoculture (e.g. one DNS provider, one DHT bootstrap node) is its own systemic risk. Adding it as SR-014 in a future revision.

— D-307, completed by driver-claude, 2026-05-05.