Luhn Algorithm Checksum Validator (Educational)

Inspectable records

Ledger state

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Area

Computing & Information

Tranche

tranche-5

Evidence ID

t5-126

Ledger rows

1

No ledger note is attached.

Review findings

The checksum rule is a standard Luhn rule under the stated rightmost-check-digit convention, but the specification needs an explicit validation-versus-generation contract, an explicit parity convention, and input constraints before it can receive PASS.

Formula and scope findings

• The validation formula is standard only under the convention that the rightmost digit (the supplied check digit) is not doubled and every second digit moving left is doubled; that parity convention is not stated explicitly.
• The formula for computing a check digit is missing. For a payload, the standard formula is check_digit = (10 - (sum mod 10)) mod 10, with the payload positions weighted as they will be after appending the check digit.
• It is ambiguous whether the input sequence includes an existing check digit or is a payload for which a check digit must be generated.
• The specification does not define handling for empty input, non-digit characters, whitespace, signs, decimal values, or leading zeros.

Unit assumptions

• Inputs are strings of ASCII decimal digits, not numeric values; leading zeros must be preserved.
• For validation, the rightmost digit is treated as the check digit and is not doubled; moving left, every second digit is doubled.
• When doubling produces a value greater than 9, its decimal digits are summed, equivalently subtracting 9 once.
• There are no physical units or unit conversions.
• The computed check digit is calculated for the payload excluding its final digit, then appended as one decimal digit.

Boundary hardening

Recorded hazards

• Empty input can produce an accidental pass if its total is initialized to zero; reject empty strings explicitly.
• Reject non-digit characters, signs, decimal points, whitespace, and values that have been numerically coerced and thereby lost leading zeros.
• Do not use ordinary floating-point numeric parsing for long digit sequences; process the input as a string to avoid precision loss.
• The implementation must define whether a one-digit sequence is treated as a complete sequence or as a payload; these cases can produce different API behavior.
• Modulo 10 itself has no division-by-zero hazard, but malformed or empty input validation remains an input-handling hazard.
• The UI and product copy must continue to state that this is an algorithm demonstration only, not validation of real payment cards; input must never be transmitted or stored.

Errata and corrections

No applied erratum is attached to this unique-name record.

Inspectable example

4 review vectors are recorded. One source-bound sample is shown below.

{
  "inputs": {
    "sequence": "79927398713",
    "operation": "validate"
  },
  "expected_outputs": {
    "pass": true,
    "computed_check_digit": "3"
  },
  "working": "From right to left: 3 stays 3; 1 x 2 = 2; 7 stays 7; 8 x 2 = 16, digit sum 1 + 6 = 7; 9 stays 9; 3 x 2 = 6; 7 stays 7; 2 x 2 = 4; 9 stays 9; 9 x 2 = 18, digit sum 1 + 8 = 9; 7 stays 7. Total = 3 + 2 + 7 + 7 + 9 + 6 + 7 + 4 + 9 + 9 + 7 = 70. 70 mod 10 = 0, so pass = true. For payload 7992739871, the weighted total is 67; (10 - (67 mod 10)) mod 10 = (10 - 7) mod 10 = 3."
}

Related workflows

No source-defined multi-instrument workflow membership is recorded.

Sources and evidence

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

• VERIFIED_LEDGER.json · VERIFIED_CLEAN
• evidence-tranche5/tranche5-results.json