ai-feature-validation

AI Feature Validation

The Law

AI FEATURES HAVE FAILURE MODES THAT DETERMINISTIC FEATURES DO NOT.
"We validated it like any other feature" misses hallucination UX, trust calibration, scope creep, and irreversibility — none of which appear in a standard acceptance criterion.
All four AI-specific risks addressed in the PRD IS AI feature validation.

When to Use

Trigger before:

• Approving any AI feature for development
• Adding an LLM call to any user-facing surface
• Expanding an existing AI feature's scope or capability
• Reviewing a PRD that includes AI-generated content, predictions, or decisions

When NOT to Use

• Backend AI pipelines with no user-visible output (use ai-safety-review from builder-ai instead)
• Features where the model output is filtered through deterministic rules before reaching users (the rules are the product; validate the rules)

The Four AI-Specific Risks

Standard PRD review asks: does the feature solve the user problem? AI feature validation asks four additional questions that standard PRDs never reach.

Risk 1 — Hallucination UX

What does the product look like when the model is wrong?

Every AI feature produces incorrect outputs. The question is not "will it hallucinate?" but "what does the UX do when it does?"

Required answers in the PRD:

• What is the worst plausible incorrect output for this feature? (e.g., "a medical dosage that is wrong by an order of magnitude")
• What does the user see when the model is wrong? Is it distinguishable from a correct output?
• Is there a confidence signal that alerts users to lower-confidence outputs?
• Is there a correction mechanism — can the user flag, override, or report an incorrect output?
• For high-stakes domains: is there an explicit disclaimer at the point of use?

BLOCK if:

• Incorrect outputs are visually identical to correct outputs with no uncertainty signal
• There is no correction mechanism for high-stakes outputs (medical, legal, financial, safety)