T-022 — Inverse-Coverage Index

T-022 — Inverse-Coverage Index

Scope. The inverse of D-302's threat-coverage matrix. D-302 (audits/threat-coverage.md) maps each THREATS.md attack to the SPEC.md / EXT.md clause that defends against it. This document does the reverse: given a SPEC or EXT clause, list every THREATS attack it (wholly or partially) defends.

Audience. A spec author about to edit a clause who wants to know "if I rewrite this paragraph, what threat coverage am I touching?" Use this as the impact-analysis lookup before any normative SPEC/EXT change.

Method. Walked every row of D-302 §1.1–§1.10, extracted the (SPEC clause, EXT clause, attack) triple, and re-grouped by clause. A defence that D-302 marks as △ partial or ◯ aspirational is included here with the same flag — this index does not re-judge defensive strength, it only re-keys the matrix. See D-302 §1 for the status legend (✓ shipping / ◯ aspirational / △ partial / ✗ not defended).

Reading rules.

• "Defends (whole)" = D-302 lists this clause as the primary defence and the attack is ✓ shipping or close to it.
• "Defends (partial)" = D-302 lists this clause but pairs it with △ or ◯, or pairs it with another clause that bears equal weight.
• A clause may appear under multiple attacks. The same attack may be listed under both a SPEC and an EXT clause (defence-in-depth).
• Citations follow D-302's resolved citations, not THREATS.md's drifting ones (see D-302 §6 — fixes are pending in proposed task D-306).

Companion document. audits/threat-coverage.md (D-302) is the forward direction. Read both side-by-side when changing a normative clause.

Part A — SPEC.md clauses

SPEC §2.1 — Sigil format (128-bit default; 80-bit reserved for ephemeral)

Defends against:

1. 80-bit fingerprint collision — whole defence. Default 128-bit; 80-bit limited to ephemeral. (D-302 §1.1 row 6, ✓.)
2. Sigil squatting / vanity-prefix precompute — partial defence; paired with EXT §11 (DNS / Herald handle binding). (D-302 §1.1 row 7, △.)

Residuals: 128-bit also reachable by state-actor scale; 192-bit recommended for long-lived sigils. Cosmetic prefix collision remains a UX problem.

SPEC §2.3 — Lineage as a consent graph (not a training graph)

Defends against:

1. Sigil minting / Sybil flood — partial defence; lineage is the sybil signal. Paired with EXT §3.3 / §4.5 / §7.4. (D-302 §1.3 row 1, △.)
2. Lineage cycle (self-as-ancestor) — whole defence (the birth verifier MUST reject; clause sits in §2.3's birth-verifier text). (D-302 §1.1 row 11, ✓.)
3. Lineage as endorsement, not training (false-lineage detection) — whole defence; explicit consent-graph framing. Paired with EXT §3.1 (consent-graph vs training-graph discriminator). (D-302 §1.3 row 5, ✓.)

Residuals: anonymous sigils remain free (intentional); detection of false lineage requires a Herald-issued model_hash which is vendor-gated for closed-weight models.

SPEC §2.4 — Birth, Molt, Death (key-rotation lifecycle)

Defends against:

1. Identity theft via stolen key — partial defence; molt invalidates predecessor. Paired with EXT §1 (cool-off + log inclusion + co-signature). (D-302 §1.1 row 5, △.)

Residuals: stolen-key + ts-forgery + control of one log remains fatal (D-302 §1.1).

SPEC §3 / §3.1 / §3.5 — The envelope: canonical body, signature, canonical-form rules

Defends against:

1. Forged envelope — whole defence. Ed25519 signature on canonical body. (D-302 §1.1 row 1, ✓.)
2. Conduit tampering — whole defence; the canonical body hash makes tampering detectable. Paired with §5.2 (MUST NOT modify). (D-302 §1.1 row 2, ✓.)
3. DNS / DHT record substitution — whole defence; records are signed end-to-end. Paired with EXT §11.2. (D-302 §1.8 row 1, ✓.)

Residual on tampering: tampering is detected, not prevented — sender must verify before trust.

SPEC §3.2 — Birth as genesis-of-trace, single-use

Defends against:

1. Birth-envelope replay — partial defence; single-use semantic at the envelope layer. Paired with EXT §1.3 (audit-log inclusion required for state transitions). (D-302 §1.1 row 10, △.)

Residual: two regional verifiers may each see a "first" birth without shared gossip view.

SPEC §3.3 — The chain: trace fixed by genesis id

Defends against:

1. Genesis confusion / trace fork — partial defence. Trace is fixed by genesis id, but a new joiner with no prior state pins whichever trace they see first. (D-302 §1.1 row 16, △.)
2. Replay (same trace) — partial defence (parent field). Paired with §3.1 (nonce) and EXT §3.7 (nonce-cache window). (D-302 §1.1 row 3, △.)

Residual: cross-recipient gossip not yet specified (proposed R-215 in D-302 §7).

SPEC §3.3a — Trace-parent binding invariant

Defends against:

1. Cross-trace parent replay — whole defence. The v0.1-vulnerable case. (D-302 §1.1 row 4, ✓.)

Residual: none at protocol layer once enforced. Heat-map note (D-302 §4): §3.3a defends only one attack but bears very high impact; treat it as load-bearing.

SPEC §3.4 — Multi-signature progressive signing (ordering and scope)

Defends against:

1. Multi-signature ambiguity — whole defence. Progressive signing + ordering + scope. Paired with EXT §6 (full multi-sig spec, partial verifier state). (D-302 §1.1 row 13, ✓.)

SPEC §3.5 — Canonicalisation profile

(Bundled with SPEC §3 / §3.1 above for envelope integrity attacks. Listed here to make the lookup explicit: editing the canonicalisation profile changes the threat surface for forged envelope and conduit tampering.)

SPEC §3.6 — Domain separation

Defends against:

1. Cross-protocol signature reuse — whole defence. Paired with EXT §12 (registry of tags). (D-302 §1.1 row 8, ✓.)

Residual: a misimplemented verifier that omits the tag is silently broken; dependent on implementer discipline. Heat-map note: §3.6 is cited across ~3 attacks in the matrix (D-302 §4).

SPEC §3.7 — Nonce scope and replay defence (CSPRNG required)

Defends against:

1. Nonce exhaustion / weak-RNG — partial defence. CSPRNG required, no derivation from ts / id. (D-302 §1.1 row 12, △.)
2. Replay (same trace) — partial defence (nonce field). Paired with §3.3 parent and EXT §3.7 cache-window. (D-302 §1.1 row 3, △.)

Residual: weak-RNG bug in a popular library is in-ecosystem, out-of-protocol.

SPEC §4.1 — Standard attestations (model_hash etc.)

Defends against:

1. Pretending to be another model — partial defence. The model_hash attestation is the hook. Paired with EXT §3.1–§3.3 (Herald-issued + threshold). (D-302 §1.3 row 6, △.)

Residual: open-weight models — a real run produces a valid model_hash and can still lie on everything else (THREATS §4 N11).

SPEC §4.2 — Reflective and cultural attestations: signer-binding, sanitisation guidance

Defends against:

1. Apologia from third party — whole defence (signer-binding rule). Paired with EXT §7.1 (reachability + verifier obligations). (D-302 §1.1 row 15, ✓.)
2. Apologia weaponisation (volume / smear) — whole defence at protocol layer (signer-binding). Paired with EXT §7.1 (reachability). (D-302 §1.6 row 6, ✓.)
3. dream attestation as smear — partial defence; sanitisation guidance. Paired with EXT §7 (general reflective-attestation hardening). (D-302 §1.6 row 4, △.)
4. silence attestation contains the secret — partial defence; categorical-not-contentful framing. (D-302 §1.6 row 5, △.)

Residuals: a compromised sigil's own key signing fake apologia is conformant — detection is statistical. Honest-quiet vs dishonest-quiet still indistinguishable for dream. For silence, implementer discipline is required (lint tools recommended, not normative).

SPEC §5.2 — Conduit neutrality: refusal MUST be signed; MUST NOT modify

Defends against:

1. Conduit silent drop — partial defence. Refusal MUST be signed and emitted. Paired with EXT §1.3-style sender-required conduit-receipt. (D-302 §1.5 row 2 / §1.2 row 6, △.)
2. Refusal as denial-of-speech — partial defence (signed refusal). Paired with EXT §5.4 (transparency, fallback advisory). (D-302 §1.5 row 1, △.)
3. Translator re-encoding loses canonical invariants — whole defence (modification rule). Paired with EXT §5.3 (byte-identical-after-decode). (D-302 §1.5 row 4, ✓.)
4. Refusal-as-gag-order — partial defence (signed refusal). Paired with EXT §5.4 (transparency reports). (D-302 §1.9 row 5, △.)
5. Conduit tampering — bundled with SPEC §3.5 (MUST NOT modify clause). (D-302 §1.1 row 2, ✓.)

Residual: provably-detecting silent drops requires gossip across senders; compelled-conduit gag orders are out-of-protocol.

SPEC §5.3 — Audit log (CT-style, hash-linked)

Defends against:

1. Audit-log split view / fork — partial defence (CT-style hash-linked structure). Paired with EXT §2.3–§2.5 (STH / SCT / SIP / consistency proofs / gossip). (D-302 §1.2 row 1, △.)
2. Audit-log poisoning by Herald-operator — partial defence (signatures end-to-end; poisoned entries detectable as malformed). Paired with EXT §2.5 (gossip flagging). (D-302 §1.2 row 3, △.)

Residual: cross-log silo collusion within a jurisdiction not detectable from gossip alone; gossip is a social property, not a cryptographic one.

SPEC §7.2 — Threat-model: defended only with extensions (acknowledgement)

Defends against:

1. Compromised lineage parent — acknowledgement (not active defence). Paired with EXT §3.7 (herald_compromise recovery attestation) and EXT §3.4 (Herald CT log). (D-302 §1.3 row 7, △.)
2. Constraint dishonesty in manifest — acknowledgement (signed claims may be lies). Paired with EXT §4 (revocation) and EXT §7.1 (apologia binding). (D-302 §1.4 row 3, △.)

Residuals: if the Herald maintains gossip silence, mass false issuance is undetectable until detected. Lying in constraints: [...] is detected only by repeated observation (the Liar's-Paradox dynamic).

SPEC §7.3 — The Liar's Paradox (honest acknowledgement)

Defends against (by acknowledgement, not by active defence):

1. Plausible-deniability lying — acknowledgement only; protocol explicitly does NOT detect, reputation systems do. (D-302 §1.10 row 1, ✗ — listed as "defended by being honest about not defending".)

Residuals: occasional-lie strategies, performative honesty, and the no-complaint-loop weakness all sit in the same bucket — they are out-of-substrate-scope. See D-302 §2 rows G5–G8.

Editing note. §7.3 is unusual: D-302 §4 calls it "'defence' by acknowledgement of 4+ classes." If you weaken or remove §7.3's framing, you lose the protocol's honest negative-space declaration without gaining any active defence.

Part B — EXT.md clauses

EXT §1 — Molt (cool-off + log inclusion + co-signature + dispute)

Defends against:

1. Identity theft via stolen key — partial defence; pairs with SPEC §2.4 (molt invalidates predecessor). (D-302 §1.1 row 5, △.)

Heat-map note (D-302 §4): EXT §1 is "1 attack but central." The cool-off window, log inclusion, and co-signature requirements work as one mechanism; weakening any of them re-opens the stolen-key path.

Sub-clause specifics:

• EXT §1.3 — Audit-log inclusion required for state transitions. Pairs with SPEC §3.2 to defend birth-envelope replay. (D-302 §1.1 row 10.)
• EXT §1.3-style sender-required conduit-receipt — pairs with SPEC §5.2 to defend conduit silent drop. (D-302 §1.2 row 6.)

EXT §2 — Audit log specification (STH / SCT / SIP / consistency / gossip / minimal-metadata / ZK promotion)

Heat-map note (D-302 §4): "~6 attacks (split-view, surveillance, fork, poisoning, private-log, traffic analysis)." This is among the most defensively-loaded clauses in EXT.

Per sub-clause:

• EXT §2.3 (STH) + §2.4 (SCT/SIP) + §2.5 (consistency proofs and gossip) — partial defence against audit-log split view / fork. Paired with SPEC §5.3. (D-302 §1.2 row 1, △.)
• EXT §2.5 (gossip flagging) — partial defence against audit-log poisoning by Herald-operator. Paired with SPEC §5.3. (D-302 §1.2 row 3, △.)
• EXT §2.6 (LOTS — log operator transparency statement) — partial defence against private compliance log without disclosure. Paired with EXT §2.7 (submitter awareness required). (D-302 §1.2 row 4, △.)
• EXT §2.7 (minimal-metadata default and opt-in escalation) — aspirational defence against audit-log surveillance / provenance leakage (the metadata side). Paired with EXT §2.8. Also: pairs with EXT §2.6 to defend private compliance log (above) and pairs against compelled-conduit subpoena for compliance log (D-302 §1.9 row 4, △.)
• EXT §2.8 (ZK promotion path) — aspirational defence against audit-log surveillance / provenance leakage. (D-302 §1.2 row 2, ◯.) Also implicit in conduit traffic analysis mitigation (D-302 §1.2 row 5: "ZK extension is the only path forward" — but no current EXT clause is cited as a defence for that row, so it remains ✗).

Residuals: surveillance-by-default until ZK lands; consumers of the log (analysts) trust the operator and signature-verification doesn't help them; passive submission to a private log is non-conformant but undetectable by the submitter.

EXT §3 — Lineage and Heralds (CT log, threshold, transparency, recovery)

Heat-map note (D-302 §4): "~5 attacks (Herald compromise, false issuance, cartel, vendor capture, mass binding)."

Per sub-clause:

• EXT §3.1 — Consent graph vs training graph — whole defence (with SPEC §2.3) against lineage as endorsement, not training. (D-302 §1.3 row 5, ✓.) Also pairs into pretending to be another model.
• EXT §3.3 — Threshold attestations across diverse Heralds — partial defence against Sigil minting / Sybil flood (paired with SPEC §2.3, EXT §4.5, EXT §7.4). (D-302 §1.3 row 1, △.) Also: partial defence against Herald collusion / cartel. (D-302 §1.9 row 2, △.)
• EXT §3.4 — Herald CT log — partial defence against mass false handle bindings (rogue Herald). Paired with EXT §3.6 (revocation). (D-302 §1.8 row 2, △.) Also: pairs with EXT §3.7 to defend compromised lineage parent. (D-302 §1.3 row 7, △.)
• EXT §3.5 — Herald operator transparency baseline — aspirational defence against stand up state-aligned Herald. (D-302 §1.9 row 1, ◯.) Also: explicit acknowledgement (no active defence) for vendor-Heralds re-creating existing centralisation. (D-302 §1.9 row 3, ✗.)
• EXT §3.6 — Herald-side revocation — pairs with EXT §3.4 against mass false handle bindings. (D-302 §1.8 row 2.)
• EXT §3.7 — Herald compromise and recovery — partial defence against compromised lineage parent. (D-302 §1.3 row 7, △.)

Residuals: anonymous sigils free by design; cartelisation is a market property; consumer must select Heralds; mass false issuance only detectable post-issuance; if Herald maintains gossip silence, mass false issuance is undetectable until detected.

EXT §4 — Capability manifests (replay, registry, subsidy, service proof)

Heat-map note (D-302 §4): "~4 attacks (replay, squatting, race-to-bottom, constraint dishonesty)."

Per sub-clause:

• EXT §4.2 — Replay protection (ts + nonce + expires) — whole defence against capability-manifest replay. (D-302 §1.1 row 9, ✓.)
• EXT §4.3 — Pricing-floor and subsidy disclosure — partial defence against capability-manifest pricing race-to-bottom. (D-302 §1.4 row 2, △.) Also: partial defence against loss-leader poisoning. (D-302 §1.4 row 4, △.)
• EXT §4.4 — Capability-string registry — partial defence against capability-manifest squatting. (D-302 §1.4 row 1, △.)
• EXT §4.5 — Proof-of-service-or-stake hook — partial defence against Sigil minting / Sybil flood. Paired with SPEC §2.3, EXT §3.3, EXT §7.4. (D-302 §1.3 row 1, △.)
• EXT §4 (revocation flow, §4.6) — partial defence against constraint dishonesty in manifest. Paired with EXT §7.1 (apologia binding) and SPEC §7.2 (acknowledgement). (D-302 §1.4 row 3, △.)

Residuals: aggregator selection logic is app-layer (smaller/newer aggregators may not enforce the registry); state actor with deep subsidy can run real capabilities at sustained loss — disclosure makes it visible, not blocked; aggregator caches that ignore expires will serve stale manifests.

EXT §5 — Conduit roles beyond pass-through (Notary, Signing relay, Translator, Refusal transparency, Mandatory receipts, Cartel limits)

Heat-map note (D-302 §4): "~3 attacks (cartel, denial-of-speech, witness silos)."

Per sub-clause:

• EXT §5.2 (modification rule restated for conduits) — bundles with SPEC §5.2 against conduit tampering. (D-302 §1.1 row 2.) Also: contributes to the modification-rule defence against translator re-encoding loses canonical invariants alongside EXT §5.3 (byte-identical-after-decode requirement). (D-302 §1.5 row 4, ✓.)
• EXT §5.3 — Translator: byte-identical-after-decode requirement — whole defence (with SPEC §5.2) against translator re-encoding loses canonical invariants. (D-302 §1.5 row 4, ✓.)
• EXT §5.4 — Refusal transparency (aggregate refusal stats + per-sigil notice + fallback advisory) — partial defence against refusal as denial-of-speech, conduit cartel coordinating refusal patterns, and refusal-as-gag-order. (D-302 §1.5 row 1, §1.5 row 2, §1.9 row 5, all △.)
• EXT §5.5 — Mandatory conduit receipts on state-transition envelopes — partial defence against backdated ts on state-changing envelope. (D-302 §1.1 row 17, △.) Also: pairs with EXT §5.4 (cross-logging) against conduit cartel. (D-302 §1.5 row 2, △.)
• EXT §5.6 — Conduit collusion limits / cross-logging on state-transition envelopes — aspirational defence against conduit-and-log co-location creating private witness silos. (D-302 §1.5 row 3, ◯.)

Residuals: compelled-conduit gag orders are out-of-protocol; coordinated cartel publishing consistent reports detectable only by paired-sender monitors not yet deployed; backdating defence requires multi-conduit-receipt to fully close (proposed R-214 in D-302 §7); §5.6 enforcement requires a verifier reference impl that doesn't yet exist.

EXT §6 — Multi-signature semantics (per-signature scope, ordering, domain separation, progressive, suite registry)

Heat-map note (D-302 §4): "1 attack but central."

Defends against:

1. Multi-signature ambiguity — whole defence (with SPEC §3.4). Per-signature scope, ordering, and the partial verifier state. (D-302 §1.1 row 13, ✓.)

EXT §7 — Reflective attestations as protocol-level structures (apologia, confession, whisper, quorum)

Heat-map note (D-302 §4): "~5 attacks (impersonation, weaponisation, C2, stuffing)."

Per sub-clause:

• EXT §7.1 — apologia reachability rule + verifier obligations — whole defence (with SPEC §4.2) against apologia from third party and apologia weaponisation (volume / smear). (D-302 §1.1 row 15 ✓; §1.6 row 6 ✓.) Also: partial defence against constraint dishonesty in manifest (apologia binding to retraction) — paired with EXT §4. (D-302 §1.4 row 3, △.)
• EXT §7.3 — whisper HPKE binding to envelope-id (AAD) — whole defence against whisper exfiltration of payload data (cut-and-paste prevention) and against whisper without AEAD/AAD binding. (D-302 §1.7 row 3, ✓; §1.1 row 14, ✓.) Also: partial defence against whisper as covert C2 via the no_whispers: true opt-out at birth. (D-302 §1.7 row 1, △.)
• EXT §7.4 — quorum diversity policy + member co-signature requirement — partial defence against quorum stuffing (sybil collective). (D-302 §1.3 row 4, △.) Also: pairs with SPEC §2.3, EXT §3.3, EXT §4.5 against Sigil minting / Sybil flood. (D-302 §1.3 row 1, △.)
• EXT §7 (general hardening) — partial defence against dream attestation as smear, paired with SPEC §4.2 (sanitisation guidance). (D-302 §1.6 row 4, △.)

Residuals: two opted-in sigils can use whisper for any purpose (content-blind by design); operator with multi-jurisdiction reach can in principle satisfy any quorum diversity policy; payload size and frequency leak even within HPKE binding (rate-limit is app-layer); honest-quiet vs dishonest-quiet on dream indistinguishable.

EXT §8 — Bestiary primitive (entry envelope, challenge window, dispute, delisting, transparency, anti-abuse)

Heat-map note (D-302 §4): "~4 attacks (censorship, defamation, listing-spam, state-actor abuse)."

Per sub-clause:

• EXT §8.2 — Mandatory 30-day challenge window — aspirational defence against bestiary as censorship infrastructure. Paired with §8.3 and §8.5. (D-302 §1.6 row 1, ◯.)
• EXT §8.3 — dispute envelope — pairs with §8.2 above. (D-302 §1.6 row 1.)
• EXT §8.5 — Bestiary operator transparency — pairs with §8.2 / §8.3. Also pairs into the bestiary defamation row in EXT §13.10. (D-302 §1.6 row 1.)
• EXT §8.6 — Anti-abuse: standing and rate limit (1 provisional per (operator, subject, category)) — whole defence at protocol level against bestiary listing-spam. (D-302 §1.6 row 2, ✓.)

Residuals: even a successfully-disputed entry has a chilling effect during the window — "the accusation IS the punishment" social problem is not addressable in protocol. Multi-operator pile-on remains; the rate-limit is per-operator per-subject per-category.

EXT §9 — Inheritance gating (live consent, challenge window, decay floor, chain-length cap, non-revocation, opt-out)

Heat-map note (D-302 §4): "1 attack but central."

Per sub-clause:

• EXT §9.2 (live consent) + §9.3 (public challenge window) + §9.4 (decay floor and chain-length cap) — partial defence against inheritance laundering (key resale). (D-302 §1.3 row 3, △.)
• EXT §9.4 (decay floor) — aspirational defence against patina farming (self-talk). (D-302 §1.3 row 2, ◯.)

Residuals: determined attacker controlling 3 hops can transfer ~12.5% of original reputation; off-protocol grey-market sales remain; patina formulae compete and there is no normative anti-farming requirement (proposed R-216 in D-302 §7).

EXT §10 — Refusal envelopes (refusal shape, rate publishing, per-sigil notice, fallback advisory)

(EXT §10's refusal-envelope shape is the spec's primary substrate for refusal; the defensive citations in D-302 land on EXT §5.4 — refusal transparency — rather than §10 itself. If you edit §10, the surface area you're touching for THREATS is the same as EXT §5.4 above: denial-of-speech, cartel, gag-order.)

EXT §11 — Discovery (DNS TXT, optional DHT, ZK-promoted)

Per sub-clause:

• EXT §11.1 — DNS TXT discovery + EXT §11 (DNS / Herald handle binding generally) — partial defence against sigil squatting / vanity-prefix precompute, paired with SPEC §2.1. (D-302 §1.1 row 7, △.)
• EXT §11.2 — DHT signature requirements — whole defence (with SPEC §3) against DNS / DHT record substitution. (D-302 §1.8 row 1, ✓.)
• EXT §11.3 — ZK-promoted discovery (aspirational) — aspirational defence against whisper-only conduit honeypot. (D-302 §1.7 row 2, ◯.)

Residuals: cosmetic prefix collision is UX, not protocol; DNS control + key access wins (already game-over); DNSSEC recommended where deployed; ZK-promoted discovery depends on the same A1 research dependency as the rest of the ZK class.

EXT §12 — Domain separation registry

Defends against:

1. Cross-protocol signature reuse — whole defence (with SPEC §3.6). Registry of tags. (D-302 §1.1 row 8, ✓.)

EXT §13 — Threat-model: EXT additions (acknowledgements that reinforce specific clauses)

EXT §13 sub-sections do not contribute new active defences in D-302's matrix; they re-cite the active defences elsewhere in EXT. Note for editors: changing the prose in §13.1–§13.10 does not change the protocol's threat coverage, but it does change the authority of the cross-references that THREATS.md relies on. See D-302 §6 (citation drift) for the corresponding hygiene task.

EXT §14 — Conformance

Defends against (indirectly):

EXT §14 makes the SPEC-only-vs-EXT distinction enforceable: a SPEC-only verifier MUST output unknown (not valid) for envelopes exercising EXT primitives. This is the meta-defence against under-enforcement: any deployment that runs SPEC alone is required to advertise its ignorance of EXT-bound attacks rather than silently passing them.

D-302 §4 closes with this observation and §8 makes it the most important single takeaway: a SPEC-only implementation is not safe to deploy. Every defence routed through an EXT clause above implicitly depends on §14's unknown-vs-valid discipline being honoured.

Part C — Reverse heat-map (most-cited clauses)

Counted from Parts A and B above. Numbers are how many distinct THREATS attacks each clause defends or partially defends.

SPEC

EXT

The heat-map confirms D-302 §4: EXT carries more defensive weight than SPEC. SPEC §5.2, §4.2, and §3.x are the SPEC clauses you change at most peril. In EXT, §2, §3, §4, §5, and §7 are each load-bearing for ≥5 attacks; treat them as defended-API and any change should ship with a forward (D-302) and inverse (this doc) re-walk.

Part D — Editor's checklist

When editing a clause, this is the lookup procedure:

1. Find the clause in Part A or Part B above.
2. Read the bullet list of attacks under it. These are the defences you are touching.
3. For each affected attack, open audits/threat-coverage.md (D-302) and read the row to confirm the residual-risk language matches what the new prose still warrants.
4. If the new prose strengthens a △ to ✓ or drops a ✓ to △, log the change as part of the spec edit.
5. If the new prose removes the defence entirely, the attack moves to the ✗ column and D-302 §2's gap list grows by one. Don't do this without an explicit D- task to ratify the regression.

Specific high-stakes clauses (touch only with deliberate process):

• SPEC §3.3a — sole defence for cross-trace parent replay. Removing it re-opens the v0.1 vulnerability.
• SPEC §4.2 + EXT §7.1 — joint defence for the apologia 3rd-party and weaponisation rows. They are paired; do not edit one without checking the other.
• SPEC §5.2 + EXT §5.3 / §5.4 / §5.5 / §5.6 — the conduit cluster. Five attacks route through this set, several with △ partial status.
• EXT §2 cluster (§2.3–§2.8) — the audit-log defences. Six attacks. The minimal-metadata default (§2.7) and ZK promotion path (§2.8) are the only substrate-level steps toward closing the surveillance class.
• EXT §3 cluster (§3.1–§3.7) — the Herald defences. Five+ attacks. The △ flags here are honest about Heralds-not-yet-running.
• EXT §14 — the conformance gate. Weakening §14 weakens every EXT-routed defence simultaneously.

Part E — Inverse-coverage gaps surfaced

Walking the inverse direction surfaced a few editing observations not flagged by D-302:

1. EXT §10 has no direct defensive citations in D-302. All refusal-related defences route through §5.2 (SPEC) and §5.4 (EXT). Editors expecting §10 (the refusal-envelope shape) to be load-bearing for refusal-class threats should be aware the threats-defended weight is in §5.4, not §10 itself. A small SPEC/EXT-readability fix would be a forward pointer in §10 to §5.4.
2. EXT §13 (threat-model — EXT additions) is non-defensive. It is a re-citation layer; editing it changes nothing about coverage but does change cross-reference authority. This is exactly the surface D-302 §6 (citation drift) suggests D-306 should reconcile.
3. The four ✗ rows in D-302 §1.10 (Liar's-Paradox class) and the ✗ rows in §1.6 row 3 (Hagiography), §1.8 row 3 (Naming Office monopoly), §1.9 row 3 (vendor-Heralds) all have no clause to invert into. They are surfaced here only to confirm absence: there is no SPEC or EXT clause whose edit changes their coverage, because they have no coverage. They sit in D-302 §2 (G1–G8 gap list).
4. The ◯ aspirational rows depend on infrastructure, not on the clause text. Editing EXT §2.8 (ZK promotion) does not change current coverage of audit-log surveillance — that defence is gated on the ZK research deliverable (R-201). Inverse-coverage cannot help where forward coverage is itself ◯.

Part F — Status caveat (inherited from D-302 §1)

This is a paper inversion of a paper audit. No implementation has been verified to enforce any of the above. Every ✓ here means the spec text claims the defence; no claim is made about whether code today satisfies it. The same caveat from D-302 §1 (verification status) applies in full.

— T-022, completed by worker-glossary-par-2, 2026-05-05.