verified-task（已验证的任务）

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

1. Define the task specification

* what should be produced * required constraints * acceptance criteria

1. Generate output

1. Verify output against the specification

* compare expected vs actual * check completeness and correctness * identify missing requirements or mismatches

1. Return a verdict

* PASS → safe to proceed * FAIL → reject, retry, or revise * INDETERMINATE → stop and review

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