{
  "assumption_density": 0,
  "assumptions": [
    "The $8K/month spend is primarily driven by a subset of heavy workflows that can be isolated and migrated independently",
    "The team has or can allocate ~0.5 FTE of DevOps/platform engineering capacity for runner infrastructure maintenance",
    "Build workflows can be cleanly categorized into 'heavy' (suitable for self-hosted) and 'light' (retain on GitHub-hosted) without significant cross-dependencies",
    "The team operates in a cloud environment (AWS/GCP/Azure) where Kubernetes infrastructure can be provisioned, and has existing cloud accounts and networking in place",
    "Security and compliance requirements do not prohibit running CI/CD workloads on self-managed infrastructure"
  ],
  "confidence": 0.72,
  "id": "cc940f93-205e-4dcd-a258-77c16c203f5b",
  "next_action": "Run a 2-week build profiling analysis: tag every GitHub Actions workflow by category (compilation, test, lint, deploy, other), measure per-workflow minute consumption and cost, and identify the top 10 workflows by cost — these are your migration candidates for self-hosted runners.",
  "question": "Should we move our CI/CD from GitHub Actions to self-hosted runners for a 50-developer team spending $8K/month on Actions minutes with 400 builds per day?",
  "question_fit_score": 0,
  "rejected_alternatives": [
    {
      "path": "b004: Conduct comprehensive CI/CD strategy review before any infrastructure changes — optimize workflows, caching, and architecture first",
      "rationale": "Despite having the highest stated confidence (0.95), this branch is structurally a [reframe] — it challenges the question's framing without providing an actionable recommendation. It offers no specific technology, threshold, or implementation path. 'Conduct a review' is consulting fog, not a decision. The underlying insight about TCO and build volume optimization is valid and is captured as a strategic consideration, but it cannot win as an implementation branch. Per selection rules, reframes compete in a different category."
    },
    {
      "path": "b001: Full self-hosted with spot instances for non-critical + reserved for critical builds, Kubernetes auto-scaling 10-50 nodes, targeting 60% cost reduction to $3.2K/month",
      "rationale": "Overly aggressive cost target ($3.2K) depends on heavy spot instance usage. Branch b005 effectively prosecuted this: spot interruptions could kill 10-20% of builds mid-flight at 400 builds/day scale, creating a reliability tax. The 10-50 node autoscaling range implies significant Kubernetes operational complexity. Killed branch b003 was eliminated for the same overreliance on spot instances and underestimation of DevOps staffing costs. b001 shares these vulnerabilities."
    },
    {
      "path": "b005: Self-hosted spot instances create a reliability tax that tanks developer velocity worse than GitHub's managed uptime",
      "rationale": "Valid adversarial contribution that successfully weakened the pure-spot approaches (b001, b003), but is a critique rather than a recommendation. Its core insight — spot interruptions as hidden cost — is incorporated into the hybrid approach's design constraints."
    }
  ],
  "reversal_conditions": [
    {
      "condition": "Build profiling reveals that workflow optimization and aggressive caching alone can reduce GitHub Actions spend by 40%+ (to $4.8K or below) without infrastructure changes",
      "flips_to": "Optimize existing GitHub-hosted workflows (caching, parallelization, deduplication) instead of migrating to self-hosted runners"
    },
    {
      "condition": "Team has zero Kubernetes expertise and hiring/contracting a DevOps engineer would cost $150K+/year, making TCO savings negative",
      "flips_to": "Stay on GitHub-hosted runners and focus purely on workflow optimization, or evaluate turnkey managed runner services (e.g., Buildjet, Namespace, Actuated) that provide cost savings without self-management"
    },
    {
      "condition": "GitHub significantly reduces Actions pricing or introduces a volume tier that brings the 400 builds/day cost below $5K/month",
      "flips_to": "Remain on GitHub-hosted runners — the operational complexity of self-hosted infrastructure is not justified for marginal savings"
    }
  ],
  "unresolved_uncertainty": [
    "Actual build profile distribution is unknown — the 200/200 split between heavy and light workflows is assumed, not measured. If 350+ builds are heavy, the hybrid approach saves less because more infrastructure is needed",
    "Team's existing DevOps capacity and Kubernetes expertise is unspecified — if no current Kubernetes competency exists, ramp-up time and staffing costs could eliminate the cost advantage for 6-12 months",
    "b004's core point remains unaddressed: whether 400 builds/day is optimal or includes redundant/wasteful builds. Build caching and workflow optimization alone might reduce spend by 20-30% with zero infrastructure changes",
    "Killed branch b003 had the most specific architecture (ARC, exact instance types, capacity math showing 16 concurrent runners needed at peak) but was eliminated for underestimating DevOps staffing costs — its technical specifics may still be the right implementation details",
    "Security and compliance implications of self-hosted runners (secrets management, network isolation, audit logging) are unaddressed by any surviving branch"
  ],
  "url": "https://vectorcourt.com/v/cc940f93-205e-4dcd-a258-77c16c203f5b",
  "verdict": "Implement a hybrid CI/CD model: migrate heavy workflows (compilation, integration tests, Docker image builds) to self-hosted runners orchestrated via Kubernetes (ARC on EKS/GKE), while retaining GitHub-hosted runners for lightweight and low-frequency tasks. Target 40-60% cost reduction from $8K to $4-5K/month. Self-hosted infrastructure must reliably handle at least 200 of the 400 daily builds.\n\nCritical failure mode: Runner image drift. GitHub-hosted runners update base images weekly with ~200 pre-installed tools. Self-hosted runners diverge within 2-3 weeks, breaking builds that worked on hosted runners. This is the primary reason self-hosted migrations get reverted. Mitigate with automated weekly image rebuilds matching GitHub's runner image releases.\n\nSecond failure mode: Spot interruptions affecting 5-10% of instances. Use mixed instance types and maintain 3+ on-demand baseline runners that never scale to zero. Set termination grace periods to allow in-flight builds to complete.\n\nCritical threshold: DevOps staffing. This infrastructure requires ~0.5 FTE dedicated DevOps capacity. If your team lacks this, the TCO advantage collapses — a $75K+ annual staffing cost against ~$36-48K annual savings makes this marginal. Only proceed if existing DevOps capacity can absorb the load.",
  "verdict_core": {
    "recommendation": "Deploy a hybrid CI/CD model migrating heavy workflows to self-hosted runners on Kubernetes while retaining GitHub Actions for lightweight tasks, targeting a 40-60% cost reduction to $4-5K/month.",
    "mechanism": "Because heavy workflows (compilation, integration tests, Docker builds) consume disproportionate minutes at GitHub's per-minute pricing, offloading these to self-hosted runners on reserved/on-demand instances eliminates the premium while retaining GitHub-hosted runners for lightweight jobs avoids the maintenance burden on the long tail of simple workflows.",
    "tradeoffs": [
      "Added operational complexity requiring dedicated DevOps capacity to manage runner infrastructure, image updates, and autoscaling",
      "Runner image drift risk where self-hosted environments diverge from GitHub-hosted runners within 2-3 weeks, causing build failures",
      "Increased incident surface — spot interruptions, Kubernetes cluster issues, and networking failures become your team's responsibility"
    ],
    "failure_modes": [
      "Spot instance interruption cascade: 3+ spot nodes terminating simultaneously during peak queues builds for 2-4 minutes and can trigger retry storms",
      "Runner image drift: self-hosted runners diverge from GitHub-hosted base images within 2-3 weeks, causing 'works on hosted, fails on self-hosted' syndrome — the #1 reason self-hosted migrations get reverted",
      "DevOps staffing shortfall: maintaining Kubernetes-based runner infrastructure requires ~0.5 FTE of dedicated DevOps time, which at $150K+ fully-loaded cost erodes savings significantly"
    ],
    "thresholds": [
      "400 builds/day current volume",
      "$8K/month current spend",
      "Target $4-5K/month post-migration",
      "Self-hosted runners must reliably handle at least 200 daily builds",
      "40-60% reduction in hosted minutes usage"
    ]
  },
  "verdict_type": ""
}