Appendix F — Divergences from the spec

Where this list is silent, the spec governs. Every entry states: what the spec requires, what this implementation does instead, and why.

Live divergences

1. Repository naming

Spec: Meridian-Canon (one n). This repo: Meridian-Cannon (two n's) for historical reasons. The inconsistency is unresolved. Why: The textbook preserves both spellings: Meridian-Cannon for the repository, Meridian-Canon for the specification. No change to conformance. ### 2. Embedding model defaults Spec: nomic-embed-text-v1.5 (768-d) on SQLite; bge-large-en-v1.5 (1024-d) on Postgres. This textbook: Chapter 9 introduces BGE-M3 and Nomic v2-MoE as defaults for new builds; spec defaults remain documented for backward compatibility. Why: Per dossier 03, the spec defaults are the 2024 generation; BGE-M3 and Nomic v2-MoE are the 2026 successors. No change to attestation byte-shape. ### 3. Cryptopals-equivalent for canonicalization Spec: No specific lab prescribed. This textbook: Lab 7 — a six-problem set walking from naïve canonicalization to the parser-mismatch attack, identified in dossier 01 as a pedagogical gap. Why: Canonicalization byte-exactness is best learned by attacking it. The lab is supplementary; it is not a Canon conformance requirement. ### 4. Second-language verifier Spec: Implementation-neutral; no second language required. This textbook: Lab 25 requires implementing the verifier in Go (or Rust) and proving byte-for-byte agreement with the Python reference. Why: Re-implementation in a second language is the only reliable way to verify that canonicalization is byte-exact. This is pedagogy, not a Canon conformance requirement. ### 5. EU AI Act compliance overlay Spec: Silent on EU AI Act compliance. This textbook: Appendix C and Chapter 26 treat it as an optional overlay for systems deployed in EU jurisdictions. No effect on R1–R9 conformance. ### 6. Status of FRE 707 Spec: Frames FRE 707 as an open question. This textbook: Explicit that FRE 707 is proposed but not law as of May 2026 (see Chapter 3, Appendix C, dossier 05). The spec is silent on the timeline. ### 7. Key rotation implemented; formal revocation not implemented What diverges. The spec (§ 6.4) describes a key lifecycle that includes revocation: a previously-issued key can be invalidated so that attestations signed under it are no longer considered valid. The meridian-canon rotate-key CLI command (Chapter 23, meridian/canon/keys.py) implements rotation — generating a new Ed25519 keypair, recording the prior public key and rotation timestamp in the audit log, and updating the active key in the Keychain — but it does not implement revocation. Existing attestations signed under the rotated-out key remain verifiable; there is no mechanism to mark them invalid or to publish a revocation list. Why. Revocation requires a distribution channel (a revocation endpoint or a signed revocation list that verifiers can fetch). That infrastructure is out of scope for the current implementation; the textbook does not yet cover deployment of the attestation signing service as a network-accessible component. Implication. In the current implementation a compromised key cannot be actively invalidated. The mitigation is procedural: rotate promptly on suspicion of compromise, record the rotation event in the audit log with a reason field, and disclose the rotation to any relying party that holds attestations signed under the prior key. Chapter 23 notes this limitation explicitly and defers formal revocation to a future Phase C implementation. ### 8. DSSE adoption — breaking change in signature format What changed. Canon v0.2.0 adopts DSSE per the CNCF in-toto specification. Prior to v0.2.0, Canon used bare Ed25519 over JCS bytes — sign(SHA-256(JCS(obj))). v0.2.0 uses sign(PAE(payload_type, JCS(obj))). This is a breaking change in the signature format: a v0.1.x signature over an attestation body is not a valid v0.2.0 DSSE signature over the same body, and vice versa. Implication. Attestations sealed with emit() (v0.1.x) verify via the seven-step legacy path. Attestations sealed with emit_dsse() (v0.2.0) verify via the DSSE three-step path. Both paths are supported by conformant verifiers. The dsse_envelope key is the discriminator. Migration. Existing v0.1.x attestations are not invalidated. No re-sealing is required. For new attestations, emit_dsse() is preferred. emit() is retained for backward compatibility and documented as legacy. ### 9. chain_hash as Canon extension to DSSE What diverges. The DSSE base specification does not include a chain_hash field in the envelope. Canon v0.2.0 adds chain_hash as an extension field containing SHA-256(base64url_decode(payload)). This allows field-level integrity checking without implementing the full PAE verification procedure. Why. The chain_hash field is a convenience for recipients who want to confirm payload integrity quickly (a single SHA-256) before committing to the PAE computation and Ed25519 verification. It is not a substitute for signature verification but provides a fast pre-check. Implication. A verifier that only checks chain_hash is not conformant — it must also verify the Ed25519 signature over the PAE. The chain_hash field is documented as a convenience; the PAE signature is authoritative. ### 10. payload_type version encoding — Canon convention What diverges. DSSE specifies that payload_type is a URI identifying the content type of the payload. It does not require version information in the URI. Canon v0.2.0 encodes the spec version in the payload_type string: application/vnd.nora.canon.attestation+json; version=0.2.0. This is a Canon convention, not a DSSE requirement. Why. Encoding the version in payload_type ensures that the version is part of the signed message (via PAE). A verifier can detect version mismatches from the payload_type alone, without parsing the payload. This makes version detection fast and tamper-evident. Implication. A DSSE verifier that does not understand Canon's version parameter will still verify the signature correctly — the parameter is part of the type string, not a separate field. It is a Canon extension to DSSE naming conventions, not a change to the DSSE protocol. ### 12. Epistemic Neutrality Masking uses a rule-based masker, not a trained classifier What diverges. The spec (§ 5.2, R5 — Epistemic Neutrality) calls for a masking component that suppresses author-identifying signals using a model trained to recognize those signals across diverse text styles. The current implementation in meridian/witness/local_chunker.py and part3_architecture/18_epistemic_masking.md uses a rule-based masker: a configurable list of named-entity patterns, pronoun substitution rules, and stopword filters defined in YAML (see docs/textbook divergence note in EDITORIAL.md). The masker does not learn from data and does not generalize beyond its configured pattern set. Why. A trained classifier requires a labeled corpus of author-attributed text, a training pipeline, and periodic retraining as writing styles shift — infrastructure that is not yet in place. The rule-based approach is deterministic, auditable, and sufficient for the current evidence types (email headers, SMS metadata, structured records) where author signals are largely confined to known fields. Implication. The rule-based masker may fail to suppress subtle stylometric signals in free-text fields (narrative case notes, long-form correspondence). Any consumer of Meridian-Cannon attestations relying on R5 for anonymization should treat the current ENM as a best-effort mitigation, not a guarantee. Chapter 18 documents the pattern set in full and includes a ✻ Try This exercise that demonstrates the attack surface. Replacing the rule-based masker with a trained classifier is listed as a Phase C deliverable. ## Resolved divergences (none yet) ## Open questions - Should the textbook include a Rust reference verifier as a separate published artifact? Decision pending. - Should the textbook ship a Quarto build pipeline by default, or remain Markdown-only? Decision pending; per dossier 06 Quarto is the recommendation. - Should the standalone nora-canon-verifier PyPI package ship from this repository or from a separate one? Decision pending.

Status: living document. Update on every divergence noticed.