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>

spec/01-conventions.md

@@ -27,6 +27,8 @@ A producer SHOULD round coordinates to hundredths of a point, which keeps their
 
 A hash is SHA-256, written as 64 lowercase hexadecimal digits.
 Six digits are for display and for pins in addresses; no record stores a shortened hash.
+`document.json` names the function in `hashing.algorithm`, `sha-256` in this version, and every hash in the package, its records and its proofs uses the one function the document names; a consumer refuses an algorithm it does not implement (`doc.hash.algorithm`).
+Property names such as `sha256` and `page_fp` belong to that function, so a later algorithm arrives as a new major version of the formats whose values it changes, with the name in the data letting two versions share a store.
 Inside a team's own store, hashes are plain SHA-256; any content value that leaves the team is keyed, as [5.8](05-hashes.md#58-keyed-hashes) defines.
 
 ## 1.4 Text normalization for hashing

spec/08-fidelity.md

@@ -62,7 +62,7 @@ Its signing payload is the canonical JSON of `{"format": <the record's format>,
 | `gpg` | A detached, armored OpenPGP signature of the payload. |
 | `sigstore` | A Sigstore bundle for the payload, as JSON text. |
 | `cose` | Reserved: a COSE_Sign1 message over the payload, in Base64, as the IETF SCITT work shapes signed statements, so other transparency services can verify a receipt. No vector yet. |
-| `ml-dsa-65` | Reserved: an ML-DSA-65 signature (FIPS 204) of the payload, in Base64, for the time Ed25519 is no longer considered safe. No vector yet. |
+| `ml-dsa-65` | An ML-DSA-65 signature (FIPS 204, the pure variant with an empty context) of the payload, in Base64, for the decades after Ed25519 is no longer considered safe; the roster's `public` is the 1952-byte key in Base64. The reference implementation reproduces NIST's ACVP vectors; `signatures.jsonl` pins a key generation and a deterministic signature. |
 
 A consumer treats a record signed with a scheme it does not implement as invalid, so a reserved scheme can be adopted by a new minor version without any format changing.
 `signature.key` is the signer's roster key and equals `by`.
@@ -100,7 +100,8 @@ A spot-check is itself a receipt, so its status may depend on its own spot-check
 A revocation, `scienting-revocation/1`, names one `receipt`, or a `signer` and a `period` `{from, to}`, with a `reason`, and is signed like a receipt.
 It is valid when its signature verifies and its signer is the revoked receipt's signer, the signer it names, or a key whose `role` in the roster is `owner`.
 
-The roster, `scienting-roster/1`, lists the keys that may sign: each with an `id`, a `person`, a `role`, a `scheme`, its `public` key (Base64 for Ed25519), its `purposes` (`sign`, `spot-check`, `export`), `registered_at` and `revoked_at`.
+The roster, `scienting-roster/1`, lists the keys that may sign: each with an `id`, a `person`, a `role`, a `scheme`, its `public` key (Base64 for Ed25519 and ML-DSA-65), its `purposes` (`sign`, `spot-check`, `export`, or `witness` for a party that cosigns the team's log checkpoints, [23](23-log.md)), `registered_at` and `revoked_at`.
+A key MAY carry its `did`, the `did:key` decentralized identifier the public key determines: `z` and the base58btc of the multicodec prefix (`0xed` for Ed25519, `0x1207` for ML-DSA-65, as varints) followed by the key bytes; a validator refuses a `did` that the key does not determine (`doc.roster.did`), so a signer can be named outside the store without a second name.
 The `role` is the holder's role in the team that keeps the roster, `owner`, `editor`, `reader` or `guest`, as in a project ([20](20-projects.md)).
 Because the roster carries it, a package that carries its roster carries everything needed to judge its revocations.
 A package MAY carry the roster its receipts need as `roster.json`, so its receipts verify without the store.

spec/11-corrections.md

@@ -28,7 +28,7 @@ Runs are made canonical after every operation, and the result MUST satisfy every
 | Property | Holds |
 | --- | --- |
 | `evidence` | At least one item: `crop`, `witness` or `source-file` by SHA-256, or `person`. |
-| `author` | `{key}` for a person in the roster, or `{model, run}` for a model's session. |
+| `author` | `{key}` for a person in the roster, or `{model, run}` for a model's session, where `model` is `{name, provider?, version?, weights?, prompt?, parameters?, processor?}`: the model's name, who served it, its version, and SHA-256 of the weights, the instructions and the sampling parameters it ran with, as far as the team can obtain them, and where it ran ([14](14-rights.md)). |
 | `reason`, `at` | Why, and when. |
 
 A proposal, such as one a tool makes, carries these and `status: "proposed"`, and no applied fields.

spec/18-layers.md

@@ -54,7 +54,7 @@ Replies are annotations that target annotations, so discussions are threads anch
 | `crosslink` | `SpecificResource` | `source`, `selector` | That the span corresponds to a span in another document. |
 | `translation` | `TextualBody` | `language` | The span in another language. |
 | `description` | `TextualBody` | `role` | A description of a figure, panel or table for readers who cannot see it: `alt`, a short text equivalent, or `long`, a full description. |
-| `generated` | `TextualBody` | `generator` | Text a model wrote about the span; never mistaken for source. |
+| `generated` | `TextualBody` | `generator` | Text a model wrote about the span; never mistaken for source. `generator` is `{model, run}` as a correction's model author is ([11.2](11-corrections.md#112-every-correction-records)). |
 
 A textual body has a `value`, and optionally a `format` (`text/plain` or `text/markdown`) and a `language`.
 Nothing a model writes is ever stored as source text.

spec/20-projects.md

@@ -10,7 +10,7 @@ A project, `scienting-project/1`, is the unit a team works in.
 | `paths` | Reading paths: ordered steps through documents, nodes, claims and layers, for onboarding a student or preparing a reading group. |
 | `layers`, `datasets`, `views`, `drafts` | What the project holds. |
 | `claims` | The claim namespace or bundle it uses, as the `lode` setting. |
-| `settings` | The digit rule for targeted F3 ([8.10](08-fidelity.md#810-targeted-f3)), the drift threshold ([6.6](06-anchors.md#66-drift)), the spot-check rate and minimum ([8.8](08-fidelity.md#88-spot-checks)), what happens when a right is unknown (`refuse`, the default, or `warn`), and the stage requirements in use, as the `id` of their stage file ([14](14-rights.md)). |
+| `settings` | The digit rule for targeted F3 ([8.10](08-fidelity.md#810-targeted-f3)), the drift threshold ([6.6](06-anchors.md#66-drift)), the spot-check rate and minimum ([8.8](08-fidelity.md#88-spot-checks)), what happens when a right is unknown (`refuse`, the default, or `warn`), the stage requirements in use, as the `id` of their stage file ([14](14-rights.md)), and the project's transparency `log`: its `origin`, the roster keys that `witness` it, and the `threshold` of witnesses a checkpoint needs ([23](23-log.md)). |
 
 Projects are small on purpose: everything about them is designed for hundreds of documents, not millions.
 Owners sign policies ([14.2](14-rights.md#142-effective-uses)).

spec/23-log.md

@@ -38,8 +38,9 @@ The key hash is the first four bytes of SHA-256 of the signer's name, a newline,
 A note parsed into JSON has `format`, `origin`, `size`, `root` as hex, `signatures` as `{name, key_hash, value}` and the `note` text itself; the schema is `checkpoint.schema.json`.
 `checkpoint.jsonl` gives a checkpoint over the example paper's receipts and its verification.
 
-A checkpoint may carry further signature lines from witnesses, independent parties that cosign only a checkpoint consistent with every earlier one they saw.
+A checkpoint may carry further signature lines from witnesses: roster keys with the `witness` purpose, held by independent parties, that cosign only a checkpoint consistent with every earlier one they saw.
 A verifier that holds two checkpoints of one log checks a consistency proof between them ([11.5](11-corrections.md#115-the-history-root)); a log that cannot produce one has rewritten its past.
+A project accepts a checkpoint when its origin is the project's log, a key with the role `owner` and the `sign` purpose signed it, and at least the project's `threshold` of its listed witnesses cosigned it ([20](20-projects.md)); `fixtures/records/log/checkpoint` is signed by the team and one witness.
 
 ## 23.3 What a log settles
 
@@ -53,5 +54,15 @@ Without a log the rules of [8.6](08-fidelity.md#86-receipt-status) stand, and th
 
 ## 23.4 Serving a log
 
-A log is served as tiles, the layout transparency logs share, so that clients fetch only the subtrees they need and a static file server can host a log.
-The tile layout and the exact URL scheme are left to the first deployment; this chapter fixes only the entries, the tree and the checkpoint, which any layout must preserve.
+A log is served as static files in the tile layout transparency logs share, so that a client fetches only the subtrees it needs and any file server can host a log.
+
+| Path | Holds |
+| --- | --- |
+| `checkpoint` | The latest checkpoint note ([23.2](#232-checkpoints)). |
+| `tile/<L>/<N>` | Hash tile N of level L: the 32-byte hashes of the 256 complete subtrees of 256^L entries each that the tile covers, in order. Level 0 holds the leaf hashes. |
+| `tile/<L>/<N>.p/<W>` | The rightmost, partial tile of level L, holding W hashes. |
+| `tile/entries/<N>` and `tile/entries/<N>.p/<W>` | The entries themselves, 256 to a tile, as canonical JSON Lines. |
+
+N is written as 3-digit groups, every group but the last prefixed `x`: tile 1234067 is `tile/0/x001/x234/067`.
+A tile at level L holds only the hashes of complete subtrees, so the hashes a partial tree still needs are computed from lower levels, as RFC 9162 computes a root from its subtrees.
+`fixtures/records/log/` is the example paper's log in this layout, and `checkpoint.jsonl` lists its tile paths.