Defiantly Not Regex
Executive summary
A literal match answers a narrow question: Does this input fit a pattern? Understanding intent answers a different one: What does this signal mean in context? Reliable systems need both capabilities, and a clear boundary between them.
Defiantly Not Regex grew from work with models and harnesses in my TechSoft Systems AI lab, including the original Hermes/Open-WebUI PIPER intent architecture. The engineering insight became a personal communication metaphor, then a programmer joke and a graphic. When its small encoded payload became difficult to read, the artifact became a compact case study in the same problem.
The broader argument is about the harness around intelligence. Models, tools, evidence, validation, clarification, and recovery mechanisms must work together when inputs are incomplete or ambiguous. A related principle applies to people: imperfect expression should not be treated as proof of imperfect thought.
1. Structure is evidence, not meaning
Regex is a precise and valuable tool for recognizing textual patterns. It can find a token, check an identifier's format, or extract a field from predictable input. Those are legitimate, often indispensable tasks.
But a correctly formatted statement can be misleading, and a malformed statement can communicate a coherent idea. Neither syntax nor fluency guarantees that an interpretation is right.
A robust system distinguishes three jobs:
| Job | Question | Appropriate response |
|---|---|---|
| Extraction | What characters or structure are present? | Use deterministic parsing when the input supports it. |
| Interpretation | What does the speaker or artifact likely mean? | Use context, evidence, and uncertainty-aware reasoning. |
| Verification | Is this the exact value or supported claim we can act on? | Check against an authoritative source and the relevant validation requirements. |
These jobs complement one another. Problems begin when interpretation is presented as exact extraction, or when a surface mismatch is treated as proof that no meaning exists. A format check can establish structure; it cannot establish the truth of an underlying claim.
2. The artifact: a message in multiple layers
Parse carefully. Humans are not strings.
"Defiantly," rather than "definitely," is intentional. The point is not hostility toward regular expressions; it is resistance to using the wrong abstraction for a human or semantic problem.
The artifact carries context through several channels:
- Visible typography: a statement and a human-readable instruction.
- Encoded fine print: a Base64 representation of a short explanatory message.
- Supporting context: website text, accessible descriptions, and image metadata where that metadata survives processing.
The rollover places the original image and its clearer reconstruction in conversation with each other. The main phrase remains legible across the change. The fine-grained characters are more fragile.
Base64 is an encoding, not an error-correction system. A misread character can change decoded bytes or cause a decode to fail. Neither apparent readability nor successful decoding alone proves that the resulting text matches the intended source.
3. Case study: when character-level recovery was unreliable
In an early version of the artifact, the small encoded line was too blurred for reliable transcription. Characters with similar shapes became ambiguous. The visible design still offered strong clues about the purpose of the message, but it did not establish every encoded character.
The recovery path was therefore not to let the model guess the missing Base64. It was:
- Recognize the artifact's intended purpose using the surrounding context.
- Refer back to the known explanatory message rather than assert an unverified decode.
- Rebuild the encoded text with deterministic tools and clearer typography.
- Verify that the new encoded payload decodes to the intended source.
- Preserve a human-readable explanation as a fallback.
The episode demonstrates a distinction worth protecting: the intended message was recoverable from context and known source material; the damaged characters were not thereby proven recoverable from the image alone.
The result was a better representation of the intended message. The task could continue because its purpose was understood and a different method was available.
4. The harness makes the distinction operational
A model can interpret ambiguous material, but its confidence is not a substitute for verification. Reliable behavior depends on the system surrounding it. This is what I came to call the year of the harness: treating interpretation, routing, validation, and recovery as engineering responsibilities.
The PIPER experience
In the original Hermes-based lab, with Open-WebUI as the front end, PIPER was an intake policy compiler and bounded-workflow guard. It connected intent to task contracts, freshness, clarification, required capabilities, routing, and evidence needs. EVA handled orchestration and synthesis, with specialist agents supplying bounded work.
The early hybrid design combined Core-generated contracts with conditional model assistance, validation, repair, and fallback. Historical runtime guards checked required work and controlled final-answer release; separate output contracts carried specialist findings and unresolved gaps back for synthesis. These were implemented research mechanisms, with failures and revisions, not a guarantee that every interpretation or conclusion was correct.
One investigated failure captures the problem. A follow-up mentioning "today" and "accidents" could trigger another traffic-research workflow even though the user was only acknowledging the previous report. The topic was recognized; the purpose of the turn was not. A proposed turn-context packet made that distinction explicit instead of relying on more phrase-by-phrase rules.
The later native plugin is an early adaptation of PIPER gateway ideas to another harness. Its current advisory role is one stage of the research, not the full scope of the original architecture or its future direction. Historical mechanisms and future goals should not be mistaken for current-plugin features.
Design obligations
The mechanisms vary by application, but the responsibilities are consistent:
- Route deliberately. Decide whether the task calls for exact parsing, interpretation, retrieval, computation, or clarification. Preserve the whole assignment beyond the first route.
- Track uncertainty. Label inferred intent as inference; do not quietly promote it to verified fact.
- Preserve provenance. Keep the source needed to validate exact outputs, quotations, identifiers, and encoded data.
- Constrain high-impact actions. Do not let an ambiguous reading silently trigger an irreversible operation.
- Provide recovery paths. Retry with better input, consult a trusted source, use deterministic tools, or request clarification.
- Validate the result. Check whether the completed work satisfies the request and whether its claims are supported.
A harness does not make a model infallible. It makes the system's assumptions, checks, and failure handling explicit, and therefore easier to test.
5. Human communication has its own noisy channels
People communicate under imperfect conditions. Typographical errors, word substitutions, fatigue, different language backgrounds, dyslexia, and incomplete context can affect expression without defining the quality of the underlying thought.
My own experience of less reliable expression under fatigue helped connect this principle to the lab work, as described in the backstory. A flawed output should not be mistaken for a flawed mind.
The engineering analogy has limits: people are not software components, and understanding them is not a decoding exercise. Still, the design lesson transfers. A malformed message should invite an effort to understand, not an automatic judgment of the person sending it.
Semantic tolerance also requires restraint. It means asking a clarifying question when interpretation matters, rather than confidently assigning an intention the speaker never expressed.
6. Practical design rules
Use the right level of precision. Match and validate exact strings for hashes, identifiers, commands, financial figures, and other fields where a single character matters. Do not substitute semantic similarity for byte-level correctness.
Treat context as evidence, not permission. Context can narrow possibilities and suggest a likely intention. It cannot justify manufacturing missing facts.
Keep a canonical source. If information must be rebuilt after corruption, reconstruct from a trusted original whenever possible. Validate the result before presenting it as exact.
Design for degraded inputs. Provide alternate representations, readable transcripts, clarification paths, and independent checks where the consequences justify them.
Separate understanding from action. It may be acceptable to infer what a user is asking; it may not be acceptable to execute a high-impact command until that inference is confirmed.
Make the failure visible. When extraction failed or verification is incomplete, say so. An explicit limitation is more useful than a polished fiction.
7. Scope and limitations
This is a design argument informed by independent AI lab work and an artifact-development experience, not a controlled study or benchmark. The artifact illustrates how contextual reasoning and deterministic reconstruction can complement one another; it does not measure their reliability across tasks, models, or input conditions.
Image metadata may be removed during resizing, upload, or distribution; fine print may be unreadable at smaller sizes; and a contextual interpretation may still be wrong. Those limitations are reasons to retain accessible text and independently verifiable source material, not reasons to rely more heavily on guesswork.
The lesson is narrower, and stronger, than "AI understands what regex cannot." Choose the mechanism that matches the task, preserve evidence, and build a recovery path for the cases where the signal is not enough.
8. Conclusion
An engineering insight became a personal reminder and a technical joke. The blurred encoded text made its central tension visible: literal characters can fail before the intent behind them disappears. But intent alone cannot certify an exact reconstruction.
The answer is not to abandon deterministic parsing or place unlimited trust in interpretation. It is to give each a proper role within a system that can distinguish uncertainty, consult evidence, validate outputs, and ask for help when necessary.
Parse carefully. Humans are not strings.
Appendix: the explanation inside the image
Short decoder
"Defiantly not regex" is a reminder to consider intent and context before judging surface patterns. The wording may be imperfect, deliberate, or both. Read carefully, and ask when the meaning is uncertain.
Representation and verification
The rebuilt PNG carries the idea through visible language, a rendered Base64 explanation, and file-level text metadata. These provide different ways to inspect the intended message, not interchangeable guarantees of recovery.
Base64 represents bytes as text; it does not provide error correction. An incorrect character can alter decoded bytes or cause rejection. Successful decoding alone is not an integrity check. See RFC 4648, section 4.
Metadata is useful only when retained and accessible. A screenshot may not preserve it, and an assistant receiving only image pixels cannot be assumed to read file-level fields. The formats are defined in the PNG specification's text chunks.
Exact context payload
The text below reproduces the rebuilt PNG's AI_CONTEXT metadata. The Base64 value matches its AI_CONTEXT_B64 field and encodes the same UTF-8 text, including the curly quotation marks.