feat: ML-DSA-65, did:key, named hash algorithm, model provenance, log tiles and witnesses

- hashing.algorithm names the hash function in every document; a consumer refuses one it does not implement (doc.hash.algorithm)
- ML-DSA-65 (FIPS 204) is an implemented signature scheme: pure-Python reference in tools/oracle/mldsa.py checked against NIST ACVP vectors, a receipt signed by the new roster key dana, and signature vectors for key generation and a deterministic signature
- roster keys may carry a did:key, which the validator checks against the public key (doc.roster.did), and a witness purpose for parties that cosign log checkpoints
- model provenance: a correction's author and an annotation's generator name the model with provider, version and the hashes of its weights, prompt and parameters, and where it ran
- the transparency log gains the tlog-tiles static layout (fixtures/records/log/), a project settings.log with origin, witnesses and threshold, and an acceptance rule; the fixture checkpoint is cosigned by a witness
- store.sql: roster_keys accepts cose and ml-dsa-65 and gains a did column
- spec chapters 01, 08, 11, 18, 20 and 23, the rationale, glossary, fixture, vector and tool guides updated; stress harness covers ML-DSA

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/glossary.md

@@ -38,6 +38,7 @@ Format `scienting-checklist/1`, `provisional`. ([8.11](../spec/08-fidelity.md#81
 
 Checkpoint
 :   A signed note that states a transparency log's size and root hash, which a verifier checks against the last checkpoint it saw.
+Independent parties, the log's witnesses, cosign it, and a project says how many must.
 Format `scienting-checkpoint/1`, `provisional`. ([23.2](../spec/23-log.md#232-checkpoints))
 
 Correction
@@ -46,6 +47,11 @@ Correction
 Description
 :   An annotation that describes a figure, panel or table for readers who cannot see it, as a short text equivalent (`alt`) or a full description (`long`); an accessible export uses confirmed descriptions only. ([18.4](../spec/18-layers.md#184-bodies))
 
+DID
+:   Outside term.
+A decentralized identifier (W3C).
+A roster key may carry its `did:key`, which the public key alone determines, so a signer has one name inside and outside the store. ([8.7](../spec/08-fidelity.md#87-revocations-and-the-roster))
+
 Document
 :   The text established for one version of one work, from one or more witnesses, as a tree of nodes. ([2.1](../spec/02-model.md#21-four-objects), [3](../spec/03-nodes.md))
 
@@ -90,6 +96,14 @@ Match hash
 Two readings agree only when their match hashes are equal and their complex-notation keys are equal.
 A complex-notation key is `notation:source` for a piece of math too complex for the formats to normalize, with the source's whitespace removed ([5.3](../spec/05-hashes.md#53-the-strict-projection)). ([5.1](../spec/05-hashes.md#51-the-five-values), [5.3](../spec/05-hashes.md#53-the-strict-projection))
 
+ML-DSA-65
+:   Outside term.
+The lattice-based signature scheme of FIPS 204, believed to resist quantum computers.
+A receipt may be signed with it today, beside Ed25519. ([8.4](../spec/08-fidelity.md#84-record-hashes-and-signatures))
+
+Model
+:   The record of a machine-learning model that proposed a correction or wrote an annotation: its name, provider and version, and the hashes of its weights, instructions and parameters. ([11.2](../spec/11-corrections.md#112-every-correction-records))
+
 Node
 :   An addressable part of a document: a section, paragraph, sentence, figure, panel, caption, table, row, cell, equation, footnote, reference and the rest.
 Each node has a permanent ID and five content values; table columns and figure-text items have IDs and are not nodes. ([3](../spec/03-nodes.md), [4.2](../spec/04-identity.md#42-minting-node-ids))
@@ -164,6 +178,9 @@ Text leaf
 Text policy
 :   Whether a package carries its text (`full`) or withholds it (`checks-only`). ([12.5](../spec/12-package.md#125-text-policies))
 
+Tile
+:   One file of a transparency log served statically: 256 hashes of one level of the tree, or 256 entries, so a client fetches only the subtrees it needs. ([23.4](../spec/23-log.md#234-serving-a-log))
+
 Verdict
 :   A judgment of whether a cited passage supports a citing sentence: supports, partly, does not, or cannot tell. ([19.2](../spec/19-exercises.md#192-verdicts))
 

docs/rationale.md

@@ -302,13 +302,13 @@ These are settled for now, and a future version may revisit them.
 
 Choices made so that the formats still serve in the 2030s, and the ones deliberately left open.
 
-- Signature schemes `cose` and `ml-dsa-65` are reserved: COSE so that the IETF's SCITT transparency services can verify receipts, ML-DSA (FIPS 204) for the time Ed25519 is no longer considered safe.
-  A consumer treats an unimplemented scheme as invalid, so adopting either is a minor version ([spec/08 §8.4](../spec/08-fidelity.md#84-record-hashes-and-signatures)).
-- Every hash is SHA-256, and the hashing scheme names only how a value is keyed, not the function.
-  A hash function change would be a new major version of every format; the formats accept that rather than carrying agility they cannot test.
-- Roster keys are named by short keys, not by decentralized identifiers; a `did:key` form could be added as a key property without a new version.
-- A correction's author may be a model and its run; a fuller provenance for model output (the model's identity, weights and prompt by hash) is left to the project that first needs it.
-- A transparency log is specified but no deployment exists yet; its tile layout is left to the first one ([spec/23](../spec/23-log.md)).
+- `ml-dsa-65` (FIPS 204) is a signature scheme a receipt may carry today, with a pure-Python reference implementation that reproduces NIST's test vectors, so a team can sign with a post-quantum key before Ed25519 is deprecated and verify such receipts decades on.
+  `cose` is reserved for the IETF's SCITT transparency services; a consumer treats an unimplemented scheme as invalid, so adopting it is a minor version ([spec/08 §8.4](../spec/08-fidelity.md#84-record-hashes-and-signatures)).
+- Every hash is SHA-256, and `document.json` names the function, so a later algorithm is a new major version that can share a store with this one rather than a silent reinterpretation ([spec/01 §1.3](../spec/01-conventions.md#13-hashes)).
+- A roster key may carry its `did:key`, which the public key determines, so a signer has one name inside and outside the store ([spec/08 §8.7](../spec/08-fidelity.md#87-revocations-and-the-roster)).
+- A model that proposes a correction or an annotation is named by its weights, instructions and parameters by hash, and by where it ran ([spec/11 §11.2](../spec/11-corrections.md#112-every-correction-records)).
+- The transparency log has a static tile layout, witnesses in the roster, and an acceptance rule in the project's settings; what remains is to run one ([spec/23](../spec/23-log.md)).
+- The VRF reference implementation proves in about 5 ms and verifies in about 4 ms in plain Python, which is fine for fixtures and small logs; a production verifier can use any RFC 9381 library, since the proofs are the standard's bytes.
 
 ## Known limits