Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

instrument mechanism / verified-clean

QR Code Payload Size Estimator mechanism

The inspectable method record for QR Code Payload Size Estimator, kept separate from implementation and qualification.

Status: VERIFIED_CLEANLifecycle: verified-clean

Model scope

The capacity rows and the 4v + 17 grid rule are standard. Verdict is NEEDS_REVIEW because the requested output name, byte-encoding policy, ECI treatment, segmentation behavior, and mode-specific length units are unspecified. The two boundary vectors exactly match widely memorized version-1 table entries: numeric 41 at L and alphanumeric 20 at M.

  • The lookup-table method is standard, but the specification does not define how payload length is measured for each mode: numeric and alphanumeric capacities are character counts, while byte-mode capacity is encoded-byte count.
  • The output called "byte capacity margin" is not meaningful for numeric or alphanumeric mode unless it is renamed to mode-capacity margin and its unit is reported.
  • The grid-size formula is omitted; for QR version v it must be 4v + 17 modules per side.
  • Byte-mode results require an explicit character encoding, normally UTF-8, plus an ECI policy. Non-ASCII text can have more encoded bytes than characters.
  • The estimator must account for mode validity: numeric permits digits only; alphanumeric permits 0-9, A-Z, space, and $%*+-./:; byte mode depends on the selected byte encoding.
  • The standard capacity table assumes one QR segment in the requested mode. Automatic segmentation, multiple segments, ECI headers, structured append, and other headers can reduce available payload capacity and are not specified.

Units and conventions

  • QR table values use the ISO/IEC 18004:2015 QR capacity convention for a single segment and the stated error-correction level.
  • Grid size is measured in QR modules per side and is calculated as 4 times the version plus 17.
  • Numeric margins are measured in numeric characters; alphanumeric margins are measured in alphanumeric characters; byte-mode margins are measured in encoded bytes.
  • Byte-mode examples use UTF-8 without an additional ECI overhead segment; the table's byte capacities are treated as 8-bit byte capacities.
  • The requested mode is fixed rather than automatically optimized by the encoder.
  • The QR quiet zone, typically four modules on each side, is not included in the reported grid size.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "payload_text": "12345678901234567890123456789012345678901",
    "encoding_mode": "numeric",
    "error_correction_level": "L"
  },
  "expected_outputs": {
    "minimum_version": 1,
    "grid_modules": 21,
    "capacity_margin": 0,
    "capacity_margin_unit": "numeric characters (not bytes)",
    "selected_version_capacity": 41
  },
  "reference_data": {
    "source_convention": "ISO/IEC 18004:2015 QR capacity table",
    "rows": [
      {
        "version": 1,
        "error_correction_level": "L",
        "numeric_capacity": 41
      },
      {
        "version": 2,
        "error_correction_level": "L",
        "numeric_capacity": 77
      }
    ]
  },
  "working": "Count the payload: 4 groups of 10 digits plus 1 digit = 4 x 10 + 1 = 41 numeric characters. Version 1-L capacity = 41, so margin = 41 - 41 = 0. Version 1 is sufficient and therefore minimal; no smaller QR version exists. Grid = 4 x 1 + 17 = 21 modules per side."
}

Failure boundary

BREAK_CLAIMED · SELF_FLAGGED

The specification does not state how text is converted to bytes in byte mode, so the same payload can produce different byte lengths and margins. The estimator must also reject out-of-domain error-correction levels such as X.

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-tranche7/tranche7-results.json
  • BOUNDARY_HAZARD_CATALOG.json