An application expresses eligible computational work through the WebCompute API as a semantic graph. A planning layer analyzes it together with the capabilities of the current device and produces an execution plan: an assignment of graph regions to concrete execution strategies across the CPU and GPU execution domains, using only mechanisms the Web platform already provides.

The semantic graph is an execution-independent description of operations and data dependencies. It records what the computation means: its structure, its data flow, its parallelism, without committing to how any part of it will execute. The graph is the unit the planning layer reasons about. Decisions are made over regions of the graph, not over isolated operations.

The planning layer maps a semantic graph and a device’s capability profile to an execution plan. The research question is whether it can do so using cost signals that are actually knowable inside a browser, with planning overhead small enough not to erase the gains. Its quality is measured as oracle regret: the gap between its chosen plan and the best plan available on that device in hindsight.

The model recognizes two execution domains: CPU and GPU. Web Workers, SIMD, and shared-memory/threaded execution are execution capabilities and topologies within these domains. They shape how a strategy runs, but they are not separate hardware targets.

An execution strategy is a concrete way to run a graph region: JavaScript or WebAssembly in the CPU domain, WebGPU/WGSL in the GPU domain, each potentially in different worker and threading configurations. Strategies are what the planner selects among; the application never names one.

Data has a location, and moving it costs time. The model tracks where resources reside, such as CPU memory or GPU buffers, so the planning layer can weigh transfer costs against compute gains across the whole graph. A plan that is fastest kernel-by-kernel can lose to one that keeps data where it already lives.

Every graph must be executable on every device, so the CPU domain is always available as a complete fallback. Capability loss, such as no WebGPU, no SIMD, or no shared memory, narrows the strategy space; it never makes a graph unrunnable.

The model deliberately avoids exposing raw hardware information to applications. Capability modeling is designed to stay within what the Web platform already reveals. The security report will examine whether planning can remain useful without creating new fingerprinting surface. Several project non-goals exist specifically to keep this boundary tractable.

The exact graph construction API, the operation vocabulary, the cost-model internals, the capability-probe mechanics, and all interface signatures remain implementation-defined at this stage. The first experiment should test the hypothesis before these surfaces are fixed. Fixing them before the evidence exists would invert the project’s method.