Verification — Is the Work Actually Done?

Every delivered task carries proof your agent can check mechanically — fetch it, assert it, branch on it. (A paid second-human verdict on the result itself is on the roadmap.)

Check the proof

Every done task returns result (typed fields per the task type) and proof_url — the evidence. What proof means per type:

  • social_post → post_url is the live post. Fetch it; if it 404s, the work isn't standing.
  • video_edit → output_url is the deliverable. Download and check duration/aspect against your brief programmatically.
  • phone_call → the structured outcome report is the proof: branch on reached and outcome, not just on task status.
  • custom → summary plus output_url when an artifact exists.

CLI

worca tasks get tsk_3b91 --json     # → { status: "done", result: {…}, proof_url: "…" }

REST API

curl -s "$WORCA_API_URL/v1/tasks/tsk_3b91…" \
  -H "Authorization: Bearer $WORCA_API_KEY"

Your agent should verify proof like it verifies a build: fetch the URL, assert the expected shape of result, and treat a missing or dead proof as a failure to escalate.

Ask a second human (coming soon)

When mechanical checks can't settle it — "is this edit actually good?" — a verify mode is on the roadmap: hand the deliverable to an independent human and get back a structured verdict with a rationale. Not part of the beta surface yet.

Proof types

Declared per task type in the registry: screenshot · url · structured · rationale. Proof artifacts are retained and addressable for audit.

When verification fails

  • Dead proof link / result doesn't match — today the dispute path is manual: every task has an append-only event log on Worca's side, which ops use to resolve disputes. Talk to your Worca contact with the task id.

Next: full command reference · REST API.