Source: https://guthlabs.ai/docs/instruments/regex-tester/

instrument / verified-clean

# Regex Tester

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/regex-tester/>)[02**Mechanism**Method and assumptions](<https://guthlabs.ai/docs/instruments/regex-tester/mechanism/>)[03**Implementation**Binding and validation](<https://guthlabs.ai/docs/instruments/regex-tester/implementation/>)[04**Qualification**Evidence and errata](<https://guthlabs.ai/docs/instruments/regex-tester/qualification/>)

## Ledger state

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

**Area**: Computing & Information

**Tranche**: tranche-4

**Evidence ID**: t4-184

**Ledger rows**: 1

No ledger note is attached.

## Review findings

Core JavaScript regex testing is plausible, but the engine description, supported-flag scope, result API, error reporting, offset convention, and zero-length/global-match contract must be specified before the instrument can receive PASS.

### Formula and scope findings

- "JS RegExp engine execution (NFA-based matching)" is not a precise or universally correct formula: JavaScript specifies RegExp matching semantics, while engines may use backtracking, hybrid, or other implementations; backreferences and lookarounds are not regular-language NFA operations.

- The supported flag list is incomplete for JavaScript semantics: it omits at least y (sticky), d (hasIndices), and v (Unicode sets, where supported).

- "Flags common errors" is underspecified: the spec does not define which syntax errors, unsupported flags, invalid escapes, or runtime behaviors must be detected and reported.

- Match-list behavior is ambiguous because JavaScript results differ among RegExp.prototype.exec, String.prototype.match, String.prototype.matchAll, and test; especially when g is present and for zero-length matches.

### Unit assumptions

- There are no physical units.

- Match spans are assumed to use JavaScript UTF-16 code-unit offsets, with an exclusive end offset.

- The pattern syntax and flags are assumed to be JavaScript RegExp syntax, not PCRE, POSIX, ICU, or another flavor.

- With the u flag, matching is Unicode-aware, but JavaScript match indices still refer to UTF-16 code-unit positions.

- A global scan is assumed for match lists and counts; zero-length global matches are assumed to advance according to JavaScript RegExp rules.

## Boundary hardening

### Recorded hazards

- Division-by-zero is not applicable to this instrument, but an unguarded global zero-length pattern can cause an infinite loop if the implementation does not advance after an empty match.

- Invalid patterns or flags must produce a defined error result rather than a match list.

- UTF-16 offsets can split surrogate pairs when u is absent; the UI must label offsets as UTF-16 code units or explicitly convert them.

- Regexes with catastrophic backtracking can cause severe latency or denial of service; execution limits or cancellation are needed.

- Global matching state can persist in lastIndex when a reusable RegExp object is used, causing surprising results unless lastIndex is reset or managed explicitly.

- The native iOS note is correct: ICU NSRegularExpression is not behaviorally identical to JavaScript RegExp and must not be presented as an equivalent engine.

- The honest label should also disclose that JavaScript engine versions and supported flags can differ, and that match indices and zero-length behavior depend on the selected API contract.

## 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": {
    "pattern": "cat",
    "flags": "gi",
    "test_string": "Cat scat"
  },
  "expected_outputs": {
    "match_list": [
      {
        "text": "Cat",
        "start": 0,
        "end": 3,
        "groups": []
      },
      {
        "text": "cat",
        "start": 5,
        "end": 8,
        "groups": []
      }
    ],
    "capture_groups": [
      [],
      []
    ],
    "highlighted_match_spans": [
      [
        0,
        3
      ],
      [
        5,
        8
      ]
    ],
    "match_count": 2
  },
  "working": "1. UTF-16 positions in \"Cat scat\": C=0, a=1, t=2, space=3, s=4, c=5, a=6, t=7. 2. /cat/i matches \"Cat\" at start 0, exclusive end 0+3=3. 3. It also matches the final three characters of \"scat\": start 5, exclusive end 5+3=8. 4. Global matching returns 2 matches. 5. 2 matches × 0 capture groups gives capture arrays [], []."
}
````

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