---
name: domain-validator
description: Validate agent output against declared domain rules and ground truth before trusting it downstream. Trigger after any agent produces output that will be used in a decision, stored persistently, or passed to another agent.
---

# Domain Validator

> **Agent output is a hypothesis. Domain validation is the test.**

An agent that produces output without validation is a system that produces hallucinations at scale. The domain validator is the check that separates "the agent said so" from "it is true."

## When to use

- After an agent produces output that feeds a downstream system or human decision
- When an agent has reasoned over domain-specific data (financial figures, medical records, legal clauses, system configurations)
- Before persisting agent-generated content to a database or document store
- When an agent output will be presented to an end user as factual

## Procedure

1. **Declare the domain rules** — before running any validation, the domain rules must be explicit:
   - What are the invariants? (e.g. "a date range must have start < end", "a price must be positive", "a configuration must reference an existing resource")
   - What are the allowed value ranges or enumerations?
   - What is the ground truth source? (database record, API response, regulatory document, schema definition)

2. **Extract the claims** — identify the specific assertions in the agent output that are subject to validation. Not every word in the output is a claim; focus on structured data, named values, and factual assertions.

3. **Validate each claim against the domain rules**:
   - **Structural validation**: does the output conform to the expected schema or format?
   - **Range and constraint validation**: are values within allowed bounds?
   - **Referential integrity**: do referenced entities exist in the ground truth source?
   - **Logical consistency**: are the claims internally consistent? (e.g. no contradictory figures)
   - **Freshness**: is the ground truth source current, or could it be stale?

4. **Classify findings**:
   - **PASS**: claim is valid against all domain rules
   - **WARN**: claim is plausible but cannot be fully verified (e.g. ground truth unavailable)
   - **FAIL**: claim violates a domain rule or contradicts ground truth

5. **Produce a validation report** — for each claim: status (PASS/WARN/FAIL), the rule checked, and the evidence.

6. **Gate downstream use** — FAIL findings block downstream use of the output. WARN findings require explicit human acknowledgement before proceeding. PASS findings may proceed automatically.

## Outputs

- Validation report: claim | status | rule checked | evidence
- Overall verdict: PASS / WARN / FAIL
- List of FAIL and WARN findings for human review

## Guardrails

- **Domain rules must be declared before validation runs.** Validating against implicit rules produces false confidence.
- **WARN is not PASS.** A WARN finding means uncertainty, not safety.
- **Ground truth must be identified.** If there is no ground truth source, the output cannot be validated — flag this explicitly rather than assuming it is correct.
- **Validation is not proofreading.** Grammar and style are not domain rules. Focus on factual and structural correctness.

## Anti-rationalization table

| Excuse | Counter |
|---|---|
| "The model is reliable enough" | Reliability is a statistical claim. Domain validation is a deterministic check. Run it. |
| "We'll catch errors in review" | Human review misses structured errors that automated validation catches. Both are needed. |
| "The domain rules aren't defined yet" | Then the output cannot be trusted yet. Define the rules before relying on the output. |