Waiting-on detection: identifying work that depends on someone else

Waiting items are easy to lose because they do not always require immediate action from the user. They sit between active work and completed work.

Vortyx treats waiting on as a first-class work signal. The goal is to help users see what depends on someone else before it disappears into email, messages, notes, or memory.

A waiting item usually has three parts: an expected external actor, a thing expected from that actor, and a reason the item still matters.

Waiting for Priya to approve the launch copy.

This has a clear external actor, expected action, and dependency.

Can you send the updated invoice by Thursday?

This may become a waiting item after the user sends the request, because the next progress depends on the recipient.

I'll get back to you once Legal confirms.

This can indicate a waiting state, but the owner may be indirect. Vortyx should preserve that ambiguity for review rather than assume too much.

Not every unresolved conversation deserves tracking.

Sounds good, thanks.

This does not identify an expected response or dependency.

Let's keep this in mind.

This may be useful context, but it does not clearly say who owes what.

Approved, please proceed.

If the thread previously involved waiting for approval, this message may close the waiting state instead of creating a new one.

Waiting-on detection depends on ownership. Vortyx should distinguish whether the user owes the next action, someone else owes it, ownership is unclear, or the waiting state appears complete.

If the user owes the next action, Vortyx may suggest a follow-up or draft reply. If someone else owes it, Vortyx may suggest a waiting item. If ownership is unclear, the item should remain reviewable. If the thread appears complete, Vortyx should avoid resurfacing stale waiting work.

Waiting items often include timing cues such as by Friday, tomorrow, or next week if we do not hear back. Vortyx can use these cues to suggest due dates, expected response windows, or resurfacing times.

Timing extraction should stay conservative when language is vague. A phrase such as soon is weaker than by Friday and should generally require more review.

A waiting item should be explainable from source evidence. Useful trace fields include the source email, message, thread, or capture; the detected external actor; the expected response, approval, document, decision, or update; any timing cue; and the reason the item is still surfaced.

Traceability helps the user decide whether the suggested waiting item is real or noise.

Vortyx does not need to be perfectly certain to be useful, but uncertainty should be contained. Waiting items should be shown for review, and users can confirm, edit, dismiss, snooze, or mark handled.

Vortyx should not automatically contact someone, send a follow-up, or mark a dependency as active without user review.

Vortyx is currently evaluating these signals with a closed set of users. Quantitative metrics will be published only after there is sufficient repeatable evidence, including a labeled evaluation set, annotation rules, sample size, precision, recall, false-positive rate, and model/version context.