Loading page
About this tool
Define allowed values once and get the matching LLM prompt rule, JSON Schema enum, TypeScript union, Zod, Pydantic and SQL CHECK.
The Enum Constraint Builder turns one list of allowed values into every artefact that must agree with it: an LLM prompt rule ordering the model to answer with exactly one value verbatim, a JSON Schema enum (draft 2020-12, where matching is exact and case-sensitive), a TypeScript string union, a Zod enum, a Python typing.Literal and a SQL CHECK constraint. It is for developers building structured LLM outputs who are tired of the prompt, the validator and the database silently drifting apart.
Open Enum Constraint Builder on AltFTool — it loads instantly in your browser.
Enter the Field name and paste your Allowed values (comma or newline separated), optionally setting a 'Fallback value when unsure' and ticking 'Collapse values that differ only by case'.
Check the Allowed values count of distinct members after de-duplication and any Consistency warnings, which flag values differing only by case.
Read the generated Prompt rule, JSON Schema, TypeScript union, Zod, Pydantic / typing.Literal and SQL CHECK constraint blocks, then press Copy all to take every artefact at once.
Prompt, JSON Schema, TypeScript, Zod, Pydantic and SQL are all emitted from the same de-duplicated list.
Warns when values differ only by case, because JSON Schema enum matching is case-sensitive.
The prompt rule always says what to answer when nothing fits — a chosen fallback or a detectable ERROR token.
Combine two layers: a prompt rule listing the exact values and ordering the model to copy one verbatim with no explanation, and a JSON Schema enum (or provider structured-output mode) that validates the response. The prompt alone is a request, not a guarantee — always validate.
Yes — the enum keyword requires the instance to equal one of the listed values exactly, so "Open" does not match "open". That is why prompt rules should tell the model to copy the value with the same spelling and case, and why label sets differing only by case are a defect.
Give it an explicit escape hatch: either add a real member like "unknown" or "other" to the enum, or instruct it to output a fixed token such as ERROR that your code detects and handles. Without one, models pick the least-wrong value and the mistake is invisible downstream.
Yes — a SQL CHECK constraint (or a native enum type) mirroring the schema list is the last line of defence when application code or a model slips a bad value through. The generated CHECK uses standard IN-list syntax with single quotes doubled, which works across PostgreSQL, MySQL and SQLite.