CONCEPT Cited by 1 source

Regex + enum validation

Definition

Regex + enum validation is the two-layer validation discipline in which:

1. A regular expression validates the syntactic shape of a string — does it have the right format, the right separators, the right field count, the right character class.
2. A StrEnum-backed canonical registry validates the semantic identity — is the string one of the names this system actually knows about.

The two layers catch different bug classes. The regex catches malformed names. The enum catches syntactically valid but non-canonical names — a name that looks right but isn't on the approved list.

"A regex validates the structure, and a StrEnum backs the canonical registry. The regex catches malformed names, while the enum catches names that are syntactically valid but not canonical." — Source: sources/2026-06-02-redpanda-how-omninode-uses-redpanda-to-scale-ai-agent-workflows

Why one layer isn't enough

Regex alone catches malformed strings (e.g. missing the version suffix, wrong separator, illegal character) but accepts any syntactically legal name — including a name that's perfectly formatted but typo'd or non-canonical: - onex.evt.router.routing-complete.v1 (canonical) - onex.evt.router.routing_complete.v1 (regex-legal, not canonical — underscore drift) - onex.evt.router.routing-completed.v1 (regex-legal, not canonical — past-tense drift)

The regex says yes to all three. Only the second layer — checking against the enum'd canonical list — distinguishes them.

Enum alone catches non-canonical names but doesn't help discover what shape the canonical name should have, doesn't provide a generative grammar for new entries, and doesn't validate free-text fields within structured names. The regex provides the format contract.

OmniNode's instantiation

The disclosed shape from the OmniNode post:

• Regex pattern: onex.{kind}.{producer}.{event}.v{N}. The segments encode what kind of message (cmd for command, evt for event), which producer service emits it, what specific event it represents, and the version. The regex enforces that every topic name has these five dot-separated segments, with the v{N} suffix mechanically present.
• StrEnum canonical registry: every legal topic name is enumerated as a member of a StrEnum in the codebase. Adding a new topic requires adding the name to the enum. Using a topic requires referencing the enum value.

The combination: a name has to pass both the regex and be in the enum to be accepted at provisioning time. A typo passes the regex but fails the enum; a freshly-invented but mis-formatted name fails the regex even before the enum check.

Why this is more than a style guide

A style guide can specify the canonical shape, but it relies on human discipline to apply. Regex + enum validation makes the rule mechanically enforceable at: - PR review time (CI fails if a new contract uses a name that doesn't pass both checks). - Runtime boot (provisioner refuses to provision a non-canonical topic name). - Post-boot validation (validator detects topics that exist on the broker but aren't in the enum, surfacing orphans).

The mechanical check eliminates the "both names are well-formed and both operations succeeded" failure mode that produces silent wiring failures.

Sibling validation patterns

• concepts/topic-prefix-namespacing-convention — the prefix-only style of structured topic naming, without the enum layer. Cheaper to start; weaker against drift because the prefix is open-ended.
• concepts/schema-evolution — schema-registry-based validation of message payload shape. Complementary to topic- name validation; catches different drift.
• concepts/registry-as-governance-precondition — the general framing that an inventory primitive is upstream of policy. Regex + enum is one way to materialise that registry.

Generalises beyond topic names

The pattern applies anywhere two distributed components have to agree on an identifier: - Service IDs in service-mesh routing. - Resource names in IaC. - Event types in observability pipelines (metrics names, span names, log fields). - Tool names in agent-tool registries (compare concepts/tool-sprawl). - Feature flag keys across application code and flag config.

The unifying property: two layers of mechanical check beat one layer plus a style guide.

Seen in

• sources/2026-06-02-redpanda-how-omninode-uses-redpanda-to-scale-ai-agent-workflows (2026-06-02, OmniNode founder Jonah Gray on Redpanda Blog) — canonical disclosure source. Provides the explicit two-layer framing: "a regex validates the structure, and a StrEnum backs the canonical registry. The regex catches malformed names, while the enum catches names that are syntactically valid but not canonical." The OmniNode topic-name shape onex.{kind}.{producer}.{event}.v{N} is the disclosed regex format; the enum is the canonical-name registry. Together they are the mechanical-validation layer of OmniNode's contract.yaml-as-bus- surface discipline.

Related

• concepts/topic-name-as-coordination-surface — why this layer is needed.
• concepts/silent-wiring-failure — the bug class it catches.
• concepts/contract-yaml-as-bus-surface — the manifest the validation runs against.
• patterns/contract-driven-topic-provisioning — the full pattern.
• systems/omninode — the canonical wiki adopter.