Source: https://guthlabs.ai/docs/instruments/http-status-code-header-lookup/

instrument / verified-clean

# HTTP Status Code / Header Lookup

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

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

## Inspectable records

[01**Overview**Purpose and lifecycle](<https://guthlabs.ai/docs/instruments/http-status-code-header-lookup/>)[02**Mechanism**Method and assumptions](<https://guthlabs.ai/docs/instruments/http-status-code-header-lookup/mechanism/>)[03**Implementation**Binding and validation](<https://guthlabs.ai/docs/instruments/http-status-code-header-lookup/implementation/>)[04**Qualification**Evidence and errata](<https://guthlabs.ai/docs/instruments/http-status-code-header-lookup/qualification/>)

## Ledger state

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

**Area**: Computing & Information

**Tranche**: tranche-7

**Evidence ID**: t7-038

**Ledger rows**: 1

No ledger note is attached.

## Review findings

The core status-code and header lookup concept is valid, but the specification needs review before implementation. Define the authoritative header registry, the exact header-output schema, validation and miss behavior, and label non-normative common-cause and related-code annotations as curated reference guidance.

### Formula and scope findings

- The lookup-only approach is appropriate; status-code class can be derived as floor(status_code/100) followed by 'xx' for valid three-digit codes.

- The requested 'common causes' and 'related codes' are not authoritative fields in the IANA registry and require clearly labeled editorial or operational data in addition to RFC-defined meanings.

- The specification does not define the header dataset or the output schema for header lookups, such as whether header category means request/response direction, field type, or semantics.

### Unit assumptions

- Status codes are unitless, three-digit decimal integers; standard HTTP status-code classes are 1xx through 5xx, normally 100-599.

- Header-name matching should be case-insensitive because HTTP field names are case-insensitive under RFC 9110.

- The bundled status table is assumed to use IANA HTTP Status Code Registry and RFC 9110 terminology; operational 'common causes' are not normative protocol values.

- The bundled header table is assumed to use RFC 9110 registered field semantics and should identify any extension or non-standard fields separately.

## Boundary hardening

### Recorded hazards

- Unknown, obsolete, deprecated, extension, and unofficial status codes must not be silently presented as standard IANA codes.

- Status codes outside 100-599, non-integer inputs, and integers with more or fewer than three decimal digits require explicit validation behavior; code 0 must not be treated as a valid HTTP status code.

- A lookup miss for a header must be distinguished from a recognized but deprecated or non-standard header.

- Header names must be matched case-insensitively, while header values and parameter names may have separate parsing rules.

- 'Common causes' can be misleading because the same status code or header can result from many application, proxy, cache, or server conditions.

- The empty honest_label is a concern: the panel should disclose that common causes and related-code lists are curated annotations, not always normative IANA or RFC fields.

- The data tables need an update/version policy because the IANA registry and HTTP field registry can change.

## 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": {
    "status_code": 200
  },
  "expected_outputs": {
    "description": "OK",
    "category": "2xx",
    "common_causes": [
      "The request succeeded."
    ],
    "related_codes": [
      201,
      202,
      204
    ]
  },
  "reference_data": {
    "status_code_entry": {
      "code": 200,
      "description": "OK",
      "source_convention": "IANA HTTP Status Code Registry / RFC 9110 §15.3.1"
    },
    "category_rule": {
      "range": "200-299",
      "category": "2xx",
      "source_convention": "RFC 9110 status-code class convention"
    },
    "operational_annotation": {
      "common_causes": [
        "The request succeeded."
      ],
      "related_codes": [
        201,
        202,
        204
      ],
      "source_convention": "Widely tabulated standard operational interpretation; not an IANA normative field"
    }
  },
  "working": "1. Read status code 200 from the bundled registry. 2. Look up 200 => 'OK'. 3. Compute the class: floor(200 / 100) = 2, so the category is 2xx. 4. Return the bundled operational annotation: successful request; related success codes 201, 202, and 204."
}
````

## 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-tranche7/tranche7-results.json`