promptfooconfig.yaml into the LLM Eval Test-Case Builder, or build one in its form. It checks the file against the promptfoo 0.123.1 config schema and then reports four faults that schema accepts: an assertion type promptfoo does not have, a {{variable}} a test never sets, a model-graded check with no grader pinned, and a score threshold outside 0 to 1. Fix them in the form, download the file, and run npx promptfoo@latest eval yourself. The tool never calls a model.An eval that fails loudly is the easy case. The expensive one passes. A test named “Digital goods are not refunded” goes green on every run because the customer message it was meant to send never reached the prompt, and the model answered a question nobody asked. Nothing in the output says so. The config parsed, the provider answered, and a not-icontains check had nothing to object to.
This is a short, realistic promptfoo config. It sets a shared refund policy in defaultTest and adds two test cases:
description: Refund assistant\nprompts:\n - |\n You answer refund questions for an online store.\n Policy: {{policy}}\n Customer message: {{message}}\nproviders:\n - openai:gpt-5-mini\ndefaultTest:\n vars:\n policy: Refunds within 30 days of delivery. Digital goods are not refundable.\ntests:\n - description: Late refund request is declined\n vars:\n message: I bought a jacket 45 days ago. Can I return it?\n assert:\n - type: contain\n value: 30 days\n - type: llm-rubric\n value: Declines politely and explains the 30-day window.\n threshold: 80\n - description: Digital goods are not refunded\n vars:\n customer_message: Please refund the e-book I bought yesterday.\n assert:\n - type: not-icontains\n value: refund has been issuedEvery key in it is one promptfoo accepts, and every value has an accepted type. Checked with Ajv against the JSON schema published at the 0.123.1 tag, it validates. Choose Import YAML in the builder, paste it, and select Import config. The Findings panel lists one error, three warnings and one note:
\n\nerror tests[1] \"Late refund request is declined\" › assert[1]\n \"contain\" is not an assertion type in promptfoo 0.123.1. The schema accepts any\n string here, so `promptfoo validate` passes and the eval fails with \"Unknown\n assertion type\". Did you mean \"contains\"?\nwarning tests[1] \"Late refund request is declined\" › assert[2]\n The threshold is 80, but the score it is compared with runs from 0 to 1.\n Nothing can reach it, so this always fails.\nwarning tests[1] \"Late refund request is declined\" › assert[2]\n 1 model-graded assertion has no grader. [...]\nwarning tests[2] \"Digital goods are not refunded\"\n This test never sets {{message}}, which prompt 1 uses. [...]\ninfo vars.customer_message\n \"customer_message\" is set but no prompt or assertion reads it.The misspelt type. In promptfoo's own zod definitions, AssertionTypeSchema is a union that ends in an unrestricted z.custom(), and the published JSON schema ends the same union with an empty {}. Any string is a valid type. The check happens only when the assertion runs: the dispatcher in src/assertions/index.ts finds no handler for contain and throws Unknown assertion type: contain. The builder carries the 66 base types from the 0.123.1 schema, their not- forms, and the special types select-best, human and max-score, and suggests the nearest match for anything else.
The renamed variable. The second test sets customer_message, but the prompt reads {{message}}. promptfoo renders prompts with Nunjucks, and its getNunjucksEngine helper leaves throwOnUndefined at false, which the Nunjucks API documents as its default. An undefined value renders as an empty string. The model receives “Customer message:” followed by nothing, and a negative check such as not-icontains passes against almost any reply to a blank message. The builder reads the root name of every {{ }}, {% if %} and {% for … in … %} in the inline prompts, subtracts the vars in defaultTest and the test itself, and warns per test. It leaves out names promptfoo supplies, such as env and _conversation. In the form, a test that is missing variables shows an Add missing {{message}} button.
The threshold of 80. The llm-rubric grader is asked for a score from 0.0 to 1.0, and in 0.123.1 the grading code sets pass = pass && score >= threshold. A threshold of 80 reads naturally as a percentage and can never be met. The builder applies this range check only where the threshold really is a 0 to 1 score: llm-rubric, g-eval, similar, the context and relevance graders, ROUGE, BLEU and a test-level or assert-set threshold. For latency the threshold is milliseconds, for cost it is dollars and for levenshtein it is an edit count, and none of those are flagged for exceeding 1.
A key promptfoo does not know. This sample has none, but the commonest one is asserts: for assert:. The published JSON schema marks the config, each test and each assertion as closed objects, so an editor that honours the yaml-language-server comment underlines the typo. promptfoo's loader does not complain. TestCaseSchema is a plain z.object(), and zod strips keys it does not recognise instead of failing, so validate passes and the test runs with no assertions at all. The builder reports every unknown key as an error.
The missing grader. With no provider on the assertion, the test's options or defaultTest.options, llm-rubric picks its grader from whichever credentials are present. The docs list gpt-5 for an OpenAI key and claude-sonnet-4-5-20250929 for an Anthropic key, among others. A laptop with one key and a CI runner with another grade the same output with different models. This one is a warning rather than an error because --grader on the command line is a legitimate fix the builder cannot see.
contain to contains in its dropdown. The dropdown groups the common types as deterministic, model-graded and performance checks, and the not- checkbox beside it negates any of them.0.8.customer_message to message in the second test.openai:gpt-5-mini into Grader for model-graded checks. It is written to defaultTest.options.provider, so every rubric in the file uses the same judge.promptfooconfig.yaml.The changed parts of the exported file:
\n\ndefaultTest:\n vars:\n policy: Refunds within 30 days of delivery. Digital goods are not refundable.\n options:\n provider: openai:gpt-5-mini\ntests:\n - description: Late refund request is declined\n vars:\n message: I bought a jacket 45 days ago. Can I return it?\n assert:\n - type: contains\n value: 30 days\n - type: llm-rubric\n value: Declines politely and explains the 30-day window.\n threshold: 0.8\n - description: Digital goods are not refunded\n vars:\n message: Please refund the e-book I bought yesterday.Run the file where your API key lives. promptfoo validate is still worth the second it takes. It rejects faults the builder also reports, such as a variable left as a bare message:, which YAML reads as null, or a file with neither providers nor targets, before any tokens are spent:
npx promptfoo@latest validate -c promptfooconfig.yaml\nnpx promptfoo@latest eval -c promptfooconfig.yamlIf the suite asserts latency, the run command shown under the YAML gains --no-cache. The latency handler throws on a cached response, which has no timing to measure. A latency or cost assertion without a threshold is reported as an error for the same reason: both handlers throw rather than guess.
Anything the form does not model survives an import. Transforms, rubricPrompt, evaluateOptions, env, test metadata and file:// test references are carried through and written back unchanged, so the builder can be used on an existing suite without flattening it.
promptfoo loads a CSV of test cases with tests: file://tests.csv. Ordinary columns become vars, and each __expected column holds one assertion written as type: value. Add tests from CSV parses the rows the way src/csv.ts in 0.123.1 does and shows the result as editable test cases:
message,__expected1,__expected2\n\"Can I return shoes after 10 days?\",\"contains: 30 days\",latency\n\"Refund my gift card\",\"contain: not refundable\",\"latency(3000)\"Two of those four cells do not mean what they appear to. contain: not refundable does not match the parser's pattern of known types, so it falls through to the default and becomes an equals check on the entire string contain: not refundable. It fails on every output with no hint of why. A bare latency matches, but the parser supplies a default threshold of 0.75 to latency, cost and several other types when none is written in parentheses. That is a 0.75 ms budget. The builder warns on both cells; latency(3000) is the form that means three seconds.
It works on text in the config and nothing else. A prompt loaded with file://prompt.txt is not opened, so variables inside it are not compared with the tests, and the builder says so in a note rather than pretending the check passed. The same applies to vars loaded from files.
It does not run your javascript or python assertions, compile your JSON Schema against real outputs, or know which environment variables your CI runner exports. It cannot tell whether a model will wrap JSON in a Markdown fence, which makes is-json fail because that type parses the whole output; contains-json accepts embedded JSON.
The rules are pinned to promptfoo 0.123.1, the current release on 1 October 2026. npx promptfoo@latest will move on, and an assertion type added in a later version will be flagged as unknown here until the tool's list is updated. The version is printed in the page and in the YAML header so a mismatch is visible.
Should CI use promptfoo@latest? For a gate that decides merges, pin the version you validated against, for example npx promptfoo@0.123.1 eval, and upgrade on purpose. @latest is fine for a local run, but it changes the evaluator under a suite that has not changed.
What does weight: 0 do? promptfoo marks an assertion with weight 0 as passed whatever it finds, which is useful for recording a metric without gating on it. The builder notes it so it is not mistaken for a disabled check.
Where does a schema for is-json come from? Write it from the output contract, or start from a captured response in the JSON to Schema Generator and review which fields are really required, as described in Review Required Fields in a Generated JSON Schema. Paste it into the assertion's value box as JSON or YAML; the export writes it as a mapping.
Is the builder a YAML formatter? No. A YAML parser can say the file is well-formed, which is the check in Review YAML Conversion Before Changing a CI File, but not that asserts should be assert. For a generated eval target, the reviewing habits in Review AI-Generated Playwright Tests Before You Merge Them translate directly into assertions: a not-contains on waitForTimeout is one line.
Import the promptfoo config your team runs most often. Resolve every error, then read each missing-var warning against the test's description: those are the tests most likely to have been passing without testing anything. Pin a grader, save the file, and run validate followed by eval. Keep the Findings list from before the fix in the pull request, so a reviewer can see which green results were never real.
not- negation, weights, test thresholds, and weight 0 passing automatically.contains-any lists, is-json with a schema, latency needing --no-cache, cost thresholds.__expected column syntax.validate, --no-cache, --grader and -r.src/csv.ts: the __expected parser, its fallback to equals, and the 0.75 default threshold.src/assertions/index.ts: the “Unknown assertion type” error at run time.throwOnUndefined defaults to false.