---
title: 'Google: Postsubmit Speculative Cycles with Transition Prediction'
slug: google-speculative-cycles
stable_id: dd6d683bf4ef1237
company: Google
function_code: software_engineering
pattern_codes:
  - continuous_decisioning
  - queue_elimination
evidence_strength: verified
publication_tier: showcase
freshness: current
reviewed_at: '2026-08-23'
updated_at: '2026-08-22'
source_quality_summary: 1 peer reviewed, 1 primary; publication outcomes are verified.
caveat_summary: >-
  Comparison is to the prior comprehensive scheduler on empirically observed production
  timings at a 25% target budget, not a randomized controlled experiment. The paper says
  Google 'is implementing' Speculative Cycles; the evaluated production-data window does
  not state the fleet fraction live during every day of the three months. The Google
  Research abstract reports an approximately 70-minute median reduction; the ICST paper
  states 65% from 107 to 37 minutes, which is the same difference.
collections:
  - queue-eliminated
bundle_version: 1.0.0
bundle_fingerprint: sha256:c23c6cc2b88153d008ea8fda928f632ce0011fc2d4c5036672a16e5d895bab93
canonical_url: https://brianletort.ai/transformations/google-speculative-cycles
---

# Google: Postsubmit Speculative Cycles with Transition Prediction

Novel breakages need not wait for a comprehensive post-submit test cycle.

Function: Software engineering. Patterns: Continuous decisioning; Queue elimination. Evidence: verified.

Freshness: current. Reviewed: 2026-08-23. Updated: 2026-08-22.


Source quality: 1 peer reviewed, 1 primary; publication outcomes are verified.

## Before

1. **Developer** — Submits a change after limited presubmit testing. (control: Presubmit checks and code review; comprehensive testing is deferred)
2. **TAP Postsubmit comprehensive cycle** — Waits for capacity, then runs all tests affected since the last definitive repository status. (control: Static build-graph dependence; no ML ranking of which tests to run first)
3. **Culprit finding / autorollback / developers** — Triage the first detected failure, identify the culprit change, and roll back when evidence thresholds are met. (control: Autorollback currently requires at least 10 distinct failing targets)

## After

1. **Developer** — Submits a change after limited presubmit testing. (control: Same presubmit and review gates)
2. **Transition Prediction (TRANSPRED)** — Every ~20 minutes, after static affected-target filtering, scores targets for pass-to-fail transition risk and ranks them. (control: Shallow gradient-boosted trees on coarse metadata; scores are ranks, not calibrated probabilities)
3. **Speculative Cycle scheduler** — Schedules the top-risk targets within a 25% test budget to find novel breakages sooner. (control: Fixed top-k cost cap; comprehensive cycles still run)
4. **Culprit finding / autorollback / developers** — Consume earlier failure signals for investigation and rollback. (control: Same autorollback evidence threshold (AtLeast 10 targets))

## Decision rights

Transition Prediction decides speculative scheduling order within a human-set budget. Humans retain rollback policy, feature/training configuration, and the continued existence of comprehensive cycles. The model does not skip required comprehensive coverage by itself.

## Exception path

Missed breakages wait for the next comprehensive cycle. Flaky or low-evidence culprits are filtered by culprit verification. Late speculative detections that do not beat comprehensive timing still fall back to the existing gardening workflow.

## Outcomes

- **Median (p50) time to detect novel breaking targets** (verified): 107 minutes with comprehensive cycles only → 37 minutes with Speculative Cycles (approximately 65% / 70-minute reduction). Comparison is to the prior comprehensive scheduler on empirically observed production timings at a 25% target budget, not a randomized controlled experiment. The paper says Google 'is implementing' Speculative Cycles; the evaluated production-data window does not state the fleet fraction live during every day of the three months. The Google Research abstract reports an approximately 70-minute median reduction; the ICST paper states 65% from 107 to 37 minutes, which is the same difference.

## Executive lesson

When the expensive complete pass cannot get faster, the transformation is to give a cheaper, more frequent pass the right to choose what to run. Google moved postsubmit ordering from 'all affected tests when capacity allows' to a ranked speculative slice, and median novel-breakage detection fell from 107 minutes to 37.

## Anti-pattern

Claiming that developers used to pick test order by hand, or reporting a 70-minute win without stating the 107-to-37-minute comprehensive-cycle baseline and the 25% budget.

## Questions for leaders

- What is the first pass that is allowed to be incomplete in order to be faster?
- If the model is wrong, does a slower complete cycle still run, or did we just create silent coverage gaps?
- Is the outcome median time-to-detect on production traffic, or a replay against a synthetic scheduler?

## Sources

- [Speculative Testing at Google with Transition Prediction](https://research.google/pubs/speculative-testing-at-google-with-transition-prediction/) — Google Research
- [Speculative Testing at Google with Transition Prediction (ICST 2025 Industry Track full paper)](https://hackthology.com/pdfs/icst-2025.pdf) — IEEE International Conference on Software Testing, Verification and Validation (author-posted PDF)