Skip to main content

Built-in assertion library for LLM outputs

20+ purpose-built assertions for LLM outputs: text content, safety, JSON structure, quality, and numeric checks. Use in test suites or standalone.
The assertion library gives you 20+ purpose-built checks for LLM outputs — covering content correctness, safety, structure, style, and performance. Import expect from @evalgate/sdk (TypeScript) or evalgate_sdk (Python) and chain assertion methods directly against any string or value your model produces.

Import

Text and content

These assertions check what the output contains, matches, or excludes.
Deep equality check — the output must exactly match expected.
The output must include substring as a literal substring.
Every keyword in the array must appear in the output. Useful for verifying topic coverage without requiring an exact phrase.
The output must not include substring.
The output must match the provided regular expression.
The output length (in characters) must fall within the specified range.

Safety and compliance

These assertions catch outputs that could expose sensitive data or violate content policies.
The output must not contain personally identifiable information — emails, phone numbers, Social Security Numbers, or similar patterns.
The output must not contain profanity or slurs.
Every fact in facts[] must be grounded in the output. This is a local, heuristic check. Use toNotHallucinateAsync() for an LLM-backed verification.

JSON and structure

These assertions verify the shape and contents of structured outputs.
The output must parse as valid JSON.
Every key in schema must be present in the parsed JSON output.
The output must contain at least one code block (fenced with backticks).

Quality and style

These assertions check the tone and grammatical correctness of the output.
The output’s detected sentiment must match type. Accepted values: 'positive', 'negative', 'neutral'.
The output must not have obvious grammatical issues — no double spaces, missing capitalization at sentence starts, or similar basic errors.

Numeric and performance

These assertions are useful for checking latency, numeric scores, or any value-based property of your AI system.
The measured latency must be less than ms milliseconds.
The value must be greater than n.
The value must be less than n.
The value must fall within the inclusive range [min, max].
The value must be truthy.
The value must be falsy.

Tagging assertions by cost tier

Use withCostTier() to mark each assertion by its execution cost. This lets the runner skip expensive LLM-backed checks in fast feedback loops and include them in nightly or CI runs.
Accepted tiers: 'code' (local, instant) and 'llm' (backed by an LLM judge call).

LLM-backed hallucination check

toNotHallucinateAsync() sends the output and facts to a judge model for a deeper grounding check. It is async and counts against your judge token budget:
toNotHallucinateAsync() requires a configured judge. Make sure EVALGATE_API_KEY is set before calling it.

Using assertions in a test suite

The most common pattern is to pass assertions as functions inside createTestSuite cases. Each assertion receives the executor’s output and returns a result: