wasm-ai.console/compiled-intelligence/0x0000

WebAssembly AI Atlas

From portable bytecode to local intelligence.

Low-Level Atlas explained the machine. AI Atlas explained intelligent systems. This independent crossover studies how to execute those systems portably, locally, with acceleration when available, inside explicit boundaries, and with outputs that can be verified.

HOSTTypeScript · Browser · WASIorchestrate · detect · report
explicit ABI / capabilities
WASMmodule · memory · kernelsportable · bounded · inspectable
CPUGPUNPUFALLBACKVERIFIEDEXPERIMENTAL
27Canonical pages
15Branches
9Workbench milestones
0Atomic notes implemented
Independent crossover atlas

Systems depth meets AI delivery.

This is not AI Atlas with a browser appendix and not Low-Level Atlas IV. It owns the execution layer between model artifacts and portable hosts: bytecode, memory, tensor movement, runtimes, accelerators, components, sandboxes, and verification.

atlas-i

Low-Level Atlas I

Machine model, C, memory, assembly, toolchains, systems, concurrency, and an operating system from scratch.

atlas-ii

Low-Level Atlas II

Applied systems built from scratch: shell, allocator, regex engine, Git, HTTP server, and database engine.

atlas-iii

Low-Level Atlas III

Sockets, protocols, WebSocket, concurrency at scale, messaging architecture, and a real-time chat.

ai-atlas

AI Atlas

Models, RAG, agents, evaluation, safety, MLOps, product engineering, and inference optimization.

Build order

Learn each layer by making it observable.

Start with WAT and linear memory, build a tiny inference engine, measure SIMD and workers, move real models through real browser runtimes, then add adaptive acceleration, offline product behavior, portable components, and sandboxed tools.

Prerequisites: Comfort with TypeScript, typed arrays, basic memory layout, and the shape of an inference pipeline. Wasm and accelerator mechanisms are introduced progressively.

Open Start Here
Spine project

WasmAI Workbench · v0 → v8

A local-first browser workbench that progressively loads, executes, compares, verifies, and reports AI models across CPU/Wasm, WebGPU, WebNN, and portable components. Every backend decision remains visible.

v1Planned

Tiny inference engine

Layer
tensor kernels · forward pass
Expected output
Dense tensors, matmul, bias, ReLU, softmax, and a verified pretrained MLP.
v2Planned

SIMD and parallelism

Layer
SIMD128 · workers · shared memory
Expected output
Scalar, SIMD, and parallel kernels compared under one reproducible benchmark.
v7Planned

Portable inference component

Layer
WIT · Component Model · WASI
Expected output
A typed pipeline component executed outside the browser with a WASI runtime.
v8Planned

Sandboxed AI tools

Layer
capabilities · fuel · typed tools
Expected output
A local agent host invoking deterministic Wasm tools with explicit budgets and no ambient access.
Open WebAssembly Execution Model
Capability truth

Stable core, conditional acceleration.

Support is detected at runtime and recorded in reports. Experimental or browser-dependent paths never masquerade as universal.

STABLE CORE

WebAssembly Core · JS API

Validated modules, linear memory, SIMD and threads where the host enables the required isolation.

CONDITIONAL

WebGPU · Wasm threads

Feature-detected acceleration with device limits, browser policy and transfer costs recorded.

EXPERIMENTAL

WebNN · WASI-NN

Promising graph and host-inference paths whose availability and semantics still require explicit checks.

FALLBACK VISIBLE

Wasm SIMD → scalar

Every adaptive path names the selected backend and verifies output before claiming success.

Platform matrix

Different layers, different jobs.

WebAssembly, WebGPU, and WebNN are complementary mechanisms, not interchangeable runtimes.

EnvironmentRole in the atlas
Browser hostLifecycle, capabilities, media, storage, workers, UI and reporting.
WebAssemblyPortable CPU execution, bounded memory and a narrow sandboxed guest boundary.
WebGPUExplicit GPU compute with WGSL, tensor residency and visible synchronization costs.
WebNNGraph API that may map work to CPU, GPU or NPU; availability is not assumed.
WASICapability-oriented execution and components outside the browser.
TypeScriptHost orchestration, feature detection, adapters, tests and reports.
RustPrimary safe language for authored Wasm modules and components.
C / C++Porting path and comparison point for mature kernels and native libraries.
PythonTraining, export, conversion and generation of golden reference outputs.
00
Phase 00 · Calibrate the map

Orientation

Prerequisites, platform distinctions, capability limits, tool expectations, and linear versus project-led reading paths.

Phase page
01
Phase 01 · Make Wasm visible

WebAssembly Foundations

Understand modules and bytecode, compare language toolchains, and make the linear-memory boundary between guest and host explicit.

Phase page
02
Phase 02 · Build inference yourself

Inference from First Principles

Implement tensor mechanics below a runtime, then measure what SIMD, threads, workers, and memory sharing actually change.

Phase page
03
Phase 03 · Move real models

From Models to Browser Inference

Export models, understand formats and quantization, compare real runtimes, and validate the preprocessing and postprocessing around them.

Phase page
04
Phase 04 · Choose hardware honestly

Hardware Acceleration

Treat WebGPU and WebNN as distinct acceleration paths with capability detection, transfer costs, explicit fallbacks, and verified outputs.

Phase page
05
Phase 05 · Make AI useful offline

Local-First AI

Design model delivery, persistence, offline behavior, multimodal pipelines, embeddings, and retrieval around real device constraints.

Phase page
06
Phase 06 · Package capabilities

Beyond the Browser

Use WIT, the Component Model, WASI, and capability-oriented hosts to move portable inference and deterministic tools beyond one browser.

Phase page
Phase ★ · Measure and verify

Always Active

Benchmark cold and warm paths, test numerical drift, protect the supply chain, and make every fallback and output auditable.

Phase page
Reference layer

Specifications before abstractions

The registry keeps standards, implementation documentation, runtime references, and change-sensitive APIs explicit and reviewable.