Checksum Verifier mechanism

Model scope

The core operation is feasible offline in pure JavaScript, but the specification is not complete enough for an unconditional PASS. Define the exact CRC32 parameter set, UTF-8 and newline policy, checksum syntax and case policy, algorithm error behavior, and honest UI labeling. The UI should state that CRC32 and MD5 are legacy integrity checks rather than collision-resistant security hashes.

• CRC32 polynomial division is conceptually correct but underspecified: CRC-32 variant parameters must be fixed, including polynomial, initial value, input/output reflection, final XOR, and output width. The standard CRC-32/ISO-HDLC parameters are assumed below.
• Hash digest comparison is the correct comparison operation, but the digest formulas and exact algorithm variants are not explicitly specified. MD5 and SHA-256 should be defined as their standard algorithms with exact byte input.
• The specification does not define text encoding, newline normalization, file-byte handling, hexadecimal case handling, or whether surrounding whitespace is significant.
• The specification does not state required checksum lengths or behavior for malformed expected checksum strings and unsupported algorithms.

Units and conventions

• Text test inputs are encoded as UTF-8 with no implicit newline, whitespace trimming, or Unicode normalization.
• Files are hashed as their exact raw bytes.
• CRC32 means CRC-32/ISO-HDLC: polynomial 0x04C11DB7, reflected implementation polynomial 0xEDB88320, initial register 0xFFFFFFFF, reflected input and output, final XOR 0xFFFFFFFF, 32-bit lowercase hexadecimal output.
• MD5 output is 128 bits represented by exactly 32 lowercase hexadecimal characters.
• SHA-256 output is 256 bits represented by exactly 64 lowercase hexadecimal characters.
• Checksum comparison should be exact after validating hexadecimal syntax; if case-insensitive comparison is intended, that must be explicitly documented.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "algorithm": "CRC32",
    "text": "123456789",
    "expected_checksum": "cbf43926",
    "encoding": "UTF-8"
  },
  "expected_outputs": {
    "computed_checksum": "cbf43926",
    "match": true
  },
  "working": "UTF-8 bytes: 31 32 33 34 35 36 37 38 39. Initialize CRC register = FFFFFFFF. Apply the reflected CRC-32 recurrence for all 9 bytes using polynomial EDB88320. Register after the final byte = 340BC6D9. Apply final XOR: 340BC6D9 XOR FFFFFFFF = CBF43926. Format as 8 lowercase hexadecimal characters: cbf43926. Compare cbf43926 with cbf43926: equal, so match = true."
}

Failure boundary

BREAK_CLAIMED · SELF_FLAGGED

The specification does not define text encoding or whether hexadecimal checksum comparison is case-sensitive. The convention probe therefore produces match=true under the stated UTF-8, case-insensitive convention but strict case-sensitive comparison would produce mismatch=false for the same visible input and expected checksum.

Other records

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• VERIFIED_LEDGER.json
• evidence-tranche4/tranche4-results.json
• BOUNDARY_HAZARD_CATALOG.json