Source: https://guthlabs.ai/docs/instruments/checksum-verifier/mechanism/

instrument mechanism / verified-clean

# Checksum Verifier mechanism

The inspectable method record for Checksum Verifier, kept separate from implementation and qualification.

Status: **VERIFIED_CLEAN**Lifecycle: **verified-clean**

## 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

[01**Overview**](<https://guthlabs.ai/docs/instruments/checksum-verifier/>)[03**Implementation**](<https://guthlabs.ai/docs/instruments/checksum-verifier/implementation/>)[04**Qualification**](<https://guthlabs.ai/docs/instruments/checksum-verifier/qualification/>)

## 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`