What we mean by "restore"

It is easy to make activation look fast by being vague about it. If you call every quick start a "restore," a server that simply never went idle gets the same credit as genuinely bringing back a dead process — and the headline number stops meaning anything.

So we refuse the single word. Every activation in our runtime is classified into an explicit path, and each path is accounted for on its own terms.

The paths, named

• Cold rebuild — nothing was reused; the workload started from scratch. The honest worst case, and the one that sets the bar everything else is measured against.
• Prepared activation — the decision layer predicted the intent and brought the workload up before the interaction began. This is the path that earns credit for anticipation, because the preparation was caused by a prediction.
• Warm reuse — the workload happened to be warm already, but no prediction caused it. It is fast, but it does not get to claim the prediction worked.
• Live-session return — the experience was still resident and is simply re-entered, with essentially no server-side work. The fastest path, and clearly labeled as such so it is never confused with a rebuild.
• Checkpoint restore — bringing back preserved process state. Where it is not yet supported for a given workload, we mark it unsupported rather than quietly routing around it.
• Unknown — a path that should never appear in practice; if it does, it is a bug to investigate, not a number to average away.

Why the split is the point

Separating these is not pedantry; it is cost accounting. Each path has a different true cost, and collapsing them hides exactly the information you need to improve the system — and the information a partner needs to trust it. "Warm reuse" dressed up as "restore" inflates the story and erodes the credibility of the cases that are genuinely impressive.

It also keeps us honest under our own measurement. When a fast path turns out to be warm reuse rather than a prediction win, that is a signal the prediction layer has room to improve — not a result to celebrate. When a path is unsupported, the dashboard says so, in writing, where anyone reviewing it can see it.

Naming what did not get reused is as important as naming what did. A claim that survives being stated precisely — this path, this cost, this is what was reused — is the only kind worth making twice.