talonic_fail_decision_task
Declare that the claimed task cannot be decided. The platform raises a Human Review carrying your reason and applies the app's declared fallback policy: rules (a resident rule set decides — the only policy with a deterministic safety net), hold (the run parks as a system-raised review) or none (the run fails explicitly). The task ends in status failed; the ledger records the fallback decision with fallback: true.
| Parameter | Type | Description |
|---|---|---|
| task_id * | UUID | Claimed task ID. |
| execution_epoch * | integer | Exact epoch from the current claim. |
| reason * | string | Why the task cannot be decided, at most 2,000 characters. Becomes the review's question context, so name the missing or contradictory evidence. |
// talonic_fail_decision_task({
// "task_id": "11111111-1111-4111-8111-111111111111",
// "execution_epoch": 1,
// "reason": "The package carries two supplier names for one invoice and neither matches the purchase order."
// })
{
"id": "11111111-1111-4111-8111-111111111111",
"status": "failed",
"execution_epoch": 1,
"...": "remaining metadata as in the list"
}Fail is for genuinely undecidable tasks — contradictory or insufficient input that no claimant could resolve. A decision you can make with low confidence is better submitted with confidence set: the app's confidence floor routes it to review if needed, and the reviewer sees your outcome and rationale instead of an empty slot. For a rule-mining round driven from outside, fail seals the round as interrupted with your reason and raises no review.