Roadmap: Who knows

Message search finds relevant discussions, but answering "who should I ask about this?" still means opening those discussions and working out who contributed. The people and retrieval foundations in #534 make that answer possible from the archive. This issue tracks Who knows as a focused five-PR delivery, with the evidence and limits visible in every result.

Outcomes

• Ask msgvault person who-knows "kubernetes networking" and get ranked people with dated message citations and an explainable score breakdown. The HTTP API and read-only find_who_knows MCP tool return the same ranking.
• Give authored evidence most of the weight. Decay older evidence, reward breadth across threads and channels, and cap credit for merely receiving messages or attending meetings.
• Show declared ask_me_about topics, optional consented profile similarity, and organization matches as separate boosts. Relationship temperature only breaks ties.
• Surface unsaved contacts separately, with an explicit promotion path. Show organization totals from ranked people's current employment without creating profiles or facts.
• Report embedding coverage, stale contact state, exclusions, and retrieval underfill. Return an explicit empty result when no relevant evidence or matching declared/profile candidate remains.

Delivery sequence

The implementation is in five open PRs. These are review and merge steps, not shipped functionality; merge in this order. All five target main, and later PRs carry prerequisites until earlier steps land.

1. Add bounded topic-evidence reads: participant roles, source-scoped owner detection, sender provenance, declared topics, profiles, and current employment (#1300).
2. Add deterministic ranking, recency decay, authored breadth, capped reception, explicit boosts, stable citations, and graded ranking evaluation (#1301).
3. Connect ranking to one bounded hybrid retrieval pass, saved and unsaved attribution, optional profile search, published relationship temperatures, and coverage reporting. Exercise the real retrieval and Store paths with synthetic data and PostgreSQL vector coverage (#1302).
4. Expose msgvault person who-knows and owner-only GET /api/v1/people/who-knows, including date windows, JSON output, opt-in excerpts, and the generated API contract (#1303).
5. Expose the same result through find_who_knows, gated on people-tool availability and daemon API schema 3.24.0 or newer. Supporting messages open through get_message (#1304).

After the stack lands, calibrate ranking weights and relevance thresholds against representative archive queries and measure warm-index latency with and without date windows. The documented latency budgets are targets, not measured guarantees. Keep this roadmap open until the integrated delivery and evaluation are complete.

Design constraints

• SQLite and PostgreSQL remain behaviorally equivalent. The initial stack adds no archive schema or migration changes.
• Attribute evidence through resolved participants and bound people, never name mentions. Meeting organizers and attendees receive attendance credit; transcript text does not establish speaker authorship.
• Keep ranking read-only and deterministic. No model-inferred expertise, automatic promotion, or writes to person facts.
• Reuse the existing hybrid message index and profile-consent boundary. A ready message vector index is required; there is no silent lexical-only fallback. Topic text reaches the configured embedding endpoint, normally once, with a second call possible on a profile-generation mismatch.
• Bound retrieval and metadata reads. Read citation bodies only when excerpts are requested; MCP offers message IDs instead of an excerpts option. Report underfill rather than silently retrying across the archive.
• Exclude owner identities and automated senders by default; downweight list mail and one-way senders. Preserve sender-authentication provenance so email authorship is not presented as verified identity.
• Keep owner-only access for the initial release. Treat returned archive text as data, never instructions. Public examples and evaluation fixtures use synthetic identities.

Adjacent

• #534 owns the wider people roadmap; this issue owns its Who knows delivery.
• #589 and #656 provide related conversation retrieval and semantic person search. Profile similarity supplements authored evidence here.
• #664 and #668 cover attachment retrieval. Document and visual evidence are later Who knows work, outside this message-based stack.
• Speaker-to-participant resolution, restricted agent access, a web or TUI surface, and retrieval-pool replenishment need separate follow-ups before expanding this contract.