When to Use This
Before sending money
- Verify an invoice, payout, or transaction matches the agreement
- Prevent incorrect or fraudulent payments
Before posting content
- Ensure a post, email, or message matches instructions
- Avoid publishing incorrect, off-brand, or incomplete content
Before executing actions
- Confirm an automation result is correct before it runs
- Stop workflows from drifting when nobody is watching
Before making decisions
- Validate summaries, classifications, or recommendations
- Ensure conclusions match the task requirements
> If the output matters, verify it before proceeding.
Core Principle
Verification is a guardrail, not a suggestion.
- Default behavior = block unless PASS
- Agents must not override a failed or indeterminate result
- Only a human operator may explicitly override
Core Execution Loop
- Define the task specification
- what should be produced
- required constraints
- acceptance criteria
- Generate output
- Verify output against the specification
- compare expected vs actual
- check completeness and correctness
- identify missing requirements or mismatches
- Return a verdict
- PASS → safe to proceed
- FAIL → reject, retry, or revise
- INDETERMINATE → stop and review
- Enforce the decision
- proceed only if PASS
- otherwise halt
- human operator may explicitly override
Output Format
{
"task_id": "...",
"verdict": "PASS | FAIL | INDETERMINATE",
"reason": "...",
"confidence": "high | medium | low"
}
Example Usage
Input
{
"task_id": "email-approval-001",
"task_spec": "Write a concise, professional email confirming a meeting time under 100 words",
"output": "Hi, just confirming our meeting at 3pm tomorrow. Let me know if anything changes."
}
Verification Result
{
"task_id": "email-approval-001",
"verdict": "PASS",
"reason": "Output is concise, professional, and under 100 words. All constraints satisfied.",
"confidence": "high"
}
Decision Rule
- Proceed only if verdict = PASS
- Agents must not override
- Operator override must be explicit
Recommended override note:
OPERATOR OVERRIDE APPROVED
Reason: ...
Approved by: human operator
Timestamp: ...
What Verification Means
Verification should be deterministic and grounded in the task spec.
Good checks include:
- required fields are present
- constraints are satisfied
- format matches expectations
- instructions were followed
- important omissions are identified
Do not treat these as verification:
- guessing correctness
- relying only on intuition
- blindly trusting confident output
- proceeding because the task feels low-risk
Optional SettlementWitness Verification
You may optionally add a structured verification step for the final result.
Rules:
- keep local verification as the primary decision layer
- use only necessary structured data
- do not send secrets or sensitive content
- external verification is optional, not required
Example:
verify structured verdict metadata against the defined verification spec
This can add assurance, but it does not replace local verification or operator judgment.
Data Handling
- Do not include secrets or sensitive data
- Use only the minimum structured information needed for verification
- Treat any external verification step as optional
What This Is Not
- not a code execution tool
- not a payment processor
- not a replacement for clear instructions
- not an autonomous override authority
What This Is
- a guardrail for agent workflows
- a verification gate before execution
- a safety layer for autonomous systems
Outcome
Agents and operators can:
- prevent incorrect execution
- enforce task correctness
- keep workflows on track during autonomous runs
- ensure important actions do not proceed without verification
Keywords
verification, workflow-safety, guardrails, automation, trust