Human tasks

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:

1. A concrete question.
2. Why it matters: what goes wrong if the answer is one way or the other.
3. Why AI could not resolve it: what Warpway looked for and did not find.
4. The evidence already gathered.
5. The relevant code, as files and line ranges.
6. The expected kind of answer, such as yes or no, or one of a few choices.
7. The effect of each offered answer: what Warpway will conclude, including an answer that leaves the decision unresolved.

New questions also record the decision they support: which applicable review requirement is waiting, the missing fact, why the answer is necessary, and who can supply it. Warpway checks requirement references against the current trusted review plan and applicable organization rules. The task page, pull request cards and signed details link show this record alongside the actual routing explanation. Earlier questions without a record are labeled as such and retain conservative policy handling.

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–136

Choose: Immediate revocation / Up to 15 minutes is acceptable / Needs discussion.

Response types

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 as T3F4A5B, 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:

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

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 advisory tasks

A decision task is required when its answer holds back an applicable required review decision and its lens allows human decisions through the human sign-off setting. Code, tests, linked context, trusted knowledge and valid earlier answers should be investigated first. A missing source file or low certainty alone is an investigation gap, not a proven defect or a product decision.

Explicit advisory questions remain visible and answerable without blocking a required review decision. A completed investigation can include advice. Declaring a question advisory cannot clear an unresolved required investigation, replace missing evidence or bypass configured signoff. An earlier question with no decision record retains its existing conservative classification. With merge_gate.require_zero_open_human_tasks (on by default), a pull request cannot satisfy policy while a required blocking task is open.

Compatible questions can be consolidated across lenses while retaining requirement records, evidence, attribution and the original decision effects. Different response contracts, required versus advisory decisions, and different explicit rule ownership retain separate task identities.

Separate questions for the same person and pull request can share one delivery request. In Settings → General, an Admin can set a fixed grouping window from 0 to 120 seconds (30 seconds by default). Send required questions immediately is enabled by default: required questions bypass the wait and include other already available questions. Later arrivals do not extend the original deadline.

In Slack, each question keeps its own reference, buttons and authenticated details link. When more than one question remains unanswered in a request, start a written thread reply with its reference, for example T123ABC Keep the unused credits. An ambiguous reply asks for a reference and applies no answer. A full task ID or its details link works if short references collide. Answering one question leaves the others available; valid carried questions keep their existing conversation and original answer provenance.

Later questions are announced in the same Slack thread. On GitHub, a grouped comment names the recipient and lists each question; later questions receive a new notifying comment. The canonical review summary remains current and shows grouped recipients without another direct mention. Requests hold at most 20 question memberships. Every question retains its own routing, authorization, response contract and resolution. Delivery failure is visible and falls back to GitHub or the dashboard; it never answers a question.

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.

An otherwise optional lens with explicit required signoff is shown as a dependency of required policy. Calling its investigation optional never makes the configured signoff optional.

Reminders and expiry

If a task is not answered, Warpway sends one reminder after 24 hours. Due, unanswered questions in the same Slack request share a reminder; answered questions are excluded. After 72 hours the assignment expires and Warpway routes the task to the next candidate. Admins can change both times in organization settings.

In Settings → General, an Admin can enable business hours and choose an IANA time zone, working weekdays, local opening/closing times, holiday dates and a response target. Existing organizations keep elapsed-hour waiting until business hours are enabled. The suggested calendar is UTC, Monday–Friday, 09:00–17:00; choose the calendar your responders work.

With business hours enabled, response, reminder and escalation intervals count time inside those working windows. Weekends and holidays do not count. A reminder or reassignment that is due while the business is closed waits for its next opening. Daylight-saving changes follow the chosen time zone: repeated working hours count their actual elapsed time; missing boundary times advance through the clock change. A calendar edit recalculates from the assignment or last follow-up, so saving settings does not restart the wait.

An open task's Next actions panel shows its waiting basis, time zone, response target, next reminder and escalation time. Targets are planning goals. Expiry, silence or a failed delivery never resolves the question or supplies approval; the required task stays unresolved until it is answered or an authorized person takes an explicit action.

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.