WebAssembly AI Reference Registry
This registry keeps volatile facts and reusable evidence out of prose-only memory. It does not replace per-note sources; it records which specification, implementation, artifact, and environment a claim actually refers to.
Registry entry schema
| Field | Required meaning |
|---|---|
| Identifier | Stable local name for the source or artifact |
| Type | Specification, proposal, implementation, model, dataset, toolchain, or benchmark |
| Version / revision | Release, commit, model hash, or dated living-spec snapshot |
| Status | Stable, candidate, draft, proposal phase, experimental, deprecated, or implementation-specific |
| Consulted | Date the claim or compatibility information was checked |
| Environment | Browser, runtime, operating system, hardware, and enabled features when relevant |
| Evidence | Exact URL, checksum, command, raw result, or report path |
| Recheck trigger | Release, browser update, runtime update, model change, or failed reproduction |
Status vocabulary
- Standardized means the relevant standardization process has reached that state; it does not imply universal implementation.
- Stable implementation API is a vendor/runtime claim scoped to a named release.
- Draft or proposal means design and behavior can still change.
- Experimental means production use requires an explicit risk and fallback plan.
- Observed support means a dated test passed in a declared environment, not that all environments support it.
- Unavailable is a valid matrix result and must not be rewritten as a generic failure.
Initial primary references
| Area | Primary reference | Tracking rule |
|---|---|---|
| Core Wasm | WebAssembly Core Specification | Record edition or consulted date |
| Browser host API | WebAssembly JavaScript Interface | Track browser implementation differences |
| WASI | WebAssembly/WASI | Pin release and runtime coverage separately |
| Components / WIT | Component Model specification | Pin revision while evolving |
| WebGPU | WebGPU specification | Record browser, adapter, and feature set |
| WGSL | WGSL specification | Record language/spec revision |
| WebNN | WebNN specification | Treat support as non-universal and dated |
| WASI-NN | WebAssembly/wasi-nn | Record proposal phase and host implementation |
| ONNX Runtime Web | Official documentation | Pin package version and execution provider |
| LiteRT.js | Official LiteRT web documentation | Pin API/package version and browser support |
Artifact registries
- Model entries must include source, license, original hash, converted hash, format, quantization, operator assumptions, and golden-output version.
- Benchmark entries must include workload, environment, warm-up, sample count, raw distribution, and fallback observations.
- Browser-support entries must contain a test date and exact browser build, not only a compatibility-table summary.
- Golden datasets must record preprocessing, expected output, tolerance, and why each fixture exists.
- Toolchain entries must pin compiler, linker, optimizer, target, flags, and reproducible build commands.
Maintenance policy
Recheck a registry entry when a source release changes, a browser updates a relevant feature, a runtime changes backend behavior, a model is reconverted, or a benchmark no longer reproduces. Notes should cite the primary URL and carry the version-sensitive claim locally; this registry holds the normalized evidence behind it.
Connects to: Start Here · Always Active · Wasm AI Performance, Security & Craftsmanship