Audit D-309 — `model_hash` vs `lineage_training` reconciliation

Audit D-309 — model_hash vs lineage_training reconciliation

Worker: worker-glossary-2026-05-05
Date: 2026-05-05
Spec sections touched: [SPEC §4.1], [EXT §3.1, §3.2], [registries/standard-attestations.md §2.4]
Triggering finding: T-012 INTERPRETATION I-2 (worker-B); flagged as F-2 in T-012 NOTES.md

TL;DR

There is no genuine name clash. model_hash and lineage_training
are correctly distinct type identifiers at two different points in the
Herald-attestation lifecycle. Merging them would lose
authoritativeness signal. The fix is editorial: make the layering
explicit in SPEC §4.1, EXT §3.1, EXT §3.2, and the registry entry —
no on-wire bytes change.

Decision

Keep both names. Document the layering.

Both forms occupy the same JSON/CBOR field (attestations[*].type).
Verifiers MUST distinguish them by name and apply different trust
policies.

Why both names

• They produce different verifier behaviour. A model_hash

attestation is a self-claim — verifiers display it, do not honour
it as proof of training graph membership without independent
Herald endorsement. A lineage_training attestation is a Herald's
signed claim; verifiers MAY treat it as authoritative if the
Herald's signature is present in its CT log per [EXT §3.4].

• Renaming either to a single identifier would force verifiers to

reconstruct the distinction from secondary signals (envelope
signer being a Herald sigil, presence of spec field, signature
scope), all of which are weaker than a type-name discriminator.

• Worker-B's T-012 registry entry already chose this layering and

documented it. The fix here is to lift the explanation from
registry-level into protocol-level prose.

Why this is not a "rename" task

The on-wire identifiers do not change. No envelopes already-built
become invalid. The test vectors do not change. This is a docs-only
reconciliation that brings SPEC §4.1, EXT §3.1, EXT §3.2, and the
registry preamble into agreement on a layering they already imply.

Patches

The following edits are recommended. Each is a docs-only change to
SPEC.md, EXT.md, and registries/standard-attestations.md.

Patch 1 — SPEC §4.1 (line 242)

Current:

| `model_hash` | hex | Optional: hash of model weights, attested by Herald (see [EXT §3](EXT.md)) |

Proposed:

| `model_hash` | hex | Self-declared hash of model weights. Unauthoritative on its own; becomes authoritative when paired with a Herald-issued `lineage_training` attestation (see [EXT §3.1–§3.2](EXT.md)). |

Rationale: makes the self-declaration vs Herald-endorsement layering
visible at the SPEC table level. Tells implementers reading SPEC
alone that following the EXT pointer reveals a different type
identifier for the authoritative form, not a continuation of
model_hash.

Patch 2 — EXT §3.1 (lines 213–217)

Current end of paragraph 2 (line 215):

A separate primitive, the `model_hash` attestation, is used for **training graph** claims. A `model_hash` attestation MUST be signed by a Herald that has independently verified the weights against a published canonical model-hash specification.

Proposed:

A separate primitive carries **training graph** claims. The agent's own envelope MAY carry a self-declared `model_hash` attestation per [SPEC §4.1] (a bare hex string referencing a model-hash registry entry). The authoritative form is the **Herald-issued `lineage_training` attestation** (see §3.2 below), whose value structure includes the same `model_hash` hex but additionally binds it to a `subject` sigil, a `spec` registry entry, and a Herald signature with domain-separation tag `herald.lineage_endorsement.v1`. A self-declared `model_hash` is a claim; a Herald-issued `lineage_training` is a proof.

Rationale: distinguishes the two type identifiers at the protocol
text level. Removes the implication that the model_hash
attestation is itself Herald-signed (which would conflict with SPEC
§4.1 calling it "self-declared" — which the fixed SPEC text does).

Patch 3 — EXT §3.2 (line 217)

Current line 217:

A reputation system or verifier MUST NOT conflate consent and training graphs. Display, scoring, and policy MAY treat them differently; the protocol-level requirement is that envelopes carry a discriminator (`type: "lineage_consent"` vs `type: "lineage_training"`) and that verifiers expose both classes distinctly in their output.

Proposed (additive):

A reputation system or verifier MUST NOT conflate consent and training graphs. Display, scoring, and policy MAY treat them differently; the protocol-level requirement is that envelopes carry a discriminator (`type: "lineage_consent"` vs `type: "lineage_training"`) and that verifiers expose both classes distinctly in their output.

Verifiers MUST also distinguish a Herald-issued `lineage_training` attestation from an agent's self-declared `model_hash` attestation per [SPEC §4.1]. The two share the `model_hash` *field* inside the attestation value, but the *type identifier* is what determines authoritativeness: only `lineage_training` (signed by a Herald, recorded in the Herald's CT log per §3.4) is authoritative; bare `model_hash` is a claim awaiting endorsement.

Rationale: makes the layering rule normative. Without this, a
verifier reading EXT in isolation might assume the model_hash form
is just a shorter way of saying lineage_training.

Patch 4 — registries/standard-attestations.md §2.4 (line 456)

Current:

This shape follows [EXT §3.2] (`{ "type": "lineage_training", ... }`) where the registry entry is `model_hash`. **Naming clash flag:** SPEC §4.1 lists the type identifier as `model_hash`, while EXT §3.2 uses `lineage_training` for the Herald-issued attestation envelope shape. They describe the *same* primitive at two different layers. This registry entry uses the SPEC name `model_hash` for compatibility with the SPEC §4.1 table. See `INTERPRETATION.md`.

Proposed:

This registry entry covers the **self-declared** `model_hash` attestation per [SPEC §4.1]. The **Herald-issued** authoritative form has a richer envelope value and uses the type identifier `lineage_training` per [EXT §3.2]; it has a separate (Herald-attestation) registry entry. The two are intentionally distinct identifiers — the type-name distinguishes a self-claim from a Herald-endorsed proof. Verifiers MUST surface them differently. See [EXT §3.1] for the layering rule.

Rationale: stops calling the situation a "naming clash". Worker-B's
INTERPRETATION I-2 was correct; the resolution is to document the
layering, not to rename anything. The registry entry stays under
model_hash (SPEC §4.1's name).

Patch 5 — registries/standard-attestations.md preamble (line 29)

Current:

- `lineage_consent`, `lineage_training`, `revoke_attestation`, `molt_policy`, threshold lineage attestation — covered by T-016 (sigil registry) and the Herald-attestation registry implied by [EXT §3.4]; mentioned in cross-references where relevant.

Proposed (split for clarity):

- Herald-issued envelope shapes — `lineage_consent`, `lineage_training` (authoritative form of `model_hash`; see §2.4), `revoke_attestation`, threshold lineage attestation — belong to the Herald-attestation registry implied by [EXT §3.4]. They are mentioned in cross-references here where relevant.
- `molt_policy` is referenced in SPEC §2.4 and EXT §1.6 but not yet shape-specified; see D-312.

Rationale: separates "Herald-issued envelope shapes" from "agent
self-declared attestations" so a reader of this registry sees the
two-layer pattern.

What does NOT change

• No on-wire byte changes. Test vectors (test-vectors/v0.2/)

are unaffected. Signature bytes do not change.

• No domain-separation tag changes. D-308 settled the tag table

at .v1; this audit does not touch it.

• No CHARTER changes. CHARTER §3 (attestation library) does not

enumerate model_hash or lineage_training directly; it lists
cultural attestations and points at the standard registry. No
cross-references in CHARTER mention either name.

• No THREATS changes. THREATS.md:143 says "Mass false model_hash

attestations [SPEC §4.1]". The reference correctly cites SPEC
§4.1 for the self-declared form (which is what an attacker would
flood). No edit needed.

What I considered but rejected

• Rename lineage_training to model_hash_endorsement. Tempting

symmetry, but lineage_training is the existing wire identifier
per EXT §3.2 and is referenced by herald.lineage_endorsement.v1
domain-sep tag. Renaming costs migration without a payoff —
symmetry doesn't carry information that the existing names lack.

• Rename model_hash to model_hash_claim. Slightly clearer

but breaks the SPEC §4.1 table that already calls it model_hash,
every existing CHARTER reference to "model_hash attestation",
and the registry entry name. Cost outweighs the benefit.

• Collapse to a single identifier. Loses the

self-declaration/Herald-endorsement signal that's load-bearing.
Verifiers would have to reconstruct authoritativeness from
secondary signals, which is exactly what type names exist to
prevent.

Verification

After patches 1–5, the following should hold:

1. grep -nE "model_hash" SPEC.md should return only the §4.1 table
row (one occurrence, possibly two if §2.3 or §4.2 references the
self-declared form).
2. grep -nE "lineage_training" EXT.md should return its definition
site (§3.2) and any cross-reference uses, none referring to a
self-declared form.
3. The phrase "naming clash" should no longer appear in any in-tree
doc.
4. The phrase "self-declared model_hash" should appear in SPEC
§4.1, EXT §3.1, and registries/standard-attestations.md §2.4 —
the three places that benefit from the layering being explicit.
5. The glossary-check tool (T-019) should not introduce new findings
on the patched docs.

A future Herald-attestation registry (out-of-scope for this audit;
see [EXT §3.4]) should document lineage_training, lineage_consent,
revoke_attestation, and threshold lineage attestation as
first-class entries with full envelope-level shapes.