The order-faithful primary-key core of the initial snapshot (C2, design Ch3/Ch4).

A chunk pages by ORDER BY pk in MySQL while the cursor-gate classifies streamed changes by k ≤ cursor in Elixir. For that pairing to be correct — no silently mis-classified change (delivered vs suppressed → gap/dup) — the PK's Elixir term-order MUST provably match MySQL's ORDER BY. This module enforces that with a positive type allowlist and supplies the two operations the coordinator needs on PK values:

• canonical/2 — the equality form for the sink ledger. Canonicalization happens in Elixir (reconciliation-equality), NOT MySQL collation. The text-protocol string form of a PK (a chunk read) and the binlog-decoded integer/binary form (a streamed change) canonicalize to the SAME term, so the ledger reconciles a chunk row against a streamed change to the same key.
• compare/2 — the ordering for the cursor-gate (k ≤ cursor). Over the allowlist it is exactly MySQL ORDER BY: integers order numerically, BINARY/VARBINARY order byte-wise (shorter prefix first), and composites order lexicographically as tuples (matching MySQL row-value ORDER BY).

The positive allowlist (Ch3.2 / Ch4)

ACCEPT only the types whose Elixir order provably matches MySQL ORDER BY:

• signed/unsigned integer — TINYINT/SMALLINT/MEDIUMINT/INT/BIGINT
• BINARY / VARBINARY (byte-ordered)
• composites of the above (tuple compare)

REFUSE everything else with :snapshot_pk_unsupported_type:

• the collation-ordered STRING family — CHAR/VARCHAR/TEXT (both a _bin and a _ci collation report data_type char/varchar, so collation cannot distinguish them; the whole family is refused). A collation order Elixir cannot reproduce would let the cursor-gate mis-classify a change.
• DECIMAL/DOUBLE/FLOAT/DATE/DATETIME/temporal and any other type — their Elixir term-order diverges from MySQL.

BIGINT UNSIGNED across 2^63 (Ch3.1)

An unsigned 64-bit PK spans [0, 2^64). A signed-wrap decoder reads the high half as negative (2^63 → -2^63, 2^64-1 → -1), so it would order 2^63… before 0… and the cursor-gate would mis-classify a high-half key. canonical/2 decodes to the TRUE unsigned value: a text form parses directly, and a raw integer that arrived signed-wrapped (a negative for an unsigned column) is normalized back into [0, 2^width).

No PK → fail closed

introspect/2 reads information_schema for the PRIMARY KEY. A table with no PK accepts a UNIQUE key fallback ONLY IF every column of that key is NOT NULL — a nullable unique-key column admits NULL-keyed rows that WHERE k > cursor never selects (a silent gap, Ch3.3), so such a key is refused :snapshot_table_no_primary_key. A table with neither is refused the same way.

Rule 1

No PK value is ever logged or telemetered here. Errors are value-free atoms. The information_schema queries embed only the schema/table (structural identity — the same fields telemetry may carry), never a row value, and are escaped as SQL string literals.