Activation is an infrastructure problem

Discovery is effectively free now. Feeds, recommendations, and links put the right interactive content in front of the right person at the right moment. What did not get solved is everything that has to happen after the tap and before the first meaningful interaction: the process that has to start, the resources that have to be scheduled, the state that has to be loaded.

We treat that distance — the activation gap — as an infrastructure problem, not a UI one. The interesting work is in the runtime that turns "I want to play" into "I am playing."

A workload moves through explicit states

In our runtime, an interactive workload is never just "on" or "off." It moves through a small, deterministic set of states, and every transition is a decision we can name and measure:

• Cold — nothing is running; no resources are held.
• Preparing — the workload is being brought up ahead of demand.
• Ready — it is warm and waiting, but no one is using it yet.
• Active — someone is interacting; it has full resources.
• Reusable — it was active and is briefly held so it can be re-entered instantly instead of rebuilt.

Modeling activation as an explicit state machine is what makes the rest possible. You cannot optimize — or honestly account for — a transition you have not named.

Predict, prepare, activate, recover

Around that lifecycle sit four jobs:

1. Predict. Engagement signals (what someone is watching, for how long, what is trending) feed a decision layer that estimates what a person is about to want — sometimes across content types, not just "more of the same."
2. Prepare. When the signal is strong enough, the runtime brings the right workload up before the tap, within a bounded budget of warm slots so cost stays in check.
3. Activate. When the interaction actually begins, the system reuses what is already warm instead of starting from cold.
4. Recover. When a process dies — and processes die — the runtime restores the parts of its working state that matter, rather than starting over.

Two design choices keep that economical. Shared, always-warm surfaces avoid per-item cold starts for common content; everything else scales to zero when idle, so nothing is paid for while no one is there.

Why games first

Games are the most demanding measurable surface we could pick. Latency, readiness, state, failure, and abandonment all become visible immediately — if activation works under those conditions, the same runtime generalizes to other interactive software later. Watch & Play is the first visible product surface built on this layer: a proof you can open, not a diagram.

None of this is a single trick. It is a runtime that prepares ahead of demand, reuses aggressively, and recovers deliberately — and that measures each step so the claims stay honest. The posts that follow get specific about how the prepare and recover paths actually work.