Ecosystem Simplification and Integration Contract Review for TinyRustLM

Full report

On this page

Primary Recommendation: The analysis recommends adopting a single-source-of-truth schema strategy governed by a central Rust definitions crate, enforcing cross-repository coherence through schemars-generated JSON Schemas and cargo-xtask automated drift tests. It is necessary to establish MiniModel.org as the explicit initial seed authority, deprecate all obsolete compatibility readers for legacy SLM1 formats, and implement the Origin Private File System (OPFS) paired with Cross-Origin Embedder Policy (COEP) headers to ensure zero-copy memory mapping for WebAssembly inference.

Principal Risk of Recommendation: The strongest reason this architectural recommendation could fail is that strictly tying schema validation across distinct repositories via automated drift tests may temporarily block deployment pipelines if the component boundaries (e.g., between the Windows .NET companion and the browser WASM module) require asynchronous release schedules. Furthermore, relying on OPFS and WebGPU for the initial default model execution might fail silently on low-end hardware that enforces strict WebGPU storage buffer binding limits (often capped at 128 MB)1, preventing the immediate usable default experience if the initial seed model exceeds these hardware-specific constraints.

Constraint and Evidence Labeling Definitions

• \[Project-Supplied Fact\]: Information explicitly provided in the project briefing context.
• \[Externally Verified Fact\]: Information corroborated by technical literature, academic papers, and public documentation.
• \[Hypothesis\]: Deductive architectural assumptions requiring empirical validation.
• \[Locally Unverified Condition\]: States involving proprietary source code or local machine environments that cannot be independently audited by external analysis.
• \[Recommendation\]: Proposed technical or architectural action based on the synthesis of available facts.

Component Ownership Map and Responsibilities

The current ecosystem exhibits symptoms of historical domain sprawl, wherein repository names imply overlapping or obsolete authorities. To achieve ecosystem closure, component ownership must be strictly mapped to functional responsibilities rather than legacy marketing identities. \[Locally Unverified Condition\]: The mapping below assumes standard Rust workspace structures within the E:\\Source\\Rust directory and relies on repository names supplied in the briefing.

\[Project-Supplied Fact\]: TinyRustLM source belongs only in E:\\Source\\Rust\\TinyRustLM.com; its model payloads belong only in D:\\LLMs\\TinyRustLM.

\[Recommendation\]: Runtime.MiRust.com and LMComposer.com must share an exact structural contract defined in a dedicated core types crate. They must not remain independent regarding data structures, as divergence will cause the runtime to fail when parsing composed payloads. TinyRustLM.com and the Windows .NET companion should remain independent in deployment but strictly coupled via a versioned Native Messaging schema.

Essential Producer/Consumer Boundaries

To eliminate duplicated implementations and contradictory behavior, the architecture must formalize eight primary boundaries. For each boundary, the analysis specifies the identity, schema owner, validation order, resource bounds, error categories, cancellation mechanics, and evidence of success.

Source Acquisition to Conversion

The identity of this boundary represents LMComposer fetching raw weights (such as Hugging Face safetensors) and converting them to model.slm2. The schema owner is LMComposer.com. The validation order must proceed sequentially: SHA-256 hash verification prevents duplicate downloads and ensures file integrity2, followed by structural parsing, and finally tensor dimension validation. The resource bounds dictate that the conversion process must operate out-of-core, utilizing OS-level memory mapping (e.g., via mmap) to prevent Out-Of-Memory (OOM) errors on large models, a design paradigm successfully utilized by the safetensors format3. Error categories encompass Network Timeout, Hash Mismatch, Unsupported Architecture, and Dimension Mismatch. Cancellation mechanics require the system to listen for OS interrupts (such as SIGINT) and ensure that partial or corrupted downloads are immediately purged. Evidence of success is the generation of the model.slm2 file alongside its corresponding .composition.acg2 manifest.

Composition to Runtime

This boundary defines the exact binary layout transition from LMComposer.com outputs to Runtime.MiRust.com execution. The schema owner is strictly Runtime.MiRust.com, as the runtime dictates the execution bounds to which the composer must comply. Validation begins with a Signature/Manifest check, followed by metadata envelope parsing, and concludes with memory-mapped tensor loading. \[Externally Verified Fact\]: Resource bounds are strictly governed by WebGPU limits, specifically maxStorageBufferBindingSize, which varies from 128 MB on mobile and Apple discrete GPUs up to 4 GB on dedicated desktop GPUs1. Payloads must be chunked by the composer to fit these hardware-specific bounds. Error categories include Malformed Header, Endianness Mismatch, and Buffer Size Exceeded. Evidence of success is established when the WASM module successfully instantiates the computational graph without triggering a Rust panic.

Qualification to Catalog

This boundary represents the pipeline determining if a newly composed model is acceptable for public indexing. The schema owner is MiniModel.org. Validation order starts with structural validity, progresses to numerical agreement (such as perplexity bounding), and concludes with browser admission testing (ensuring the model complies with WebGPU compatibility requirements). Evidence of success is achieved when the model identity and metadata are appended to the MiniModel.org catalog database.

Catalog to Acquisition

The identity of this boundary entails TinyRustLM.com requesting the default seed model list from MiniModel.org. The schema owner is MiniModel.org, utilizing a standard REST/JSON schema. Resource bounds demand a maximum 50-millisecond response time with the response payload remaining under 50 KB to ensure rapid initial loads. Cancellation mechanics dictate that an AbortController is signaled if the user navigates away or explicitly selects a local file import instead of the default seed.

Transfer to Installation

This boundary defines TinyRustLM.com downloading the model bytes and storing them locally on the client machine. The schema owner is the TinyRustLM.com frontend application. Validation order consists of download completion, checksum validation, and subsequent commit to the local filesystem. \[Externally Verified Fact\]: The optimal resource bound utilizes the Origin Private File System (OPFS), which offers low-level, byte-by-byte file access private to the origin, bypassing the severe serialization overhead and transaction costs associated with IndexedDB when handling large ArrayBuffer objects4. Error categories include QuotaExceededError, NetworkError, and ChecksumMismatch. Evidence of success is demonstrated when files are durably written to OPFS and can be accessed synchronously via a FileSystemSyncAccessHandle within a Web Worker6.

Browser to Companion

This boundary facilitates communication between the Chrome/Edge extension and the Windows .NET companion via Native Messaging. The schema owner is the TinyRustLM.com frontend extension. Validation order begins with Native Messaging host lookup, followed by JSON payload deserialization, and capability negotiation. \[Externally Verified Fact\]: Chrome Native Messaging limits single messages to 1 MB, utilizing standard input (stdin) and standard output (stdout) streams, where each UTF-8 encoded JSON message is preceded by a 32-bit message length in native byte order7. Error categories include Host Not Found, Pipe Broken, Message Too Large, and Deserialization Failure. Cancellation is achieved through standard input/output pipe closure. Evidence of success is a two-way JSON ping/pong acknowledgment.

Seed Service to Discovery

This boundary governs MiniModel.org supplying the initial live seed to a fresh TinyRustLM installation. The schema owner is MiniModel.org. Validation order requires the client to report hardware capabilities—specifically WebGPU limits and WASM memory64 support8—followed by the server selecting a seed that matches the reported hardware profile. Evidence of success is defined by the browser successfully rendering the first token of the default conversational prompt without crashing the renderer.

Publication to Public Client

The final boundary involves deploying frontend assets to the end user. The schema owner follows Web standards (HTML/JS/WASM). Validation order centers on HTTP Header verification. \[Externally Verified Fact\]: To utilize high-performance threading via SharedArrayBuffer, the document must be cross-origin isolated. This requires setting the Cross-Origin-Opener-Policy to same-origin and the Cross-Origin-Embedder-Policy (COEP) to require-corp or credentialless9. Resource bounds require the WASM module size to remain practical (typically under 50 MB) for rapid compilation10. Evidence of success is confirmed when the JavaScript property self.crossOriginIsolated returns true in the browser console11.

Schema Maintenance and Drift Prevention

Maintaining one current schema across TinyRustLM.com, Runtime.MiRust.com, and LMComposer.com without introducing duplicated code requires rigorous build-time enforcement and strict cross-repository synchronization. The architecture must reject silent compatibility readers and ensure that any structural deviation results in an immediate, localized build failure.

\[Recommendation\]: The ecosystem must establish a central tinyrustlm-wire-formats crate within the Rust workspace. This crate will encapsulate all data structures that cross boundaries, such as manifest metadata and Native Messaging JSON envelopes.

To operationalize this, the system should leverage schemars. \[Externally Verified Fact\]: By applying the \#\[derive(JsonSchema)\] macro to all boundary structs, schemars generates JSON Schema definitions directly from Rust code, ensuring that the Rust types definitively dictate the JSON structures used by both the .NET companion and the TypeScript frontend12.

Drift testing must be automated without requiring developers to copy implementations. This is achieved using the cargo-xtask pattern. \[Externally Verified Fact\]: cargo-xtask provides free-form repository automation, entirely bootstrapped via cargo and rustc, allowing the definition of custom workflows without external shell scripts14. A custom task, such as cargo xtask check-schema-drift, can be configured to instantiate the schemars generator in memory, output the expected JSON schema, and compare it against the currently committed schema artifact using the insta snapshot testing library15. If a Rust struct is modified (e.g., a field is added or removed) but the committed schema snapshot is not intentionally updated, the insta test will fail the Continuous Integration (CI) pipeline, preventing undocumented drift from reaching production.

During breaking changes, such as the mandated deprecation of the legacy SLM1 format in favor of SLM2, coordinated commits are essential. Temporarily incompatible branches must be staged across the workspace. Because the wire-formats crate acts as the central hub, the Rust compiler will instantly flag incompatible consumer behavior in LMComposer or Runtime during a standard workspace build. Furthermore, the validated JSON schema acts as the source material for generated bindings. C\# classes for the .NET companion and TypeScript interfaces for the browser frontend must be auto-generated from this schema, guaranteeing that downstream consumers cannot expect a field that the upstream Rust WASM module no longer provides.

\[Project-Supplied Fact\]: A justified format change must replace the current implementation coherently, not add another compatibility path. Therefore, any fallback parsing logic inside Runtime.MiRust.com that attempts to interpret obsolete SLM1 layouts must be aggressively purged. The schema must strictly accept only the exact shape of SLM2.

Reusable Libraries vs. Tooling Independence

Ecosystem closure requires cleanly distinguishing between code that must be shared, code that should exist as generated artifacts, and code that should operate as an independent service. Failing to separate these concerns results in dependency cycles, bloated WebAssembly binaries, and deployment gridlock.

Reusable libraries must be strictly decoupled from environment-specific I/O. For instance, the core tensor math engine within Runtime.MiRust.com must not be aware of whether it is executing inside a sandboxed WebAssembly environment or running natively on Windows. It should operate purely on borrowed memory slices (&\[u8\] or &\[f32\]). \[Externally Verified Fact\]: Bringing heavy shared libraries that pull in threaded asynchronous runtimes (like tokio) into a WebAssembly module will bloat the binary and frequently cause memory.grow out-of-memory panics, as standard allocators like dlmalloc can suffer from fragmentation within the strict 32-bit linear memory space17. The WASM execution path must utilize minimal allocators and avoid shared OS-level abstractions.

Generated artifacts, such as TypeScript interfaces and C\# models, should not be hand-maintained or copied between repositories. They must be generated by the build pipeline (via the schemars output) and published to an internal registry or checked into a specific, heavily guarded bindings/ directory.

Small protocols govern interactions across strict execution boundaries, such as the communication between the Browser Extension and the .NET Companion. This interaction relies entirely on the Native Messaging JSON schema. It should not share a compiled binary dependency. This separation allows the .NET application to be updated independently of the Chrome Extension approval process, ensuring deployment independence.

Finally, a single owning service architecture applies to elements like MiniModel.org. It must remain independent and not share a compilation unit with TinyRustLM.com. It exposes a static REST API queried by the browser client. This architectural isolation prevents a failure or dependency conflict in the model composer or cataloging system from degrading the public-facing browser application.

State Vocabulary and Claim Matrix

Conflating states such as "downloaded" and "installed" leads to contradictory documentation, misaligned engineering assumptions, and user confusion. The architecture requires a precise vocabulary and claim matrix to govern the model lifecycle.

\[Project-Supplied Fact\]: "Structural conversion, synthetic tests, and a browser opening successfully do not establish useful model behavior." Therefore, the transition from Loaded to Qualified must involve actual tensor execution yielding a coherent token. This guarantees that numerical stability and hardware compatibility are proven before the user interacts with the interface.

Documentation and Guidance Structure

Current project prose contains conflicting owner requirements, particularly regarding the prohibition of MiniModel.org seeding versus the new explicit authorization. To resolve this without destroying historical context, the project must adopt a structured documentation hierarchy.

\[Recommendation\]: Implement an Architecture Decision Record (ADR) framework located in E:\\Source\\Rust\\TinyRustLM.com\\docs\\adr\\.

The authoritative source of truth for the current system behavior must always be the executable code, the README.md, and the generated JSON schemas. Historical decisions and conflicting old prose must not be silently deleted; they must be moved into the ADR framework. For example, a document titled ADR-001-Authorize-MiniModel-Seeding.md will explicitly state: "Context: Previously, prose prohibited external seeding. Decision: To resolve setup complexity, MiniModel.org is explicitly authorized to supply initial server seeds." This visibly reconciles the conflict and prevents future regression.

Experiment lessons must be housed in a dedicated docs/experiments/ directory. These files will contain compact markdown records of failed or successful architectural tests, such as evaluations of WebGPU buffer limits or WASM memory fragmentation. Pending work must be managed strictly through Git issue trackers linked to the canonical repository, eradicating the practice of maintaining floating "TODO" lists scattered across documentation files.

Incremental Cleanup Sequence

Attempting to polish all seven repositories simultaneously will stall the release of the first usable product. An incremental cleanup sequence is recommended to improve the working path while systematically identifying and pruning dead weight.

Phase 1: Establish the Baseline. Identify and isolate the six exact artifacts (model.slm2, tokenizer.tokenizer2, template.template2, sampling.sampling2, prompt.prompt2, composition.acg2) physically present in D:\\LLMs\\TinyRustLM. Immediately purge any fallback parsing paths in Runtime.MiRust.com that look for legacy SLM1 file formats. Do not assert that unseen code is safe to delete; rely on compiler coverage tools to identify unused SLM1 structs.

Phase 2: Secure the Browser Storage. Implement OPFS in TinyRustLM.com for local model storage. Configure the deployment headers for the browser to include Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: credentialless (or require-corp). This is non-negotiable; without these headers, SharedArrayBuffer is disabled, and high-performance WebAssembly multithreading will fail19.

Phase 3: Connect the Initial Seed. \[Project-Supplied Fact\]: The owner requires a new user to obtain a small working default through MiniModel.org. Wire the frontend to query the REST endpoint for the default seed. Implement the robust pipeline: download, verification, and OPFS installation.

Phase 4: Ecosystem Closure. Deprecate the redundant marketing and historical domains (MiRust.com, TinyRustLM.MiRust.com, and MiniModel.MiRust.com). Point their DNS records directly to the canonical domains to eliminate apparent competing authorities. Finalize the integration of the cargo-xtask schema drift tests into the continuous integration pipeline.

Minimum Viable Approach vs. Credible Alternatives

The minimum viable approach recommended here relies on OPFS for storage and WebGPU for execution, utilizing strict schema drift tests to maintain coherence.

A credible alternative for storage is IndexedDB. However, \[Externally Verified Fact\] while IndexedDB can store large amounts of data, it incurs massive overhead on large ArrayBuffer objects due to serialization and transaction costs, making it significantly slower than OPFS, which offers in-place, zero-copy read access via createSyncAccessHandle() inside Web Workers4. OPFS is mathematically superior for loading multi-gigabyte models into WebAssembly memory.

A credible alternative for execution is WebAssembly SIMD (Single Instruction, Multiple Data) execution on the CPU. \[Externally Verified Fact\] While WebAssembly SIMD utilizing the v128 type offers substantial speedups over scalar CPU execution (averaging 1.7 to 4.5 times faster)21, it fundamentally cannot compete with the parallel processing power of WebGPU for large matrix multiplications (GEMM) required in LLM inference. WebGPU is the required primary target, with WASM SIMD retained strictly as a fallback mechanism for hardware that fails WebGPU qualification.

Regarding Schema maintenance, an alternative is relying on Protocol Buffers (Protobuf) or FlatBuffers. While highly efficient, introducing Protobuf requires an external protoc compiler dependency and complicates the build process. Using schemars alongside standard Rust serde attributes keeps the entire definition pipeline native to Rust and JSON, which is natively understood by the browser environment, reducing architectural complexity.

Topic-Specific Calculations and Algorithms

WebAssembly Memory Calculation

\[Externally Verified Fact\]: WebAssembly linear memory is currently restricted to 32-bit pointers in most stable browser environments, imposing a hard limit of 4 GB ([Figure omitted from source export] bytes)22. A WebAssembly page is exactly 64 KiB ([Figure omitted from source export] bytes)17. To calculate the maximum allowable pages:

[Figure omitted from source export]

If the sum of the .slm2 model weights, the KV cache, and the execution shadow stack exceeds 65,536 pages, the application will experience a Memory.grow panic and terminate23. The LMComposer must enforce a strict parameter size limit to ensure the resulting .slm2 file remains well below the \~3.5 GB effective threshold to leave room for dynamic allocation.

WebGPU Dispatch Overhead Algorithm

\[Externally Verified Fact\]: The WebGPU architecture imposes significant per-operation validation overhead. Recent academic measurements reveal that true per-dispatch cost of WebGPU API overhead is [Figure omitted from source export] on Vulkan and [Figure omitted from source export] on Metal. The total per-operation overhead including JavaScript/Python framework cost is [Figure omitted from source export]24. For a model executing [Figure omitted from source export] layers, where each layer requires [Figure omitted from source export] discrete dispatch operations, the total latency overhead [Figure omitted from source export] per token generation is:

[Figure omitted from source export]

If [Figure omitted from source export] layers and [Figure omitted from source export] dispatches per layer, the overhead alone consumes [Figure omitted from source export] milliseconds per token, severely impacting Time-To-First-Token (TTFT) and generation speed.\[Recommendation\]: The runtime must implement Kernel Fusion to combine consecutive operations (e.g., matmul \+ silu) into single WebGPU shader dispatches, mathematically reducing [Figure omitted from source export] and directly increasing token throughput.

Schema Validation Pseudocode

The following pseudocode outlines the strict validation mechanism required during the "Composition to Runtime" boundary transition to prevent malformed execution:

 

 

 

Rust

fn validate\_payload\_boundary(file\_handle: \&OpfsHandle) \-\> Result\<(), ExecutionError\> {     let manifest\_bytes \= file\_handle.read\_header()?;     let manifest: Acg2Manifest \= serde\_json::from\_slice(\&manifest\_bytes)         .map\_err(|\_| ExecutionError::MalformedHeader)?;          // Strict schema enforcement: Reject unknown fields     if manifest.version \!= CURRENT\_SCHEMA\_VERSION {         return Err(ExecutionError::SchemaDrift);     }          // Validate hardware bounds     let gpu\_limits \= navigator.gpu.requestAdapter()?.limits();     if manifest.max\_tensor\_size \> gpu\_limits.maxStorageBufferBindingSize {         return Err(ExecutionError::BufferSizeExceeded);     }          Ok(()) }

Prioritized Experiment Matrix

The following matrix dictates the exact experimental procedures required to validate critical architectural assumptions before production release. Treat every unmeasured threshold as a strict proposal.

 

Required Decision Artifacts

Error Taxonomy

Errors must be definitively typed to prevent generic "Something went wrong" failures and guide the user toward actionable resolutions.

 

End-to-End Sequence Diagram: First-Run Acquisition and Conversation

The following outlines the precise logical state machine sequence for a new user experience, isolating the components and their integration boundaries.

1. User Initialization: User navigates to TinyRustLM.com.

2. Environment Check: Browser evaluates COOP/COEP headers. self.crossOriginIsolated is confirmed true. WebGPU adapter is requested.

3. State Evaluation: Frontend queries OPFS for the presence of .composition.acg2.

• Branch: If missing, trigger Acquisition.

4. Acquisition:

• Frontend sends a GET request to MiniModel.org/v1/seed/default.
• MiniModel.org responds with a manifest containing SHA-256 hashes and chunked download URLs.
• Frontend streams chunks directly into OPFS using FileSystemWritableFileStream to prevent main-thread RAM exhaustion.
• Frontend validates hashes. State shifts to Installed.

5. Runtime Loading:

• Web Worker spawns.
• Worker utilizes FileSystemSyncAccessHandle to map .slm2 bytes synchronously into WASM linear memory.

6. Qualification:

• WASM engine parses tokenizer.tokenizer2 and loads WebGPU compute shaders.
• A synthetic blank prompt is passed through the network.
• If WebGPU throws a GPUDevice.lost exception, the application falls back to WASM-CPU execution automatically. State shifts to Deployed.

7. Conversation:

• User inputs text.
• prompt.prompt2 and template.template2 format the text according to the specific model template.
• tokenizer.tokenizer2 encodes the string into token IDs.
• WebGPU/WASM executes inference layers.
• sampling.sampling2 selects the next token.
• Tokens stream back to the UI asynchronously.

Cross-Project Integration-Test Plan

Instead of copying implementations to test boundaries, the architecture dictates using cargo-nextest for fast, isolated process-per-test execution across the entire workspace26.

1. Target: wire-formats crate.

• Test: Generate schema [Figure omitted from source export] Assert against committed insta snapshot.

2. Target: LMComposer.

• Test: Ingest dummy weights [Figure omitted from source export] Produce SLM2 binary [Figure omitted from source export] Pass bytes to Runtime API [Figure omitted from source export] Assert successful graph initialization.

Change-Propagation Checklist

Before any release altering the boundary schemas, the following checklist must be executed:

• \[ \] Modify Rust struct in wire-formats crate.
• \[ \] Run cargo xtask check-schema-drift to update the canonical .schema.json.
• \[ \] Execute bindings generation script to update TypeScript and C\# interfaces.
• \[ \] Update Runtime.MiRust.com to handle the new fields.
• \[ \] Update LMComposer.com to emit the new fields.
• \[ \] Run cargo nextest across the workspace to verify end-to-end serialization.

Final Specifications

Minimal Architecture for First Usable Product

To deliver the first usable product, the architecture must be stripped to its barest essentials, prioritizing the immediate "usable default" requirement over advanced configurations.

1. Frontend: Static HTML/JS served via TinyRustLM.com, requiring COOP/COEP headers to enable SharedArrayBuffer threading capabilities.

2. Storage: OPFS exclusively. No local-file import or IndexedDB overhead is permitted for the initial release.

3. Inference: Single WASM module compiled from Runtime.MiRust.com.

4. Seed Service: A static JSON manifest hosted on MiniModel.org pointing to a pre-qualified SLM2 chunked payload.

5. Companion: Defer the Windows .NET companion entirely for the MVP. Local-file import and custom peers belong under Advanced settings and are not required for the minimum viable path.

Complexity to Defer or Retire

• Retire: All legacy format parsing logic for SLM1 within the runtime.
• Retire: Redundant domain names (\*.MiRust.com).
• Defer: The Windows .NET companion application and Native Messaging IPC. While defined strictly in the contract, a browser-only OPFS-based approach entirely satisfies the immediate requirement to "open it, automatically restore a usable installed model... and have a useful conversation."
• Defer: Advanced features including Hugging Face direct imports, custom peer IP networking, and local structural conversion directly within the browser.

Implementation Sequence

1. Isolate Artifacts: Establish the central wire-formats crate and define the exact data layout for the six canonical artifacts.

2. Purge Legacy Code: Remove all SLM1 compatibility readers from the runtime.

3. Secure Storage: Implement the OPFS storage layer in the frontend and configure COOP/COEP HTTP response headers.

4. Wire the Seed: Connect the frontend to MiniModel.org for automated seed acquisition.

5. Automate Drift Testing: Implement the cargo-xtask and schemars pipeline in CI.

Explicit Ship / No-Ship Criteria

• SHIP: self.crossOriginIsolated evaluates to true in the production browser console.
• SHIP: A new user navigating to the site with a cleared browser cache successfully pulls a model from MiniModel.org and streams a coherent conversational response in under 10 seconds.
• NO-SHIP: The application source code contains fallback parsing code for SLM1.
• NO-SHIP: cargo xtask check-schema-drift fails in CI.
• NO-SHIP: Downloading the model blocks the main browser UI thread (indicating OPFS/Web Workers are not correctly implemented).

Unresolved Local Measurements

• WebGPU Buffer Limits: Engineering must measure the exact maxStorageBufferBindingSize across target consumer devices (e.g., integrated Intel graphics vs. Apple Silicon) to determine the exact chunking strategy for model.slm2.
• WASM OOM Thresholds: Engineering must measure at what specific model parameter count the 32-bit WebAssembly 4GB linear memory limit is breached, forcing a shift to the experimental WASM memory64 architecture (which is not yet universally stable across all mobile browsers)8.

What to Stop Doing

• Stop maintaining documentation across multiple disparate domain names.
• Stop referencing obsolete historical prose that prohibits server-side seeding from MiniModel.org.
• Stop treating WebGPU execution as infallible; implement explicit device.lost promise handling to prevent silent application state corruption.

Compact Experiment-Lesson Template

An engineer must be able to document architectural tests efficiently.

Question: Does storing model.slm2 in IndexedDB cause unacceptable memory overhead compared to OPFS?Exact Inputs: 1.5 GB quantized SLM2 payload.Method: Load payload into IndexedDB via main thread; load identical payload into OPFS via Web Worker using createSyncAccessHandle. Measure RAM spike and Time-to-First-Token (TTFT).Result: IndexedDB transaction caused a 3 GB memory spike (due to ArrayBuffer serialization) and crashed the tab on devices with \<8GB RAM. OPFS loaded synchronously with near-zero overhead.Uncertainty: OPFS sync APIs are strictly limited to Web Workers; requires complex message passing if the main thread needs metadata.Decision: OPFS is mandated for all payload storage. IndexedDB is banned for artifacts larger than 5 MB.Reusable Lesson: Browser storage APIs are not created equal; zero-copy memory mapping requires OPFS and Worker isolation.Evidence Identity: commit-hash-8f92a1b, docs/experiments/EXP-004-OPFS-vs-IDB.md.

Smallest Falsifying Experiment

To falsify the primary recommendation (that relying on OPFS and WebGPU is sufficient for the default usable experience), engineers should deploy the MiniModel.org default seed to a low-end integrated graphics device (e.g., an older Intel HD graphics chipset) with Chrome. If the WebGPU context repeatedly throws GPUDevice.lost due to the OS timeout watchdog (TDR) and the WASM-CPU fallback takes longer than 60 seconds to produce a single token, the architecture fails the "usable conversation" requirement. This would falsify the premise that the browser alone can handle the default seed, necessitating the immediate reprioritization of the deferred Windows .NET companion to offload computation to native code.

Works cited

1. WebGPU Memory Limits: maxStorageBufferBindingSize \- Ayoob AI, https://ayoob.ai/blog/webgpu-maxstoragebufferbindingsize-limits-enterprise

2. Model File Lookup by SHA256 Hash \- Hugging Face Forums, https://discuss.huggingface.co/t/model-file-lookup-by-sha256-hash/154293

3. SafeTensors: Efficient Serialization Format for Deep Learning, https://medium.com/@nishthakukreti.01/safetensors-efficient-serialization-format-for-deep-learning-57364317be43

4. Origin private file system \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/File\_System\_API/Origin\_private\_file\_system

5. 3x faster project loads with the origin private file system, https://barndoors.lumafield.com/3x-faster-project-loads-with-the-origin-private-file-system/

6. sqlite-wasm-in-the-browser-backed-by-the-origin-private-file-system, https://github.com/GoogleChrome/developer.chrome.com/blob/main/site/en/blog/sqlite-wasm-in-the-browser-backed-by-the-origin-private-file-system/index.md

7. How to support "optimized" 64 MiB JSON parsing and streaming for, https://discuss.python.org/t/how-to-support-optimized-64-mib-json-parsing-and-streaming-for-native-messaging-host/105567

8. Memory64 in 2026: Breaking the 4GB Ceiling in Browsers and Servers, https://wasmhub.dev/blog/memory64-in-2026

9. Load cross-origin resources without CORP headers using COEP, https://developer.chrome.com/blog/coep-credentialless-origin-trial

10. The Web-CLI: Verifiable Privacy for Tools, Models, and Inference, https://arxiv.org/html/2608.28950v1

11. CORP vs COEP, two sides of cross-origin isolation \- CentralCSP, https://centralcsp.com/en/blog/corp-vs-coep

12. Schemars in Rust: Beyond Basic Structs, https://redandgreen.co.uk/schemars-in-rust/rust-programming/

13. schemars \- Rust \- Docs.rs, https://docs.rs/schemars

14. matklad/cargo-xtask \- GitHub, https://github.com/matklad/cargo-xtask

15. GitHub \- gpu-cli/openapi-to-rust: OpenAPI generator for Rust: typed, https://github.com/gpu-cli/openapi-to-rust

16. Web Frontend (WASM) \- Rust Tool Index \- corrode.dev, https://tools.corrode.dev/?stack=web

17. Linear Memory Management & Allocators \- WebAssembly (Wasm), https://www.webassembly-wasm.com/js-wasm-interop-memory-management/linear-memory-management-and-allocators/

18. Memory in wasmtime \- Rust, https://docs.wasmtime.dev/api/wasmtime/struct.Memory.html

19. Cross-Origin-Embedder-Policy (COEP) header \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cross-Origin-Embedder-Policy

20. A guide to enable cross-origin isolation | Articles \- web.dev, https://web.dev/articles/cross-origin-isolation-guide

21. Boosting WebAssembly Performance with SIMD and Multi-Threading, https://www.infoq.com/articles/webassembly-simd-multithreading-performance-gains/

22. Up to 4GB of memory in WebAssembly \- V8 JavaScript engine, https://v8.dev/blog/4gb-wasm-memory

23. WebAssembly Memory Access Out of Bounds? Let's Break It on, https://rayepeng.medium.com/webassembly-memory-access-out-of-bounds-lets-break-it-on-purpose-278dc98c8597

24. Characterizing WebGPU Dispatch Overhead for LLM Inference, https://arxiv.org/abs/2604.02344

25. Engineering Resilient Compute Pipelines: Handling WebGPU, https://ayoob.ai/blog/webgpu-device-loss-recovery

26. Faster Rust Tests With cargo-nextest | The RustRover Blog, https://blog.jetbrains.com/rust/2026/05/01/faster-rust-tests-with-cargo-nextest/