Skip to content
Multigrid

Regex Builder for Output Validation

Build a regular expression that checks a model answered in the shape you asked for, test it on real responses, and take away the JavaScript and Python that runs it.

Test cases that match
3 of 5

No known blow-up shapes found in the pattern. That is a structural check, not a proof that it is fast.

Pattern characters
36
Flags
i
Cases that matched
3
Cases that did not
2
Structural risks
0
Every test case, and what it captured:
  • 1. matches — "open" → captured "open"
  • 2. matches — " closed" → captured "closed"
  • 3. NO MATCH — "Sure! The status is: open"
  • 4. matches — "OPEN" → captured "OPEN"
  • 5. NO MATCH — "```\nopen\n```"
Things worth knowing about this pattern:
  • Case-insensitive matching is on, so OPEN and Open both pass and your code has to normalise the captured value before comparing it.
What this assumes: the risk check is structural: the pattern is walked atom by atom and the four shapes known to blow up are named, at the offset where each starts. Nothing is timed, because timing an adversarial input in your tab is how you freeze your tab — so a clean result is “no known bad shape”, not “fast”. Matching uses JavaScript's regex engine; Python, Go and Java differ on lookbehind, named groups and possessive quantifiers, and Go's RE2 will refuse some patterns outright while never backtracking. Everything on this page runs in your browser. Nothing you paste is uploaded, logged or sent anywhere.

A regex is the cheapest output validator there is: no second model call, no schema round trip, microseconds per response. It is also the one most often written wrong in the same two ways. The first is forgetting to anchor it — an unanchored pattern says “this text appears somewhere”, so a model that prefixes its answer with a sentence of throat-clearing passes a check that was supposed to reject exactly that. The second is validating a shape a regex cannot describe, which is what the JSON option above exists to warn you about rather than help you do.

Why the capture group matters

A validator that returns true or false makes you parse the value a second time. Capturing it in group 1 means the check and the extraction are the same operation, and the value you act on is provably the value that passed — no window between them in which a different substring gets used. That is why the generated code returns the capture and throws otherwise, instead of returning a boolean.

What a failure should do

Not a silent retry. A response that fails the pattern is the only evidence you will get about why, and if you throw it away and call again you have paid twice and learned nothing. Log the raw output, count the failures by shape, and if the same near-miss keeps appearing — a trailing full stop, a capitalised label, a wrapped code fence — the honest fix is usually a toggle above rather than a stricter prompt.

The reasoning behind this

Related tools

Regex Builder for Output Validation · Multigrid