Verification Before Action — The No-Trust, Verify Manifesto

"Trust, but verify" is cute for international diplomacy. For AI systems that can email your clients or sign off on invoices? Verification before action is non-negotiable.

We just learned how to measure model quality (Evaluation, Metrics, and Quality Control) and how to squeeze hallucinations into a tiny box (Hallucination Containment). Now we take the next logical step: don’t let your model do anything meaningful until you verify that its output is correct, safe, and legally usable. This subtopic is the operational muscle that turns monitoring and containment into real-world reliability.

Why Verification Before Action Matters (and why you should care)

• Safety: A wrong or misleading action can cause harm (financial, reputational, or physical). Verification reduces those risks.
• Compliance: You may be legally required to confirm facts or license status before reuse (hello, Copyright & Licensing concerns).
• Trust: Users need predictable systems. Verification creates reproducible guardrails people can depend on.

Imagine your assistant automatically files an expense report with a forged receipt, or sends a medical recommendation based on hallucinated facts. Evaluation metrics tell you how often that might happen; verification prevents it in the moment.

What to Verify (short checklist)

1. Factual accuracy — Is the claim true? Can it be supported by reliable sources?
2. Source provenance — Where did the information come from? Is the source authoritative?
3. License & reuse status — Is this material copyrighted, or cleared for reuse? (Tie-in: Copyright/Licensing)
4. Intent & permissions — Is the requested action allowed for the user? Does it exceed privilege?
5. Safety & policy compliance — Does the action violate safety rules or content policy?
6. Operational constraints — Will this action break downstream systems (format, sizes, rates)?

Practical Verification Techniques (the toolbox)

1) Automated factual checks

• Use retrieval-augmented generation (RAG): fetch evidence, then match the model's claim to the evidence.
• Run claim-evidence scoring models that output a confidence score for the claim.

2) Multi-model consensus

• Have two independent models (or different prompt styles) answer; accept action only if they agree within tolerance.

3) Specialized verification models

• Smaller models fine-tuned specifically to verify facts, citations, or license text are cheap and fast.

4) External validators and APIs

• Cross-check against authoritative APIs (governmental registries, DOI resolvers, licensing databases).

5) Human-in-the-loop (HITL)

• Route uncertain or high-stakes cases to human reviewers with annotated context and quick-verification tools.

6) Rule-based and schema checks

• Validate outputs against strict schemas, allowed-value lists, or regex patterns (useful for invoices, addresses, code execution inputs).

A Simple Verification Pipeline (step-by-step)

1. Model produces candidate output.
2. Automated checks: schema validation + quick lookup + license check.
3. Evidence retrieval: fetch top-N sources relevant to claims.
4. Verification model: compute claim-to-evidence alignment score.
5. Decision node: if score >= threshold AND no policy triggers -> execute. Else -> human review or block.

Pseudocode (wrapper)

def verify_and_execute(action, user, data):
    candidate = model.generate(action, data)
    if not schema_validate(candidate):
        return escalate('malformed')
    evidence = retrieve_evidence(candidate)
    score = verification_model.score(candidate, evidence)
    licence_ok = license_check(evidence)
    if score > THRESH and licence_ok and policy_ok(candidate, user):
        return executor.run(candidate)
    elif is_high_risk(candidate):
        return human_review(candidate, evidence)
    else:
        return block('failed verification')

Prompt Patterns & Templates (because prompts are the duct tape of AI)

Prompt for verification model:

Claim: "{claim_text}"
Sources: {list_of_sources}
Task: For each claim, output: {"verdict": "SUPPORTED|REFUTED|UNVERIFIABLE", "confidence": 0.0-1.0, "evidence_snippets": [...] }

Human review summary template:

• Claim: ...
• Top evidence (source + quote + URL):
• License status: [OK/Requires permission/Unknown]
• Recommendation: [Approve/Reject/Needs more research]

Metrics to Track (builds on Evaluation & QC)

• Verification Precision: fraction of accepted actions that were actually correct.
• False Acceptance Rate (FAR): actions accepted but wrong — terrifying metric.
• Calibration Error: does the model's confidence reflect reality? (Use ECE — expected calibration error.)
• Human Escalation Rate: percentage of cases routed to humans. Useful for ops planning.
• Latency: time-to-verify; crucial for UX.

Tie these back into your monitoring dashboard so you can close the loop: if FAR increases, raise thresholds or add more validators.

Trade-offs & Operational Patterns

• Fail-closed vs Fail-open: For high-risk domains (medical, legal, finance), default to fail-closed (block) when verification fails. For low-risk tasks, fail-open with a clear UX caveat may be acceptable.
• Latency vs Safety: More rigorous checks add time. Use tiered verification: quick checks for small actions, deep checks for large ones.
• Human cost: Minimize human work with better automated validators and effective UI for quick reviews.

Table: Quick Comparison of Verification Methods

Red Teaming and Continuous Improvement

• Regularly run adversarial tests: how can outputs appear verified while being false? (Credential spoofing, manipulated sources.)
• Expand negative examples in verification model training to reduce clever failures.
• Log everything: provenance, intermediate evidence, verifier outputs — for audits and learning.

Closing: Your Practical Playbook

1. Define what must be verified for each action type. Not all actions need the same scrutiny.
2. Implement a layered verification pipeline: quick + evidence + verifier + decision.
3. Monitor verification metrics and tie them into your evaluation dashboard.
4. Use humans strategically: for edge cases and models’ blind spots.
5. Don’t forget licensing: fetch and check source licenses as part of retrieval.

Final, not-cute thought: verification isn’t an optional extra. It’s the difference between a chatbot that helps you and a chatbot that gets you sued. Build verification like you’d build a seatbelt — because when incidents happen, you don’t want to be the engineer who said “we’ll fix it later.”

Version notes: This lesson builds on hallucination containment and the metrics-based approach to quality control. Treat verification as the runtime enforcement of those earlier principles.