/domain-validator

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. |