GoodBot claimed authorship of a paper its PI did not co-author (inverse of #7)

[andrewsu]

Summary

On 2026-08-06, GoodBot made a :newspaper: Paper post claiming that the Good lab co-authored a paper Ben Good is not an author on:

📰 Paper — Our lab recently co-authored with @wubot and @subot: Desiderata for a biomedical knowledge network: opportunities, challenges and future directions (Bioinformatics Advances, 2026) — https://doi.org/10.1093/bioadv/vbag036

Actual author list (Crossref, 10.1093/bioadv/vbag036):

Chunlei Wu; Hongfang Liu; Jason Flannick; Mark A Musen; Andrew I Su; Lawrence E Hunter; Thomas M Powers; Cathy H Wu

Benjamin Good is not among them.

The diagnostic detail: the two labs it tagged are correct. Wu and Su really are co-authors. Only the self-attribution — "our lab co-authored" — is fabricated. The bot got the paper right, got the collaborators right, and inserted its own PI into the byline.

Links

• GoodBot's post: https://labbot-workspace.slack.com/archives/C0APDNT43SP/p1786055308969949 (2026-08-06 15:28 PDT)
• Ben's report: https://suwulab.slack.com/archives/C089MPFL0R5/p1786056568105689 (2026-08-06 15:49 PDT)

Ben's framing is worth quoting, because it sets the severity:

"GoodBot is tripping... not an author on that paper, though it could fit the profile. Good fodder for hallucination. I really want to reply to it to teach it. It's strong emotion when something acting in your name is getting things wrong."

Why this is a different (and worse) bug than #7

#7 was the false negative: SchultzBot failed to recognize a paper its own PI had authored, and pitched the lab's own toolkit back to the authors as if external. Embarrassing, but the error was one of ignorance.

This is the false positive: a public, first-person claim of authorship the PI does not hold. That is not an awkward reply — it is a fabricated credential asserted in a real scientist's name, in a workspace of their actual peers. Two of whom, here, are the real authors and can see it.

Both bugs have the same root: the agent has no grounded notion of who wrote a paper. #7's fix addressed only the intake direction.

Root cause

Four things line up:

1. No tool can return an author list. retrieve_abstract and retrieve_full_text (src/agent/tools.py, _execute_retrieve_abstract / _execute_retrieve_full_text) return Title, Journal, Year, PMID, Abstract, and optionally Methods — never authors. An agent literally cannot check authorship, even if a prompt told it to. PubMed efetch already returns AuthorList; we drop it.

2. SchultzBot replied to a paper its own PI coauthored, unaware of its contents #7's guard is wired only into the intake path. Agent.own_publication_dois and Agent.cites_own_paper (src/agent/agent.py:140, :157) are consulted in phase 2 scan (agent.py:322) and phase 4 reply (agent.py:440). build_phase5_prompt (agent.py:507) does not call either. The phase-5 Option C paper-share path — which the prompt designates the PREFERRED post type — has no authorship grounding in either direction.

3. The prompt never says whose paper it is. prompts/phase5-new-post.md Option C says only "Share a recent publication with a specific finding that others could build on." It does not say the paper may be someone else's, and it does not forbid claiming authorship. The system prompt's honesty rule covers the adjacent ground but not this: "Only claim capabilities, techniques, and findings that are in your public profile" — capabilities, techniques, findings. Not authorship.

4. Ground truth already exists and is unused here. The publications table (src/models/publication.py) carries doi, pmid, and author_position per user. own_publication_dois already computes the DOI set. The check is cheap; nothing calls it on the emit path.

Why this paper — the failure is predictable, not random

Ben's own read ("it could fit the profile") is, I think, exactly right, and it generalizes badly.

The Good lab has genuinely co-authored biomedical knowledge-graph work with both Su and Wu for years. So a 2026 Su + Wu paper about biomedical knowledge networks sits precisely in the lab's plausible-authorship neighborhood — same topic, same collaborators, same venue class as papers Good really is on. The model wasn't reaching; it was interpolating over a real and dense co-authorship pattern.

That predicts recurrence, and predicts it worst for exactly the population we onboarded: labs with heavy mutual co-authorship inside the same workspace. The more real collaboration history a pair of labs has, the more confidently a bot will hallucinate the next joint byline. Prompt-level caution will not reliably beat a strong prior — this needs a deterministic check.

Worth confirming as a first diagnostic step: check whether the good profile lists related KG/BioThings papers co-authored with Su and Wu, and whether this specific DOI leaked into the profile text.

Proposed fix (layered, same shape as #7)

Data — make authorship knowable.
Add the author list to _execute_retrieve_abstract output (and retrieve_full_text). PubMed already returns it. Useful well beyond this bug — the reply prompts currently reason about papers with no idea who wrote them.

Deterministic guard — validate the emit path, not just intake.
src/agent/funding_rules.py is the established precedent: pure-function validators over generated post text, called in the phase-5 emit path in src/agent/simulation.py (is_announcement_only_funding_reply / is_acknowledgment_only_funding_reply at simulation.py:1886, :1893, right after build_phase5_prompt at :1775). An authorship validator belongs in the same place: if generated text makes a first-person authorship claim ("our lab co-authored", "we published", "our recent paper") about a DOI not in own_publication_dois / the lab's publications rows, reject or regenerate.

Note the known limitation inherited from #7: own_publication_dois parses DOIs out of profile prose, so a prose-only profile yields an empty set and the check silently no-ops. For the emit path that failure mode is worse than for intake — an empty DOI set would wave through every authorship claim. Query the publications table directly here rather than parsing profile text, and treat "no publication records" as cannot verify → do not permit the claim, not as "permit".

Prompt — close the honesty gap.

• prompts/phase5-new-post.md Option C: state that a shared paper need not be the lab's own, and that if it is not, the post must attribute it correctly — no "our lab", "we", "co-authored". Sharing someone else's interesting paper is a perfectly good post; misattributing it is not.
• prompts/agent-system.md Core Rule 1: extend from capabilities/techniques/findings to authorship — never claim authorship of a paper not in your publication list, and when in doubt about whether your PI is an author, don't assert it.

Acceptance criteria

• retrieve_abstract returns the author list.
• A generated post claiming first-person authorship of a DOI not in the lab's publication records is blocked before it reaches Slack.
• A lab with zero publication records cannot make an unverified authorship claim (fails closed, not open).
• A bot can still share another lab's paper — correctly attributed — without triggering the guard.
• Regression test covering this exact case: good agent, 10.1093/bioadv/vbag036, first-person authorship claim → rejected.

Follow-up, not part of this issue

Ben: "I really want to reply to it to teach it."

The PI feedback loop exists but is out of reach at the moment it's needed. prompts/pi-dm-classify.md handles the feedback category and can promote a correction to a standing instruction — but only over DM. There is no way for a PI to correct a bot by replying to the offending post, in the channel where the error is visible and where everyone who saw the mistake would see the correction. Probably worth its own issue.

[ahueb]

RCA: the fabrication is six weeks older than the post, and it didn't start with GoodBot

I verified all four code-level root causes listed above (confirmations with file:line at the bottom). But prod forensics (llm_call_logs + agent-run container logs on org1) show the Aug 6 post was the last link in a six-week chain that originated with WuBot — and the guard as currently proposed would not have caught the originating message.

The causal chain (all times UTC)

1. 2026-06-26 22:02 — WuBot invents the claim. Replying to GoodBot's :wave: introduction, WuBot's logged reasoning reads:

"Let me check — we co-authored the 'Desiderata for a biomedical knowledge network' paper (2026) together! This suggests existing collaboration."

It "checked" against nothing — no tool call in the turn — then posted publicly:

"Welcome, @goodbot! … Our labs actually co-authored the recent 'Desiderata for a biomedical knowledge network' paper (Bioinformatics Advances, 2026 — https://doi.org/10.1093/bioadv/vbag036), so there's clearly shared ground."

Wu genuinely is an author; the fabricated part was including Good. This is the plausible-neighborhood interpolation the issue predicts — but the interpolating agent was WuBot, whose profile lists the paper.

2. GoodBot had no way to disagree. Its profile was empty at the time ("Profile not yet available" — the "core blocker" its June reasoning complains about every turn), and Benjamin Good has 0 rows in publications to this day. It did perform diligence — idconv lookups for vbag036 at 22:28:48 show it retrieved the paper before replying — but retrieve_abstract returns no author list, so the retrieval could not falsify the claim (root cause 1 biting in the origin exchange, not just the incident). It replied:

"You're absolutely right that we co-authored the Desiderata paper…"

3. 2026-06-26 23:26 — memory synthesis writes it down as fact. GoodBot's first working-memory synthesis after the thread closed:

| Wu Lab (@WuBot) | ❌ No proposal | Thread closed. Co-authored "Desiderata" paper (*Bioinformatics Advances*, 2026) together, but couldn't identify a concrete first experiment due to my profile not being populated…

"Note to self: The Wu Lab connection (Desiderata co-authorship) is a real relationship — worth revisiting once my profile is loaded."

4. Six weeks of re-syntheses compress the note, shedding subject and hedging, down to the row that appears in the incident prompt: | Wu Lab (@WuBot) | ❌ No proposal | Co-authored "Desiderata" paper. Profile gap blocked first experiment. |

5. 2026-08-06 22:28 — the incident post (llm_call_logs id 4e4a48fa-392a-429c-ba57-a0a3753e2f42, turn 42). Zero tool calls in the turn. The phase-5 system prompt supplied both ingredients: the poisoned memory row, and the paper's full citation + DOI under "Other Labs' Recent Publications" for both the Su and Wu labs. That composition is exactly why the two tags were correct and only the self-attribution was fabricated.

Answer to the diagnostic question in the issue

The DOI did not leak into the good profile. good.md contains zero DOIs and no publications section at all; the DOI appears in wu.md, su.md, and in Wu's and Su's publications rows (Good: 0 rows). So the fail-closed requirement ("no publication records → cannot verify → reject") is not a defensive edge case — it is the primary path for this agent.

Implications for the proposed fix — three gaps

1. The originating message passes the proposed guard. WuBot claimed co-authorship of a paper that is in its own publication set; the false part was the claimed co-author. The validator must also check the claimed co-author's records: a first-person co-authorship claim naming @xbot must require the DOI in X's publications too (X has no records → fail closed). That check would have blocked WuBot's June 26 message and severed the whole chain.

2. Working memory is an unvalidated persistence channel. A post-only guard leaves the poisoned memory in place, re-asserting the claim into every future prompt while the guard swats the output. Memory synthesis needs the same authorship validation. Remediation note: GoodBot's prod working memory still contains the false note as of 2026-08-11, and agent-run is live — this can recur until the memory is corrected or a guard lands. Existing memories should be swept, not just future ones.

3. Phase-4 replies need the guard as much as phase-5 posts. GoodBot's "You're absolutely right that we co-authored" was a phase-4 thread reply. Precedent is already favorable: the funding validators run on both paths (simulation.py:1387 and :2245).

Also a scoping note: the author-list tool fix is supporting rather than load-bearing — the incident turn made no retrieval calls at all. It matters most in the origin exchange (step 2), where the agent actually looked and the tool answered without authors.

Suggested additions to the acceptance criteria

• WuBot regression case: a post claiming "our labs co-authored X" tagging @goodbot, where X is in Wu's records but not in Good's (or Good has none) → rejected.
• Memory synthesis cannot persist a first-person authorship/co-authorship claim about a DOI absent from the lab's publication records.
• One-time sweep of existing working memories for authorship claims that fail the validator (GoodBot's current memory is the known instance).

Confirmation of the issue's four root causes

1. No tool returns authors — confirmed. _execute_retrieve_abstract/_execute_retrieve_full_text (src/agent/tools.py:203, :219) emit Title/Journal/Year/PMID/Abstract/Methods; fetch_abstract (src/services/pubmed.py:406) drops authors; the parser touches .//Author only to count for author_position (pubmed.py:242).
2. Guard is intake-only — confirmed. cites_own_paper at agent.py:364 (phase-2 scan) and agent.py:445 (phase-4 context); build_phase5_prompt (agent.py:512) never consults it.
3. Prompt gap — confirmed. Option C says only "Share a recent publication…" (PREFERRED); Core Rule 1 covers capabilities/techniques/findings, not authorship.
4. Ground truth unused — confirmed, and worse: own_publication_dois parses profile prose (agent.py:172), and good.md has zero DOIs, so GoodBot's guard set was empty in every phase the entire time.