Analyse a gene list typed into the chat

[adamjohnwright]

Asked "can we do a gsa analysis in the chat. I want to do it with genes TP53, ERBB2 and RUNX2", the chat replied with upload instructions for an expression matrix. Three genes are not a matrix. What Reactome runs on a gene list is over-representation analysis, and the Analysis Service runs it in about a second, so the chat now offers to do it.

What the reader sees

1. An offer, not a run. The reply explains that a gene list means over-representation rather than GSA, and lists exactly the identifiers it read. Then it shows Run it and No, answer my question. The reader can click either, type yes, or keep typing.
2. Run shows "Matched N of M", the top 10 pathways by FDR (names escaped, stable IDs shown), and a link to the result in the Pathway Browser of the service that holds the token (beta by default). Unmatched identifiers are listed. Small lists get a caution.
3. Follow-ups work. The exchange is seeded as the thread's previous turn. Checked in a browser: "which has the lowest FDR?" is answered from the result.
4. No:
   • a message that asked about GSA gets the matrix instructions, without the gene-list line (so the declined list is not offered again);
   • anything else goes to the model, as before.

Why it asks first

Recognising a request is a heuristic. The first version ran immediately, and review found it answered 14 of 44 ordinary questions ("Could you explain why IFNG and TNF are enriched…") with a results table. With the offer, a misfire costs one click, and the reader sees what will be submitted before anything is sent.

Three rounds of adversarial review

• Round 1 — the recogniser. False positives and misses, plus shouting detection firing on gene symbols themselves.
• Round 2 — speed and flow.
  • Quadratic parsing: a 4,000-gene paste took 38 s, and 40,000 newlines took 24 s, on the shared event loop.
  • Trailing sentences were read as genes.
  • AskActionMessage locked the message box until a click.
  • No looped back to the offer.
• Round 3 — the button flow.
  • Resume crashed: offers lived in user_session, which is saved as JSON, so cl.Action came back as null.
  • Button callbacks ran with no task (no Stop, errors swallowed).
  • A stale typed yes could run an old offer.
  • More trailing-word cases.

Everything found is fixed, and each fix has a test that fails when the fix is removed (sabotaged and checked).

Measured rates

The phrase sets are in tests/analysis/gene_list_phrases.py, with where each came from. The honest numbers come from sets written after each rewrite and never tuned against:

Set	Requests read exactly	Questions that trigger an offer
1	15/15	0/20
2	11/12	1/15
4 (latest)	9/10	0/12

Round 3's own fresh set had 4/20 questions trigger an offer before the last fix. The remaining wrong cases are pinned in KNOWN_LIMITS. Pasted tables are one of them: attach the file instead.

Performance

Parsing is a single pass. Gap patterns are possessive, and messages are capped at 60K characters. Timing tests cover each pathological input the reviews found; the worst of them now runs in tens of milliseconds.

Verified

• ./checks.sh (the same as CI) passes.
• 23 browser checks pass against a local instance on the beta network, including:
  • the exact message from the report;
  • Run, typed yes, and No (with both routes);
  • an older offer's Run;
  • typing on without answering the offer;
  • Stop shown and sending blocked while a declined question is answered;
  • three question-shaped controls;
  • the Pathway Browser link opening the analysis.

Data

The identifiers go to Reactome's Analysis Service (beta by default, per ANALYSIS_BASE_URL). The seeded turn goes to the model provider on the next message. The reader typed the list into a chat whose every message already goes there.

🤖 Generated with Claude Code