# How Needs You is ordered

Needs You is ranked rather than chronological, because the oldest thing waiting is very often not the most costly thing waiting. Operational faults that stop work outrank individual decisions; a first contact outranks a long-running thread; work with a deadline outranks work without one. The exact weighting is not published, but the classes of signal are these.

- **Status:** Available
- **Audience:** both
- **In the app:** #/needs-you, #/inbox
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/autonomy/needs-you-ranking/

## Why arrival order fails here

A chronological list is honest about one thing only: what happened first. It cannot tell you that the item at position forty is a disconnected mailbox that has stopped a whole channel, while the top thirty-nine are replies that could each wait an hour without anybody noticing. Sorted by time, the most expensive problem in the list is wherever it happens to have landed.

The same argument applies within decisions. A held reply to somebody writing for the first time is a different kind of debt from a held reply on a thread that has been running for a week: the first person has no relationship to fall back on and no reason to assume they were heard. Time waiting alone cannot see that difference.

## The signals that move an entry

| Signal | Direction | Reasoning |
|---|---|---|
| It stops other work | Up, strongly | A mailbox not being read makes every decision under it less complete |
| It has a deadline | Up as the deadline nears | A promised call-back is worthless once it is very late |
| It is a first contact | Up | No relationship absorbs the delay |
| Your own triage marks it important | Up | A person's judgement about a thread is read by the engine, not just displayed |
| It has gone stale | Down | A reply answering a message the customer has already followed up needs regenerating, not releasing |
| Its cause has cleared | Off the list entirely | Entries are derived from live state, not stored as tasks |

> **Note** The fourth row is worth using deliberately. Triage marks live on the conversation itself and the engine reads them when it chooses what to work on, so raising a thread's priority is not decoration — it changes what happens next as well as where the entry sits.

## What the ordering is not

- **Not a published formula.** The classes of signal above are documented; a numeric weighting is not, and any specific score you see quoted elsewhere is not from here.
- **Not a queue you can reorder by hand.** Influence it through triage on the underlying conversation rather than by dragging entries about.
- **Not a filter.** Nothing is hidden by being low; the list is complete, and position is a suggestion about sequence.
- **Not stable across a day.** A deadline approaching or a line degrading changes position without anybody touching the screen.

## Reading it as a workload

1. Work top-down for the first pass and resist filtering.
   - Result: The sequence has already accounted for the things a filter would hide from you.
2. Deal with anything that is blocking a channel before touching decisions.
   - Result: Replies drafted while a mailbox was disconnected may be answering an incomplete picture.
3. For anything with a deadline, decide it or accept it will lapse.
   - Result: A phone commitment more than a day late is closed as missed and is not rung, so leaving it is a decision by default.
4. If the same entry keeps returning to the top, fix its cause rather than its symptom.
   - Result: Derived entries return because the condition returned; deciding the item again changes nothing about the condition.

## Questions

### Can I sort the list by time instead?

The ordering is the product's own judgement about sequence, and the reason it exists is that arrival order buries operational faults. If you want to see one conversation's history in time order, the conversation itself and the timeline are the right screens.

### Does marking a thread important actually change anything?

Yes. A person's triage lives on the conversation record, and the engine reads it when it picks what to work on. It moves both what Connect does next and where the related entry appears.

### Why did something drop down the list without being dealt with?

Usually staleness: the customer wrote again, so a prepared reply now answers an older message and needs regenerating rather than releasing. Sometimes it is relative — something more costly arrived above it.

## Related

- [Needs You](https://connectbyjbrh.com/docs/autonomy/needs-you/)
- [What appears in Needs You](https://connectbyjbrh.com/docs/autonomy/needs-you-kinds/)
- [Approvals](https://connectbyjbrh.com/docs/autonomy/approvals/)
- [Asking before placing a call](https://connectbyjbrh.com/docs/autonomy/ask-before-calling/)
- [Working the Needs You queue, end to end](https://connectbyjbrh.com/docs/workflows/needs-you-triage/)
- [Making a next-best-action defensible](https://connectbyjbrh.com/research/evidence-for-next-action/)

## What this page is based on

- Connect source pack §5 — Needs You is ranked rather than chronological (`docs-source/sources/GENERAL.md`)
- Connect source pack §3 — triage marks live on the canonical rows and the engine reads them
- Connect source pack §7 — the late cut-off on phone commitments
- Connect capability registry (`docs-source/facts.py`) — `needs_you`, `line_health`