[v0.2.0] Hybrid Transfer Routing: Combine Rule-Based + VDB Semantic Matching

[Kavirubc]

Overview

Enhance the transfer routing system with a hybrid approach that combines the existing rule-based matcher (from #15, #22) with VDB semantic search for intelligent, context-aware issue routing.

Background

PR #22 implements a rule-based Transfer Rules Engine that routes issues based on explicit patterns (labels, title/body keywords, authors). While deterministic and fast, it has limitations:

• Cannot understand semantic meaning
• Requires manual rule maintenance
• Rigid pattern matching may miss nuanced cases

Proposed Solution: Hybrid Approach

Architecture

┌─────────────────────────────────────────────────┐
│         transfer_check (Enhanced)               │
│                                                 │
│  1. Rule-Based Matcher (Priority)               │
│     ├─ Explicit rules (fast, deterministic)     │
│     └─ High confidence → Transfer immediately   │
│                                                 │
│  2. VDB Semantic Router (Fallback)              │
│     ├─ Search similar issues across repos       │
│     ├─ Analyze repo distribution of matches     │
│     ├─ LLM explains transfer reasoning          │
│     └─ Confidence > threshold → Transfer        │
└─────────────────────────────────────────────────┘

Configuration Example

transfer:
  enabled: true
  strategy: "hybrid"  # "rules-only", "vdb-only", or "hybrid"
  
  # Phase 1: Rule-Based (Deterministic)
  rules:
    - name: "critical-security-bugs"
      priority: 100
      target: "org/security-repo"
      labels: ["security", "critical"]
    
    - name: "documentation-issues"
      priority: 50
      target: "org/docs-repo"
      labels_any: ["docs", "documentation"]
  
  # Phase 2: VDB Semantic Routing (Fallback)
  vdb_routing:
    enabled: true
    confidence_threshold: 0.75    # Minimum confidence to transfer
    min_samples_per_repo: 20      # Need enough historical data
    max_candidates: 3             # Check top N repos
    explain_decision: true        # Ask LLM to justify transfer

Implementation Details

1. VDB Semantic Router Logic

When no rules match:

1. Embed the issue (title + body)
2. Search VDB across all indexed issues with repo metadata
3. Analyze distribution:

   Results: 15 issues
   - org/backend-repo: 8 issues (53%)
   - org/frontend-repo: 5 issues (33%)
   - org/infra-repo: 2 issues (14%)
   
   Confidence: 53% → Below threshold (75%), no transfer
   

4. If one repo has >threshold% of matches → candidate for transfer

2. LLM Transfer Justification (Transparency Fix)

Problem: VDB decisions are opaque ("AI decided")
Solution: Ask LLM to explain the transfer reasoning

// After VDB suggests transfer to "org/backend-repo"
prompt := `
Analyze why this issue should be transferred to org/backend-repo:

Issue: [title and body]

Similar issues in org/backend-repo:
1. #45: "API timeout errors" (similarity: 0.82)
2. #67: "Database connection failures" (similarity: 0.79)
3. #89: "Performance degradation" (similarity: 0.76)

Explain in 2-3 sentences why this transfer makes sense.
`

// Store explanation in metadata
ctx.Metadata["transfer_reasoning"] = llmResponse

Benefits:

• Transparent decision-making
• User can review reasoning before transfer
• Logs show "why" for auditing
• Can reject transfers with weak reasoning

3. Pipeline Flow

func (s *TransferCheck) Run(ctx *pipeline.Context) error {
    // Phase 1: Try rules first (fast path)
    if ruleMatch := s.ruleMatcher.Match(issue); ruleMatch.Matched {
        ctx.TransferTarget = ruleMatch.Target
        ctx.Metadata["transfer_method"] = "rule"
        ctx.Metadata["transfer_reasoning"] = ruleMatch.Reason
        return nil
    }
    
    // Phase 2: VDB semantic routing (fallback)
    if s.config.Transfer.VDBRouting.Enabled {
        vdbMatch := s.vdbRouter.SuggestTransfer(ctx, issue)
        if vdbMatch.Confidence > s.config.Transfer.VDBRouting.ConfidenceThreshold {
            // Ask LLM to explain
            reasoning := s.explainTransfer(ctx, vdbMatch)
            
            ctx.TransferTarget = vdbMatch.Target
            ctx.Metadata["transfer_method"] = "vdb"
            ctx.Metadata["transfer_confidence"] = vdbMatch.Confidence
            ctx.Metadata["transfer_reasoning"] = reasoning
        }
    }
    
    return nil
}

Benefits of Hybrid Approach

Aspect	Rule-Based	VDB-Based	Hybrid
Speed	⚡ Instant	🐢 Slower	⚡ Rules first, VDB fallback
Transparency	✅ Clear rules	❌ "Black box"	✅ LLM explains VDB decisions
Maintenance	❌ Manual updates	✅ Self-learning	✅ Rules for critical, VDB for rest
Semantic Understanding	❌ Pattern only	✅ Content meaning	✅ Best of both
Determinism	✅ Predictable	❌ Can vary	✅ Rules are deterministic

Implementation Tasks

• Create internal/transfer/vdb_router.go
  • SuggestTransfer() - search similar issues, analyze repo distribution
  • Confidence scoring based on match distribution
• Add LLM justification logic
  • explainTransfer() - prompt LLM to justify decision
  • Store reasoning in metadata
• Update transfer_check.go to support hybrid mode
  • Try rules first (existing logic)
  • Fall back to VDB router
• Add config options for vdb_routing
• Update logging to show transfer method and reasoning
• Add tests for VDB router and hybrid logic

Use Cases

1. Clear-cut transfers: Use rules (e.g., "security" label → security repo)
2. Ambiguous issues: Use VDB (e.g., "My app is slow" → analyzes if it's frontend/backend/infra)
3. New issue types: VDB handles cases without predefined rules
4. Audit trail: LLM reasoning provides transparency for all VDB transfers

Related

• Issue [v0.1.0] Implement Cross-Repo Issue Transfer (GraphQL) #15: Initial transfer logic requirements
• PR feat: Implement Transfer Rules Engine for Cross-Repository Issue Routing #22: Rule-based Transfer Rules Engine implementation
• Milestone: 0.2.0v

Questions

• Should VDB transfer suggestions require manual approval before execution?
• Should we log transfer reasoning to issue comments for transparency?
• What confidence threshold should be default? (suggested: 0.75)

[Kavirubc]

Hi,

I have made an major change to the existing transfer workflow at the time of the above issues creation. When a issue is marked as pending transfer we use to wait for reactions before transferring. But we now do the opposite. We do the transfer and ask for reverse if needed.

Thanks.