Human tasks
How unresolved questions become bounded tasks, how answers are checked, and what happens next.
When a lens cannot resolve something material on its own, Warpway does not ask anyone to "take a look". It creates a human task: one specific question, with everything needed to answer it, sent to the person most likely to know.
What every task contains
A task must have all seven parts below before it reaches anyone. The lens that drafts a task is told what is missing so it can fix the question, and the arbiter rejects any task that still lacks one:
- A concrete question.
- Why it matters: what goes wrong if the answer is one way or the other.
- Why AI could not resolve it: what Warpway looked for and did not find.
- The evidence already gathered.
- The relevant code, as files and line ranges.
- The expected kind of answer, such as yes or no, or one of a few choices.
- The effect of likely answers: what Warpway will conclude for each.
Questions for non-engineers also get a plain-language version without code, which is what Slack shows them.
A rejected task
Review security.
Security confidence is 61%. Please inspect.
Neither says what to decide, why, or what evidence exists.
A good task
Question: Must revoking an administrator role invalidate active sessions immediately?
Why this matters: The new implementation caches authorization results for 15 minutes.
Evidence: Role changes update the database but do not invalidate the permission cache.
Unknown: No code, tests, issue or security document specifies the intended revocation timing.
Relevant code:
permissions.ts:41–72,updateRole.ts:118–136Choose: Immediate revocation / Up to 15 minutes is acceptable / Needs discussion.
Response types
| Type | Key | How it is answered |
|---|---|---|
| Yes or no | yes_no | Two buttons, or a reply. |
| Single choice | single_choice | One of the listed choices. Each choice states what it means for the code. |
| Multiple choice | multi_choice | Any combination of the listed choices. In Slack, reply in the thread with every option that applies. |
| Free text | free_text | A written answer. |
| Approval | approval | A sign-off, used when a lens requires a person to approve it. |
| Discussion | discussion | The question needs a conversation; the task stays open until someone records the outcome. |
Where people answer
- Slack: buttons, or a reply in the thread of Warpway's direct message. See Slack installation.
- GitHub: a pull request comment with
/warpway answer <task ref> <your answer>. Warpway's summary comment lists each open question with its reference, such asT3F4A5B, and any choice ids; for a choice question, answer with the choice id./warpway wrong-person <task ref>tells Warpway you are not the right person. - Dashboard: the task page, which also shows the full evidence and the conversation so far. People without a Warpway account reach it through the signed Open details link in their Slack message.
How answers are checked
Every answer goes through the response sufficiency check before it counts:
| Outcome | Key | What happens |
|---|---|---|
| Sufficient | sufficient | The task is resolved. The exact answer and its normalized meaning are recorded as evidence, and the affected lens is re-evaluated. |
| Ambiguous | ambiguous | Warpway asks one concise follow-up question. The task stays open. |
| Contradictory | contradictory | The answer conflicts with itself or with earlier answers; Warpway asks one follow-up to settle it. |
| Needs follow-up | needs_followup | The answer is partial, or picks an option such as "Needs discussion" that does not record a decision; Warpway asks for the missing part. |
| Declined | declined | The person cannot answer, or says they are the wrong person. Warpway stops asking them and routes the task to the next candidate; if nobody is left, it stays visible and unassigned. |
Only a sufficient answer resolves a task. Button presses and plain answers such as "yes" or "no" are classified by fixed rules; other replies are classified by the model, and a reply it calls sufficient must still state its meaning, and match the listed choices for a choice question, before it counts. If the check cannot run, for example because the model is unavailable, the answer is not recorded as a resolution and the task stays open while Warpway retries.
For example:
Question: Is a 15-minute privilege-revocation delay acceptable?
Reply: Sounds fine.
That reply does not resolve the task, because it could mean the delay is fine or that the change is fine. Warpway follows up once:
To record this unambiguously: Is a 15-minute privilege-revocation delay acceptable? Yes / No.
A plain agreement such as "Looks good" counts as yes only when the question itself asks for a confirmation or an approval, such as a sign-off.
What is recorded
For every resolution Warpway stores who answered, through which channel (Slack, GitHub or dashboard), the message it came from, the exact answer, its normalized meaning, the sufficiency assessment and the time. The answer becomes evidence with human provenance, so every conclusion that depends on it can show where it came from. Warpway's pull request summary then shows it in one line, without exposing the conversation:
✅ Product Semantics: unused credits are preserved after cancellation — answered by Priya in Slack
Task lifecycle
| Status | Key | Meaning |
|---|---|---|
| Unassigned | unassigned | No suitable person was found yet. The task stays visible, with the reason. |
| Pending | pending | Sent to a person, waiting for an answer. |
| Answered | answered | An answer arrived and is being checked. |
| Needs follow-up | needs_followup | A follow-up question was asked. |
| Resolved | resolved | A sufficient answer was recorded. |
| Expired | expired | The assignment timed out without an answer; Warpway asks the next candidate. |
| Cancelled | cancelled | No longer needed, always with a recorded reason, for example because a new commit removed the code in question. |
Tasks are never deleted while your organization exists, and a task never disappears silently. Unassigned, pending, answered and needs-follow-up tasks count as open; a required open task blocks the review policy. A required task that expired keeps blocking too, because its lens still needs a decision.
Required and optional tasks
A task is required when its lens is required and the lens's human sign-off setting is when_uncertain (the default) or always. Lenses set to never produce optional tasks, which are shown but never block. With merge_gate.require_zero_open_human_tasks (on by default), a pull request cannot satisfy policy while a required task is open.
A lens whose human sign-off setting is always gets a sign-off task whenever AI clears it: a person confirms the lens even when AI found nothing. From trust level 3 (Clear), so does a required lens that does not allow AI clearance. A sign-off task never goes to the pull request's author.
Reminders and expiry
If a task is not answered, Warpway sends one reminder after 24 hours. After 72 hours the assignment expires and Warpway routes the task to the next candidate. Admins can change both times in organization settings.
The wrong person
Anyone asked a question can answer I'm not the right person in Slack, or /warpway wrong-person <task ref> on GitHub. Warpway records that, excludes them, and routes the task to the next candidate. If their reply names someone ("ask Priya"), Warpway records the suggestion but never reassigns the task on it automatically. If nobody suitable is left, the task becomes unassigned and stays visible. See Routing.
New commits and earlier answers
Each task records the code regions its question depends on. When new commits arrive:
- if those regions did not change, the earlier answer is reused and nobody is asked again; edits elsewhere in the same file do not count;
- if they changed, the earlier answer is revalidated against the new code; when its assumptions no longer hold, the question is asked again in a new task, and the original keeps its answer for the record;
- a question that is still open carries over with the same person and conversation, so nobody gets a duplicate message;
- answers to tasks from superseded reviews are recorded, but revalidated before they affect the current review.
Saving an answer as organization knowledge
After a task is resolved, an Admin can save the answer as a reusable organization rule:
Save this as a reusable organization rule?
Nothing becomes policy automatically. A saved rule keeps its source (the person, the pull request and lens), records who approved it and where it applies, and can later be deprecated or superseded. Future reviews use it as cited evidence instead of asking again.
Feedback
Every task has feedback controls: Right question, Wrong question, Wrong person and AI should have resolved this. Feedback is used to measure and improve how Warpway asks questions and routes them. It never rewrites your policy on its own.
Something unclear or missing? Email marcus@cmglabs.ai.